The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

hi, all

I try to resize the window in my game, but I found the renderer didn't
worked after that. It seems that the renderer cannot find the target of the
resized window. How to solve it?



--
View this message in context: http://sdl.5483.n7.nabble.com/render-fail-after-resize-window-tp38388.html
Sent from the SDL mailing list archive at Nabble.com.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

after some tests, I found after resizing the window, if the renderer have
some textures with flag "SDL_TEXTUREACCESS_TARGET", the renderer will not
work. Is this a bug, or I lost something?



--
View this message in context: http://sdl.5483.n7.nabble.com/render-fail-after-resize-window-tp38388p38391.html
Sent from the SDL mailing list archive at Nabble.com.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Is this on Windows using Direct3D?


On Wed, Nov 27, 2013 at 3:13 AM, bttt wrote:

Hi,

This is how directx 9 works. It is also a Bug in SDL, sort of, because
SDL does not have a way to deal with it currently. You fill face the
same problem when you hit Alt-Tab, or lock the screen using WindowsKey + L.

After a window resize (and Alt-Tab and Fullscreen to Window and Screen
Lock), the DX9 video device is lost. SDL tries to restore it
automatically, but it fails because the device can't be restored until
all the unmanaged textures are purged first (according to MSDN docs).
SDL doesn't tell you that the Device is lost, it just tries to restore
it and keeps failing. None of the SDL_renderxxxx() functions return a
value, so you can't get any return values to determine the device status
either.

Changing those functions could be useful, but we have an API freeze.
However, we can add a function to determine that the video device is lost.
Maybe a function like: SDL_RenderIsDeviceOk() or SDL_RenderIsDeviceLost()

Workaround:
0. SDL doesn't tell you that video device is lost, but you can try to
guess. Every time you resize a window, or loose focus, set an internal
device loss flag.
1. When the flag is set and you regain focus, destroy all textures with
the flag "SDL_TEXTUREACCESS_TARGET".
2. Clear the screen using SDL_render_clear() (This will reset the device).
3. Re-create your render target textures.
4. Reset flag.

On 11/27/2013 4:43 PM, bttt wrote:

--
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/11/28, Pallav Nawani:

Honestly I'd rather just fix the issue so it's safe to assume the
device is available.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If we could make it just work automatically, that would be nice.

The issue is that we cannot reset the device UNTIL all the unmanaged
textures are freed. And RenderTarget textures have to be unmanaged, as
per DX9 docs.
That means SDL will have to free all the Render Target textures
allocated by the User, reset the device, and then re-allocate them.

It could be make to work, yes.

On 11/28/2013 10:54 AM, Sik the hedgehog wrote:

--
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well, whoever will make SDL free all the render target textures will need to take into account multithreading. That would be a painful process.



On Thu, Nov 28, 2013 at 7:35 AM, Pallav Nawani wrote:

thanks a lot for your help. It works. But a little complicated, hope this
could be fixed in the newer version.



--
View this message in context: http://sdl.5483.n7.nabble.com/render-fail-after-resize-window-tp38388p38401.html
Sent from the SDL mailing list archive at Nabble.com.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

A function like: SDL_RenderIsDeviceOk() or SDL_RenderIsDeviceLost() would probably be best, I think.


On Thu, Nov 28, 2013 at 11:36 AM, bttt wrote:




--
Pallav Nawani
IronCode Gaming Private Limited
Website: http://www.ironcode.com
Twitter:  http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

We would need to start tracking all render target textures, and when the device is lost, back them up (ANGLE seems to be using this technique) and restore them, and on top of that throw in a few or all of the device recreation workarounds that ANGLE has and hope that it all works


Or we could send an event saying that the device is lost and leave it up to the app to restore its contents, which would also be handy in some mobile Open GL corner cases.


Patches welcome?



2013/11/28 Pallav Nawani




--
Gabriel.

Yeah, add a function to check if the device is OK so we make the life
of everybody using SDL for rendering harder.

My problem is that if they're added, then suddenly everybody will be
required to check if the device is available whenever *any* rendering
operation needs to be done (I really doubt it'll get limited to render
targets). That sounds like a giant headache, especially when it could
have been handled at the SDL level.

Can't SDL keep track of the render targets and remake them in case of
a device lost? I imagine it already does similar stuff for other
things (if I recall correctly it's perfectly possible to lose *any*
texture, not just render targets, so code doing something like this
should already be there for reference).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You don't have to check every render operation. You just have to check once, before you begin rendering. If the device is lost during rendering, no harm is done, nothing will show up on the screen. Next frame, the device will be reset, textures re-allocated, and rendering continues.



Either the event or the function will work.






On Thu, Nov 28, 2013 at 6:46 PM, Sik the hedgehog wrote:




--
Pallav Nawani
IronCode Gaming Private Limited
Website: http://www.ironcode.com
Twitter:  http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

2013/11/28, Pallav Nawani:

Except the implication I'm seeing from the problem mentioned here is
that reallocation does *not* happen and the program has to do it
manually.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Render targets cannot be remade from source data because their source data is the result of rendering operations on the GPU. Not even heavyweight engines like Unity3d attempt to do that:


"Keep in mind that render texture contents can become "lost" on certain events, like loading a new level, system going to a screensaver mode, in and out of fullscreen and so on. When that happens, your existing render textures will become 'not yet created’” [1]


Now, it does sound like a bug in SDL’s case if the rest of the SDL Renderer doesn’t work at all or the Render Targets have no indication that they need to be remade when this happens.


[1]: http://docs.unity3d.com/Documentation/ScriptReference/RenderTexture.html

On Nov 28, 2013, at 10:29 AM, Sik the hedgehog wrote: