0
\$\begingroup\$

Currently, the way I render my frames is as follows. I have two arrays of pixels (in SDL_PIXELFORMAT_ABGR8888) called frame_pixels (which represents the pixel data for the current frame) and clear_frame_pixels (which is a constant array of black pixels). First I clear the renderer and reset frame_pixels by copying clear_frame_pixels to it. During my draw calls, I write to frame_pixels and then copy the data into a texture called frame_texture (with access SDL_TEXTUREACCESS_STREAMING), which is then copied onto the renderer and presented.

SDL_RenderClear(renderer)
memcpy(frame_pixels, clear_frame, size_of_frame_pixels);

// Draw functions go here.

// Lock frame texture and copy the pixel array onto it.
unsigned char *locked_pixels;
int pitch;
SDL_LockTexture(frame_texture, NULL, locked, &pitch);
memcpy(locked, frame_pixels, size_of_frame_pixels);
SDL_UnlockTexture(frame_texture);
SDL_RenderCopy(renderer, frame_texture, NULL, NULL);

SDL_Present(renderer);

I have a few questions, the first of which concerns the top 2 lines:

  • Do I need SDL_RenderClear anymore? Without it, my program runs with no difference, but I'm worried that there are underlying side effects that have not hit me yet.
  • Is there a faster way to do this? The reason I'm rendering using textures and pixel arrays is because it is much faster than the standard SDL_RenderDrawX functions. So any further optimization is appreciated.
  • In terms of terminology, would frame_pixels be called a "frame buffer"? What would frame_texture be called, then?
\$\endgroup\$

1 Answer 1

0
\$\begingroup\$
  • no but remember SDL_RenderClear clears pixels but also z-buffer if present and may change behaviour on different GPUs or hardware platforms; so maybe if you can experience for example no-rendering or only-partial rendering because of z-buffer trash; I recommend you to make SDL_RenderClear customizable and use it at least in the first N-frames after starting and/or recovering focus. Also some drivers can use SDL_RenderClear to perform some needed tasks. My recomendation is that you can disable SDL_RenderClear as an option.
  • using memcpy copies on the CPU. You are downloading from GPU to CPU, copying in the CPU and then uploading back to the GPU, so yes, you can perform much faster indeed. You should test it, but I suspect that you can copy pixels without passing them thru CPU by using SDL_SetRenderTarget+SDL_RenderCopy, but I'm not really sure what your needs are.
  • the frame/screen is not really a texture (because texture are used to texturize 3D surfaces). Both textures and the framebuffer are usually called "surfaces", which are generic pixel buffers. Textures are also surfaces but usually they have some special properties like sizes/sides are 2-power usually and other ones, however on some modern GPUs textures can avoid some of their limitations, however for compat purposes usually restrictions are still used.
\$\endgroup\$

You must log in to answer this question.

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