We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2705

Summary: Problem when using SDL_SetRenderTarget + SDL_RenderReadPixels
Product: SDL Reporter: Luiggi Reffatti <lmreffatti>
Component: renderAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: icculus, lmreffatti, sanette-linux
Version: 2.0.3   
Hardware: x86_64   
OS: Windows 8   
Attachments: Small test program showing the behaviors found.
Image i used in the test program (I dont think it's relevant, but, just in case...)

Description Luiggi Reffatti 2014-08-25 04:02:21 UTC
Created attachment 1851 [details]
Small test program showing the behaviors found.

In my game, I want to create a texture by rendering other textures in a target texture (SDL_TEXTUREACCESS_TARGET), and then creating a SDL_TEXTUREACCESS_STATIC texture from it.

To do that, I:
create a texture with SDL_TEXTUREACCESS_TARGET,
set it as the render target, using SDL_SetRenderTarget 
render all my other textures over it,
use SDL_RenderReadPixels to get the pixel data back from it,
create a surface from this pixel data,
create a new texture from this surface,
free and clean up everything (but the resulting texture)

After trying to achieve that for some time, I noticed that all I could get was a black image.
Than I realized that, using direct3d as renderer, SDL_RenderReadPixels always returned something from the screen or black. After some research (I didn't have time to look at the code yet), I found 2 guys saying that on direct3d SDL_RenderReadPixels always reads from the backbuffer, it doesn't matter the texture set with SDL_SetRenderTarget.
Then I switched the driver to opengl to check the behaviour.  On opengl, the pixels from the texture set as renderTarget are retrieved, but in upside down order. I don't know if that is an expected behavior, but it doesn't looks like.

After that, I wrote a small test program that shows up this behaviours, which I'm attaching to this report.
 
Some "may be useful" info:
I'm running DirectX 11.0 here, on Windows 8.1, with a Nvidia GTX 670M with drivers updated.
I triple checked if my system supported renderTargets, just to be sure.
Comment 1 Luiggi Reffatti 2014-08-25 04:06:12 UTC
Created attachment 1852 [details]
Image i used in the test program (I dont think it's relevant, but, just in case...)
Comment 2 Sam Lantinga 2014-08-25 04:58:32 UTC
The DirectX renderer was just fixed, can you try the latest snapshot?
http://www.libsdl.org/tmp/SDL-2.0.zip

I'll take a look at the OpenGL renderer, thanks!
Comment 3 Luiggi Reffatti 2014-08-26 14:34:02 UTC
(In reply to Sam Lantinga from comment #2)
> The DirectX renderer was just fixed, can you try the latest snapshot?
> http://www.libsdl.org/tmp/SDL-2.0.zip
> 
> I'll take a look at the OpenGL renderer, thanks!

Just tested with rev 9117, problem is fixed in DirectX renderer! 
Thanks a lot =D

Just for the record, with OpenGL the problem of reading the pixels in reverse line order (resulting in an upside down image) is still there.
Comment 4 sanette 2014-09-26 12:20:06 UTC
concerning the reverse line order in opengl, I just filed a bug:
https://bugzilla.libsdl.org/show_bug.cgi?id=2740
Comment 5 Ryan C. Gordon 2015-02-19 06:18:53 UTC
Ok, looks like this bug is fixed, and the OpenGL-specific part moved to a new bug, so I'm closing this report.

--ryan.