2
\$\begingroup\$

Studying the case of isometric rendering, I'm facing a big and well-known problem : depth sorting.

After many researches it seems that without tile mapping or 'height-leveling' it's impossible to solve this problem in a 2D game.
So I imagined a depth buffer that I could use with sdl_textures . The process : each sprite would contain pixels , with rgba AND a depth variable . When it comes to blit, I would check in a backbuffer the pixels that are nearer than the current pixels and replace them. Then I would convert the buffer to a texture with only four channels (rgba without depth) in order to SDL_Rendercopy it .

My questions are:

  • Is it possible to do so ?
  • Isn't it too slow to check each pixel of a 1024×768 screen in this kind of scheme ?
  • How do I create a sdl_texture from an simple array of int ?
Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ You mentioned depth sorting in the beginning of your question, but what is the actual problem you're trying to solve? Why doesn't object-based rendering ordering work, so why do you need to hackishly implement this with textures? \$\endgroup\$
    – user35344
    Apr 28, 2016 at 13:13
  • \$\begingroup\$ My problem is that when rendering with a trivial depth order, there are cases where objects overlap other objects but are also overlapped by the same objects . This problem occurs essentially in isometric 2D worlds and has not been solved until now without using tile-mapping or sprite slicing. You can find many examples on the Internet . And I'm working on this problem in order to understand the mechanisms and limits of pixel manipulation and 3D rendering in general ;) \$\endgroup\$
    – Zack
    Apr 28, 2016 at 14:16
  • 2
    \$\begingroup\$ Could you post an example image and edit that to the question? That would clarify the issue. \$\endgroup\$
    – user35344
    Apr 28, 2016 at 18:47

1 Answer 1

Reset to default
2
\$\begingroup\$

Of course it is possible, if people can write a depth buffer you can too, but it will be hideously slow. Reading from and updating SDL2 textures is very slow because it's all via software, i.e. not hardware accelerated. Proper depth buffers operate at the rasterisation step and are accelerated via your massively parallel graphics hardware.

Since SDL2 doesn't do z-ordering, your options are:

  • Do per-texture z-ordering (note: SDL2 textures) yourself. Add every texture you want to render into a collection, sort it using an algorithm that is fast on almost-sorted data (like insertion sort or Timsort), then SDL_RenderCopy in back-to-front order.
  • Use a 3D graphics library like OpenGL, render everything as 3D textured quads, and let the built in depth buffer solve the problem.
  • If your sprites have complex depth or overlap, you may be able to split the sprite into multiple parts and order the parts independently. Otherwise, the only performant method (without going full 3D) would be to write a custom shader that works with the depth buffer.
Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .