Hi all,
What is the preferred way of restoring lost surfaces when using SDL.
Under DirectX when the user alt-tabbed away from the game and alt-tabbed
back, I had to repopulate the DirectX surfaces.
Do the same rules apply with SDL or is there another way this is done
that I have missed.
Thanks,
Dominique.
Hi all,
What is the preferred way of restoring lost surfaces when using SDL.Under DirectX when the user alt-tabbed away from the game and
alt-tabbed back, I had to repopulate the DirectX surfaces.Do the same rules apply with SDL or is there another way this is done
that I have missed.
From what I have read recently on this list (check the archives to
verify this) SDL doesn’t restore hardware surfaces that go away. You
can check for SDL_ACTIVEEVENT to detect when someone alt-tabbed away
from or to your application, and recreate the surfaces.
-DOn Wednesday, June 5, 2002, at 10:53 AM, Dominique Louis wrote:
From what I have read recently on this list (check the archives to
verify this) SDL doesn’t restore hardware surfaces that go away. You
can check for SDL_ACTIVEEVENT to detect when someone alt-tabbed away
from or to your application, and recreate the surfaces.
I don’t know anything on this topic but… Couldn’t this be done by SDL
internally? Or are there cases where you wouldn’t want it done
automatically? Well, even if there are cases where it shouldn’t be done, I
think an option (passed at the surface creation?) to do it automatically
would be nice…
-Ga?tan.
From what I have read recently on this list (check the archives to
verify this) SDL doesn’t restore hardware surfaces that go away. You
can check for SDL_ACTIVEEVENT to detect when someone alt-tabbed away
from or to your application, and recreate the surfaces.
I don’t know anything on this topic but… Couldn’t this be done by SDL
internally?
Perhaps. But the problem may be that there is no way to know if the
surface has vanished or not. I may be imagining things here, but that’s
the impression I got from a past email on this topic.
-DOn Wednesday, June 5, 2002, at 12:02 PM, Ga?tan de Menten wrote:
Hi all,
What is the preferred way of restoring lost surfaces when using SDL.Under DirectX when the user alt-tabbed away from the game and
alt-tabbed back, I had to repopulate the DirectX surfaces.Do the same rules apply with SDL or is there another way this is done
that I have missed.From what I have read recently on this list (check the archives to
verify this) SDL doesn’t restore hardware surfaces that go away. You
can check for SDL_ACTIVEEVENT to detect when someone alt-tabbed away
from or to your application, and recreate the surfaces.
Don’t you just need an SDL_Flip?
From what I have read recently on this list (check the archives to
verify this) SDL doesn’t restore hardware surfaces that go away. You
can check for SDL_ACTIVEEVENT to detect when someone alt-tabbed away
from or to your application, and recreate the surfaces.
I don’t know anything on this topic but… Couldn’t this be done by SDL
internally? Or are there cases where you wouldn’t want it done
automatically? Well, even if there are cases where it shouldn’t be done,
I
think an option (passed at the surface creation?) to do it automatically
would be nice…
I just checked my application running an SDL/OpenGL combo under Win32 and
I’m not loosing surfaces when I alt-tab away and back again. But I’m
thinking that with the series of applications that I’m alt-tabbing to, maybe
my 64MB geForce3 is simply not needing the video memory?
I have found that I need to recreate all my textures and displayLists when I
change window resolutions or toggle between full screen and windowed.
(Strange though, when full screen I can alt-tab to another program just
fine.)
Is there some means of testing when a surface is lost? Likewise, I can
understand how changing window resolution or changing to/from full screen
requires a recreation of the OpenGL context- and therefore a recreation of
all textures and displayLists. But when alt-tabbing it appears that I’m
retaining these pieces, but that may not always be the case. So, is there
some means for the application to test for this?
-Blake
The effect you see is invoked by directx or other low level libs.
The effect is this: Fullscreen bzw. real hardware access means total control
about the gfx card.
If you change to another application (or desktop - thats also a
application),
then you lose control - and all what you have done with the cards memory.
This includes
of course every suface, you had allocated from hardware ram of your gfx
card. DirectX/Sdl
will remember size and settings of your surfaces - but the content will be
kicked.
Look in the doku under SDL_BltSurface. If you lose your hardware access,
this routine
(and all others which use a surface) will return -2 when you try to blit. If
you press Alt/tab
when using a fullscreen app, this app is not stopped. The main loop
inclusive all blts runs on!
But instead of blt to some card memory, the routines returns with -2. If you
think about it,
you will now understand one reason of locking/unlocking surfaces too.
The reason why the application itself must care about relloading the
surfaces and not
the directx/sdl lib is simple too. First, it is to hard to resynchronize
complexer accesses-
for example when you change surfaces by the application. When you give the
focus back to your app,
it must then track back exactly the point where you lost it. You will need a
complex communication
system between OS, driver and application to really get the point, the
application lose
focus. Remember, that this can happens at EVERY point of your application -
every single blit, every
loop. Btw, thats one reason why you block the whole OS when you lock a
surface under directx.
And thats a reason why it is not allowed under linux.
Because there are too many side effects, the low level drivers like DX goes
the direct way.
Kick the memory and tell the application that it need to reallocate.
So, you need to ask inside your blt routine for -2 as SDL_BltSurface()
return and if so, you has
lose gfx card memory control.
THEN you should not try to direct reallocate the memory - ask first the OS
about who has the
focus now. If your app has then back (after pressing the alt/tab again),
then you can reinit the
surfaces.>
Hi all,
What is the preferred way of restoring lost surfaces when using SDL.Under DirectX when the user alt-tabbed away from the game and alt-tabbed
back, I had to repopulate the DirectX surfaces.Do the same rules apply with SDL or is there another way this is done
that I have missed.Thanks,
Dominique.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
OpenGL is not DirectX. Since the OpenGL standard does not allow "loosing"
textures, MS (and possibly driver writers, I don’t know) are ensuring that
textures can be restored by the implementation and the application doesn’t
have to worry about it.
With DirectX, they decided to just drop the surfaces when fullscreen mode is
left - it’s probably more convenient to do so.
I believe that changing the resolution involves destroying and recreating the
GL context so all the data (textures, display list, other state information)
is lost. Obviously, alt-tabbing, or moving the window or something like that
doesn’t require recreating the GL context.
So the bottomline is: if you’re using the SDL/GL combination, you don’t have
to worry about loss at random times. If you use standard hardware surfaces,
you do have to worry…
cu,
NicolaiAm Mittwoch, 5. Juni 2002 20:11 schrieb Blake Senftner:
I just checked my application running an SDL/OpenGL combo under Win32 and
I’m not loosing surfaces when I alt-tab away and back again. But I’m
thinking that with the series of applications that I’m alt-tabbing to,
maybe my 64MB geForce3 is simply not needing the video memory?I have found that I need to recreate all my textures and displayLists when
I change window resolutions or toggle between full screen and windowed.