Render fail after resize window

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.

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.

Is this on Windows using Direct3D?On Wed, Nov 27, 2013 at 3:13 AM, bttt wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
.


Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming

2013/11/28, Pallav Nawani :

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()

Honestly I’d rather just fix the issue so it’s safe to assume the
device is available.

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:

2013/11/28, Pallav Nawani <@Pallav_Nawani>:

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()
Honestly I’d rather just fix the issue so it’s safe to assume the
device is available.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming

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:

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:

2013/11/28, Pallav Nawani :

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()

Honestly I’d rather just fix the issue so it’s safe to assume the
device is available.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

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:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


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 :slight_smile:

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? :slight_smile:

2013/11/28 Pallav Nawani >

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:

2013/11/28, Pallav Nawani :

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()

Honestly I’d rather just fix the issue so it’s safe to assume the
device is available.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


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).

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 < sik.the.hedgehog at gmail.com> wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


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 :

Next frame, the device
will be reset, textures re-allocated, and rendering continues.

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.

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.htmlOn Nov 28, 2013, at 10:29 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

2013/11/28, Pallav Nawani :

Next frame, the device
will be reset, textures re-allocated, and rendering continues.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org