How to get (correct) window surface when SDL_RENDERER_SOFTWARE is not enabled?

When SDL_RENDERER_SOFTWARE is enabled in the call to SDL_CreateRenderer, SDL_GetWindowSurface returns correct results, i.e., surface->pixels is pointing to memory containing correct RGBA data. But when SDL_RENDERER_SOFTWARE is not enabled so SDL_RENDERER_ACCELERATED is set by default, The result of SDL_GetWindowSurface is incorrect, i.e., surface->pixels is pointing to memory containing nothing but zero. So, could you please tell me how to return correct results by SDL_GetWindowSurface when SDL_RENDERER_SOFTWARE is not enabled? If some other API is designed for this purpose, please let me know. Thanks a lot!

PS: I’m running on Windows 10 and SDL 2.0.4.

I don’t think it is possible. The docs for SDL_GetWindowSurface() state “You may not combine this with 3D or the rendering API on this window” which I understand to mean that you should not be calling SDL_CreateRenderer() at all. You can (usually) get the pixels for the current renderer using SDL_RenderReadPixels(), but it’s slow.

1 Like

Yeah, the contents of the framebuffer are stored in VRAM, in a layout fastest for the hardware, without consideration for the CPU. To access the framebuffer contents on the CPU, you have to make various graphics API calls, and then the GPU driver will copy it to system RAM for you and convert it to linear pixel data in whatever pixel format you specified.

SDL wraps these graphics API calls for you when using SDL_Renderer, via the SDL_RenderReadPixels() function. It’s slow by nature, but fine for taking screenshots etc.

1 Like