Resizing the Gears example

SDL Development
1

Hello.

I’ve been playing with the SDLgears example, under Windows XP. A
difference between the glut version and the SDL version is that resizing
the window works with the former but not with the latter. This is due to
calling SDL_SetVideoMode, which loses the display lists. However, the
call to SDL_SetVideoMode is not necesary, and just adjusting the viewport
does the work. I’m wondering why it was done the way it was. Does it
brake under other OS?

Also, the program should include SDL_opengl.h. I’ve made both changes.
Should I upload the diff? How do I make the diff?

Bruno Martinez

2

Bruno Mart?nez Aguerre wrote:

Hello.

I’ve been playing with the SDLgears example, under Windows XP. A
difference between the glut version and the SDL version is that
resizing the window works with the former but not with the latter.
This is due to calling SDL_SetVideoMode, which loses the display
lists. However, the call to SDL_SetVideoMode is not necesary, and
just adjusting the viewport does the work. I’m wondering why it was
done the way it was. Does it brake under other OS?

That was asked recently. See this thread :
http://twomix.devolution.com/pipermail/sdl/2004-April/061268.html

Also, the program should include SDL_opengl.h. I’ve made both
changes. Should I upload the diff? How do I make the diff?

Hmm… to diff from cvs :
[go into the folder, then] cvs diff -u
To diff from two files :
diff -u file1 file2
To diff from two trees :
diff -Naur tree1 tree2
(with the latest, you might want to check you’re not adding your
temporary build files and such)

Stephane

3

Bruno Mart?nez Aguerre wrote:

Hello.

I’ve been playing with the SDLgears example, under Windows XP. A
difference between the glut version and the SDL version is that
resizing the window works with the former but not with the latter.
This is due to calling SDL_SetVideoMode, which loses the display
lists. However, the call to SDL_SetVideoMode is not necesary, and
just adjusting the viewport does the work. I’m wondering why it was
done the way it was. Does it break under other OS?

That was asked recently. See this thread :
http://twomix.devolution.com/pipermail/sdl/2004-April/061268.html

Sorry, I should’ve searched before posting. Thanks for the link.

According to Bob Pendleton, the effect of not calling SDL_SetVideoMode()
after a resize is OS specific. However, all examples from the OpenGl red
book don’t reset the rendering context. glViewPort is just called. Is it
possible to copy from GLUT’s code the way it pulls this off?

Bruno Mart?nezOn Thu, 03 Jun 2004 00:33:29 +0200, Stephane Marchesin <stephane.marchesin at wanadoo.fr> wrote:

4

SDL requires you to call SDL_SetVideoMode after a resize, even when using
OpenGL, or some SDL internals won’t see the new window size.

A side-effect of calling SDL_SetVideoMode in Windows is that the GL
rendering context is reset, which requires that the context be completely
reinitialized (textures and all other state). This is mostly a Windows
peculiarity, as far as I know.

I think this is a bug in SDL. It should either 1: not require SDL_SetVideoMode
after the window size is changed, or 2: realize that all that’s changing is
the window size, and don’t reinitialize the rendering context; and add some
API so programs can find out if they have to reinit the context.

#2 is probably better; #1 would be backwards-incompatible and require changes
to every architecture.

(If you don’t call SDL_SetVideoMode, then SDL will think the old window size
is still in use. For example, if you maximize a window, it’ll think you
have the original size; if you then restore the window so it goes back to
its original size, you won’t get a resize event, since SDL thinks the window
size hasn’t changed. There might be other effects on other architectures.)On Wed, Jun 02, 2004 at 09:50:43PM -0300, Bruno Mart?nez Aguerre wrote:

According to Bob Pendleton, the effect of not calling SDL_SetVideoMode()
after a resize is OS specific. However, all examples from the OpenGl red
book don’t reset the rendering context. glViewPort is just called. Is it
possible to copy from GLUT’s code the way it pulls this off?

–
Glenn Maynard

5

According to Bob Pendleton, the effect of not calling SDL_SetVideoMode()
after a resize is OS specific. However, all examples from the OpenGl
red

book don’t reset the rendering context. glViewPort is just called. Is
it

possible to copy from GLUT’s code the way it pulls this off?

SDL requires you to call SDL_SetVideoMode after a resize, even when using
OpenGL, or some SDL internals won’t see the new window size.

A side-effect of calling SDL_SetVideoMode in Windows is that the GL
rendering context is reset, which requires that the context be completely
reinitialized (textures and all other state). This is mostly a Windows
peculiarity, as far as I know.

I think this is a bug in SDL. It should either 1: not require
SDL_SetVideoMode
after the window size is changed, or 2: realize that all that’s changing
is
the window size, and don’t reinitialize the rendering context; and add
some
API so programs can find out if they have to reinit the context.

#2 is probably better; #1 would be backwards-incompatible and require
changes
to every architecture.

(If you don’t call SDL_SetVideoMode, then SDL will think the old window
size
is still in use. For example, if you maximize a window, it’ll think you
have the original size; if you then restore the window so it goes back to
its original size, you won’t get a resize event, since SDL thinks the
window
size hasn’t changed. There might be other effects on other
architectures.)

–
Glenn Maynard

i agree that sdl ought to understand the opengl resize vs actual
re-initialization of the opengl context (like changing the bit-depth). i
poked thru the sdl code and it seems that it would be very easy to skip the
opengl re-initialize and keep the rest of the sdl init intact for this
simple case. heck, it seems the only thing sdl needs to worry about is the
mouse bounding rectangle.

my solution would be to modify SDL’s setvideomode so that it behaves as much
like the other os’s in terms of how they treat opengl. i realize this is a
fault in windows, but if SDL can overcome it with a few simple lines of
code, why not do it?

miles vignol
fathom entertainment, incFrom: g_sdl@zewt.org (Glenn Maynard)

On Wed, Jun 02, 2004 at 09:50:43PM -0300, Bruno Mart?nez Aguerre wrote:

6

It can’t. You can resize a window without recreating the context, but
some operations (switching to and from fullscreen when the framebuffer
bit depth is different, if I remember correctly) require it. Having
SDL_SetVideoMode reset the context in some cases and not others on the
same architecture with no way of finding out if it happened or not would
be much worse. (In practice, there should be a way to find out in
advance whether a given call would reset the context.)On Wed, Jun 02, 2004 at 06:27:00PM -0700, Miles Vignol wrote:

my solution would be to modify SDL’s setvideomode so that it behaves as much
like the other os’s in terms of how they treat opengl. i realize this is a
fault in windows, but if SDL can overcome it with a few simple lines of
code, why not do it?

–
Glenn Maynard

7

my solution would be to modify SDL’s setvideomode so that it behaves as
much
like the other os’s in terms of how they treat opengl. i realize this
is a
fault in windows, but if SDL can overcome it with a few simple lines of
code, why not do it?

It can’t. You can resize a window without recreating the context, but
some operations (switching to and from fullscreen when the framebuffer
bit depth is different, if I remember correctly) require it. Having
SDL_SetVideoMode reset the context in some cases and not others on the
same architecture with no way of finding out if it happened or not would
be much worse. (In practice, there should be a way to find out in
advance whether a given call would reset the context.)

Are there situation when you can switch between fullscreem and windowed
without losing the context? If that’s the case, considering the 2 options
you described previously, I would prefer that SDL realizes that the
context can be preserved. #1: not require SDL_SetVideoMode after the
window size is changed, does not allow changes between fullscreen and
windowed.

I think that you don’t necessarily need to know in advance if it can be
done or not. I would prefer to add a flag to SDL_SetVideoMode, say
SDL_OPENGL_PRESERVE, that would make the call succeed only if the
rendering context can be preserved. The behaviour in platforms that never
lose the context would be to ignore the flag. In windows, if the flag is
not specified, the program doesn’t try to preserve the context, just the
way it works now. What do you think?

Bruno MartinezOn Wed, 2 Jun 2004 21:48:34 -0400, Glenn Maynard <g_sdl at zewt.org> wrote:

On Wed, Jun 02, 2004 at 06:27:00PM -0700, Miles Vignol wrote:

8

I think that you don’t necessarily need to know in advance if it can be
done or not. I would prefer to add a flag to SDL_SetVideoMode, say

I do, because when the context is going to be invalidated, I do things
before calling SDL_SetVideoMode.

SDL_OPENGL_PRESERVE, that would make the call succeed only if the
rendering context can be preserved. The behaviour in platforms that never
lose the context would be to ignore the flag. In windows, if the flag is
not specified, the program doesn’t try to preserve the context, just the
way it works now. What do you think?

The result of this is that every call to SDL_SetVideoMode would look
like:

if(!SDL_SetVideoMode(SDL_OPENGL_PRESERVE …))
{
/* try without */
if(!SDL_SetVideoMode(…))
error
}

I think it would be cleaner as:

bool LosingContext = SDL_SetVideoModeWillLoseContext(…);
if(!SDL_SetVideoMode(…))
error
if(LosingContext)
reload context;On Wed, Jun 02, 2004 at 11:11:05PM -0300, Bruno Mart?nez Aguerre wrote:

–
Glenn Maynard

9

I think that you don’t necessarily need to know in advance if it can be
done or not. I would prefer to add a flag to SDL_SetVideoMode, say

I do, because when the context is going to be invalidated, I do things
before calling SDL_SetVideoMode.

You do things before? I would expect doing things after, reloading
textures, etc.

SDL_OPENGL_PRESERVE, that would make the call succeed only if the
rendering context can be preserved. The behaviour in platforms that
never
lose the context would be to ignore the flag. In windows, if the flag
is
not specified, the program doesn’t try to preserve the context, just the
way it works now. What do you think?

The result of this is that every call to SDL_SetVideoMode would look
like:

if(!SDL_SetVideoMode(SDL_OPENGL_PRESERVE …))
{
/* try without */
if(!SDL_SetVideoMode(…))
error
}

Yes. That’s what I had in mind.

I think it would be cleaner as:

bool LosingContext = SDL_SetVideoModeWillLoseContext(…);
if(!SDL_SetVideoMode(…))
error
if(LosingContext)
reload context;

IIUC, that would break programs that assume the context was lost when
calling SDL_SetVideoMode under windows.

Bruno MartinezOn Wed, 2 Jun 2004 22:27:57 -0400, Glenn Maynard <g_sdl at zewt.org> wrote:

On Wed, Jun 02, 2004 at 11:11:05PM -0300, Bruno Mart?nez Aguerre wrote:

10

It can’t. You can resize a window without recreating the context, but
some operations (switching to and from fullscreen when the framebuffer
bit depth is different, if I remember correctly) require it. Having
SDL_SetVideoMode reset the context in some cases and not others on the
same architecture with no way of finding out if it happened or not would
be much worse. (In practice, there should be a way to find out in
advance whether a given call would reset the context.)

yes, there are some instances where it would fail (like bit depth changes
and perhaps fullscreen toggling), but simple resizing where you’re only
changing the size of the window would work fine.

certainly it would present a mixed bag, but it’s already a mixed bag: on
some OS’s it’s not an issue, but on windows it is. i would rather have
setvideomode under windows be 50% similar to other operating systems than 0%
simply for the sake of consistency. right now the caveat is that if you
call setvideomode under windows, you have to re-init your opengl context. i
don’t think it’s asking much to change the caveat to be if you change
anything aside from the resolution (first two parameters of setvideo mode),
then you must re-init your opengl context.

i get your point about wanting to know if it required a re-init or not, but
that seems like part B of the problem. it would be nice to have part A
working and then tackle part B (since it gets into growing the API in some
way – be it a flag, a function call, a triggered event, or whatever).

as it stands, i just don’t call setvideomode and live with the consequences
(which are minimal from what i can tell).

-miles vignol
fathom entertainmentFrom: g_sdl@zewt.org (Glenn Maynard)

11

The result of this is that every call to SDL_SetVideoMode would look
like:

if(!SDL_SetVideoMode(SDL_OPENGL_PRESERVE …))
{
/* try without */
if(!SDL_SetVideoMode(…))
error
}

I think it would be cleaner as:

bool LosingContext = SDL_SetVideoModeWillLoseContext(…);
if(!SDL_SetVideoMode(…))
error
if(LosingContext)
reload context;

i agree. for that matter, SDL_SetVideoModeWillLoseContext(…) wouldn’t
need to be part of SDL. is it too specific a function to be considered for
the API? i mean, it’s only for opengl and seems to really only be pertinent
on windows (currently, that i’m aware of).

i do like assuming that the context is preserved (like it is under most sane
OS’s) and checking for the case when it’s not. this would then make sense
for SDL to do whatever it can to preserve the context without breaking
anything.

-miles vignol
fathom entertainmentFrom: g_sdl@zewt.org (Glenn Maynard)

12

My two cents on all of this is that there should be a function like
SDL_SetVideoMode (called SDL_DestroysOpenGLContext?) that accepts the
same paramaters, but returns a true/false value stating if setting a new
video mode like this would destroy the opengl context. It would make
things much easier for us, and it would be backwards compatible with
code: older apps would just always reinit, newer apps could check if
they need to.

Also, this solves your problem of when to do it, as SDL can just figure
it out for you, and allow you to code around the fact that sometimes you
need to, sometimes you dont.

I want a function like this, so apps that have GUIs can ask the user if
they want to continue, the media would have to reload (or whatnot.)On 03-Jun-2004, Miles Vignol wrote:

From: “Glenn Maynard” <g_sdl at zewt.org>

It can’t. You can resize a window without recreating the context, but
some operations (switching to and from fullscreen when the framebuffer
bit depth is different, if I remember correctly) require it. Having
SDL_SetVideoMode reset the context in some cases and not others on the
same architecture with no way of finding out if it happened or not would
be much worse. (In practice, there should be a way to find out in
advance whether a given call would reset the context.)

yes, there are some instances where it would fail (like bit depth changes
and perhaps fullscreen toggling), but simple resizing where you’re only
changing the size of the window would work fine.

certainly it would present a mixed bag, but it’s already a mixed bag: on
some OS’s it’s not an issue, but on windows it is. i would rather have
setvideomode under windows be 50% similar to other operating systems than 0%
simply for the sake of consistency. right now the caveat is that if you
call setvideomode under windows, you have to re-init your opengl context. i
don’t think it’s asking much to change the caveat to be if you change
anything aside from the resolution (first two parameters of setvideo mode),
then you must re-init your opengl context.

i get your point about wanting to know if it required a re-init or not, but
that seems like part B of the problem. it would be nice to have part A
working and then tackle part B (since it gets into growing the API in some
way – be it a flag, a function call, a triggered event, or whatever).

as it stands, i just don’t call setvideomode and live with the consequences
(which are minimal from what i can tell).

-miles vignol
fathom entertainment

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

–
Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040603/3d125fa4/attachment.pgp

13

i agree that a function that takes the same parameters as setvideomode would
be a good solution to determine if the context changed or will change, but i
really think setvideomode should do its best to not kill the context.

i’m writing an app that has a resizable window. you grab a corner of the
window and drag it. that kills the opengl context currently. if i re-init
the context, i’d have to add a bunch of code that i really don’t need for
any other case than running on windows. i’m not going to have a fullscreen
mode. i’m not going to switch bit depths. i’m only changing the x and y
resolution of the window. which is minor enough that i can even SKIP
setvideomode in windows without any major problems (which is what i’m
currently doing). it seems like setvideomode should be able to recognize
this case and just skip the part that kills the opengl context.

-miles vignol
fathom entertainment> ----- Original Message -----

From: unknown@panax.com (Patrick McFarland)
To: "A list for developers using the SDL library. (includesSDL-announce)"

Sent: Thursday, June 03, 2004 10:14 AM
Subject: Re: [SDL] Re: Resizing the Gears example

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

14

i agree that a function that takes the same parameters as setvideomode
would
be a good solution to determine if the context changed or will change,
but i
really think setvideomode should do its best to not kill the context.

If we were designing SDL from scratch, I would agree with you. However,
there are programs out there that just assume that the context was lost if
under windows, and preserved otherwise. If the behaviour of
SDL_SetVideoMode suddenly changes, those programs would be broken.

i’m writing an app that has a resizable window. you grab a corner of the
window and drag it. that kills the opengl context currently. if i
re-init
the context, i’d have to add a bunch of code that i really don’t need for
any other case than running on windows. i’m not going to have a
fullscreen
mode. i’m not going to switch bit depths. i’m only changing the x and y
resolution of the window. which is minor enough that i can even SKIP
setvideomode in windows without any major problems (which is what i’m
currently doing). it seems like setvideomode should be able to recognize
this case and just skip the part that kills the opengl context.

I agree, but SDL should recognize this case only if explicitly told to do
so.

Another question, is there a way to lose the context on purpose?

Bruno MartinezOn Thu, 3 Jun 2004 12:13:43 -0700, Miles Vignol wrote:

15

If we were designing SDL from scratch, I would agree with you. However,
there are programs out there that just assume that the context was lost if
under windows, and preserved otherwise. If the behaviour of
SDL_SetVideoMode suddenly changes, those programs would be broken.

would they? this issue resurfaced because the gears example is already
broken. anything not written specifically to run under windows should work
fine, and even most of those that are specific to windows would probably
still work fine – rebinding textures and recreating display lists would
only cause a problem if you assumed your handles were bad without testing
them, and then the problems would only be inefficiency and not total
failure.

but maybe i’m missing something?

Another question, is there a way to lose the context on purpose?

lose the context on purpose? probably so, but it would be OS specific. SDL
must have the hooks in there at some level.From: br1@internet.com.uy (Bruno Martinez)

16

i agree that a function that takes the same parameters as setvideomode would
be a good solution to determine if the context changed or will change, but i
really think setvideomode should do its best to not kill the context.

You can’t, thats why I suggested the function in the first place. You
cannot change behavior, as it breaks older apps. As it is, all SDL
apps assume the context is destroyed, and will reload textures; if it
isnt destroyed then apps will load their resources multiple times, which
is a very bad thing. The only way to add this functionality is to use
another function and add a flag for setvideomode along the lines of
SDL_OPENGL_NO_CONTEXT_KILL (which I forgot to mention in the last mail)

i’m writing an app that has a resizable window. you grab a corner of the
window and drag it. that kills the opengl context currently. if i re-init
the context, i’d have to add a bunch of code that i really don’t need for
any other case than running on windows. i’m not going to have a fullscreen
mode. i’m not going to switch bit depths. i’m only changing the x and y
resolution of the window. which is minor enough that i can even SKIP
setvideomode in windows without any major problems (which is what i’m
currently doing). it seems like setvideomode should be able to recognize
this case and just skip the part that kills the opengl context.

Which you’re in the minority. Most apps usually do everything they can,
including depth changing, fullscreen and back, and resolution changing.
The only thing that is “broken” is that SDL has no way of not killing
the context even if the platform supports it (which is for consistancy
only). And we cant magically change the default, because it breaks all
existing SDL GL apps, which is quite a few.

Sam, if you’re reading this thread, could you mention your thoughts on
this? Since you’re the SDL God, how would you do it?On 03-Jun-2004, Miles Vignol wrote:

-miles vignol
fathom entertainment

–
Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040603/e56efcc3/attachment.pgp

17

wrote:

You can’t, thats why I suggested the function in the first place. You
cannot change behavior, as it breaks older apps. As it is, all SDL
apps assume the context is destroyed, and will reload textures; if it
isnt destroyed then apps will load their resources multiple times, which
is a very bad thing. The only way to add this functionality is to use
another function and add a flag for setvideomode along the lines of
SDL_OPENGL_NO_CONTEXT_KILL (which I forgot to mention in the last mail)

not all SDL apps. this isn’t an issue for mac or linux, unless i’m totally
misunderstanding the issue. this is only a problem under windows and only
for apps that resize. and i’m curious exactly how bad it is to reload
resources when you don’t need to.

Which you’re in the minority. Most apps usually do everything they can,
including depth changing, fullscreen and back, and resolution changing.
The only thing that is “broken” is that SDL has no way of not killing
the context even if the platform supports it (which is for consistancy
only). And we cant magically change the default, because it breaks all
existing SDL GL apps, which is quite a few.

SDL isn’t killing the context, it’s a side effect of running under
windows – again, unless i’m just totally not understanding things. so if
the platform DOES support it, sdl doesn’t kill the context. presumably,
people must anticipate this and do a good job of re-initing the gl context
in a way that won’t screw up if it’s still valid, or they must add switches
depending on what system things were compiled on.

Sam, if you’re reading this thread, could you mention your thoughts on
this? Since you’re the SDL God, how would you do it?

yes, please weigh in on this. i’d also be interested to hear from other
people who use opengl. would changing the setvideomode opengl context
method kill their app?>From: “Patrick McFarland” On 03-Jun-2004, Miles Vignol

18

If we were designing SDL from scratch, I would agree with you. However,
there are programs out there that just assume that the context was lost
if
under windows, and preserved otherwise. If the behaviour of
SDL_SetVideoMode suddenly changes, those programs would be broken.

would they? this issue resurfaced because the gears example is already
broken. anything not written specifically to run under windows should
work
fine, and even most of those that are specific to windows would probably
still work fine – rebinding textures and recreating display lists would
only cause a problem if you assumed your handles were bad without testing
them, and then the problems would only be inefficiency and not total
failure.

but maybe i’m missing something?

Well, it could be worst than wasting resources. When the context is
reset, all state is lost. There may be programs that assume that because
the context is gone texturing is disabled, for example.

BrunoOn Thu, 3 Jun 2004 13:23:22 -0700, Miles Vignol wrote:

From: “Bruno Mart?nez Aguerre” <@Bruno_Martinez>

19

wrote:

You can’t, thats why I suggested the function in the first place. You
cannot change behavior, as it breaks older apps. As it is, all SDL
apps assume the context is destroyed, and will reload textures; if it
isnt destroyed then apps will load their resources multiple times, which
is a very bad thing. The only way to add this functionality is to use
another function and add a flag for setvideomode along the lines of
SDL_OPENGL_NO_CONTEXT_KILL (which I forgot to mention in the last mail)

not all SDL apps. this isn’t an issue for mac or linux, unless i’m totally
misunderstanding the issue. this is only a problem under windows and only
for apps that resize. and i’m curious exactly how bad it is to reload
resources when you don’t need to.

You are misunderstanding the issue. If the context isnt destroyed and
reinitalized, then the textures are still loaded. Which means the app
no longer realizes that the old texture references are there, and makes
new ones, which means each texture is loaded twice, because the first
ones are still there.

Which you’re in the minority. Most apps usually do everything they can,
including depth changing, fullscreen and back, and resolution changing.
The only thing that is “broken” is that SDL has no way of not killing
the context even if the platform supports it (which is for consistancy
only). And we cant magically change the default, because it breaks all
existing SDL GL apps, which is quite a few.

SDL isn’t killing the context, it’s a side effect of running under
windows – again, unless i’m just totally not understanding things. so if
the platform DOES support it, sdl doesn’t kill the context. presumably,
people must anticipate this and do a good job of re-initing the gl context
in a way that won’t screw up if it’s still valid, or they must add switches
depending on what system things were compiled on.

SDL is killing the context on all platforms to make all platforms act
just like it does on Windows. Because of this, all SDL apps, no matter
what platform they were originally developed on and tested on,
automatically assume everything was blown away. You cannot change the
SDL API if it breaks these older apps. Period. Thats why I suggested
what I did.On 03-Jun-2004, Miles Vignol wrote:

From: “Patrick McFarland” On 03-Jun-2004, Miles Vignol

Sam, if you’re reading this thread, could you mention your thoughts on
this? Since you’re the SDL God, how would you do it?

yes, please weigh in on this. i’d also be interested to hear from other
people who use opengl. would changing the setvideomode opengl context
method kill their app?

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

–
Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040603/1bf5415e/attachment.pgp

20

If we were designing SDL from scratch, I would agree with you. However,
there are programs out there that just assume that the context was lost
if
under windows, and preserved otherwise. If the behaviour of
SDL_SetVideoMode suddenly changes, those programs would be broken.

would they? this issue resurfaced because the gears example is already
broken. anything not written specifically to run under windows should
work
fine, and even most of those that are specific to windows would probably
still work fine – rebinding textures and recreating display lists would
only cause a problem if you assumed your handles were bad without testing
them, and then the problems would only be inefficiency and not total
failure.

but maybe i’m missing something?

Well, it could be worst than wasting resources. When the context is
reset, all state is lost. There may be programs that assume that because
the context is gone texturing is disabled, for example.

That may not be an issue. Programs rebuild their environment (reset all
the states) when GL is re-initalized. That includings turning on and off
various features, including texturing. I think your example depends on
texturing having being turned on at one point… if an app depends on
texturing being on or off, then its going to be turing it on and off
itself.On 03-Jun-2004, Bruno Mart?nez Aguerre wrote:

On Thu, 3 Jun 2004 13:23:22 -0700, Miles Vignol wrote:

From: “Bruno Mart?nez Aguerre”

–
Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040603/c06ce79b/attachment.pgp