When I resize my window in any way (maximize, fullscreen, drag with
mouse), then the stuff in my graphics context (like tex objs, shaders,
display lists) is reset and I’m left looking at a white scene (the stuff
that isn’t displaylisted without textures).
Anyone know how to fix? Or is this a known bug in SDL? Is there a bug
list for SDL I can check in the future? What are the plans to fix?
I’ve downloaded a couple of other peoples sample apps and they do this
also so either it is really easy to misuse the API, or there’s a bug.
I’d be fine if there was an EVENT generated for context init and context
destroy - at least then I could know when to regen all my art. I guess I
could detect when the size changes…
thoughts?
This is a known annoyance. I don’t know if this is done on all platforms
or just Windows; it’s not documented, AFAIK.
I’ve offered to fix this, and Sam seemed to want a fix, but he hasn’t
responded to my questions of exactly how this should be fixed. Windows
must reset the OpenGL context when some settings are changed, so we need
an interface to indicate whether the context is reset; I need to know
what type of interface will be accepted. (This is one of my more major
patches that I’m maintaining a fork for, and as I hate maintaining
forks, I’d very much like to get this cleaned up and put into CVS.)
Sam, I understand that you’re busy; could you at least give an indication
that you havn’t forgotton about this? 
(I hadn’t thought of doing this via a message. Sam, would sending a
message indicating that the OpenGL context has been reset be a reasonable
way to do this that you’d consider applying to CVS? I like it because it
doesn’t add an entry point, just a message type, and it gives a way to
handle the theoretical future case where the OpenGL context is lost for
other reasons.)On Tue, Mar 11, 2003 at 09:28:26PM -0600, Kevin Meinert wrote:
When I resize my window in any way (maximize, fullscreen, drag with
mouse), then the stuff in my graphics context (like tex objs, shaders,
display lists) is reset and I’m left looking at a white scene (the stuff
that isn’t displaylisted without textures).
Anyone know how to fix? Or is this a known bug in SDL? Is there a bug
list for SDL I can check in the future? What are the plans to fix?
–
Glenn Maynard
This doesn’t seem to be a problem on Linux
try switching ;-)On Tuesday 11 March 2003 7:28 pm, Kevin Meinert wrote:
When I resize my window in any way (maximize, fullscreen, drag with
mouse), then the stuff in my graphics context (like tex objs, shaders,
display lists) is reset and I’m left looking at a white scene (the stuff
that isn’t displaylisted without textures).
Anyone know how to fix? Or is this a known bug in SDL? Is there a bug
list for SDL I can check in the future? What are the plans to fix?
I’ve downloaded a couple of other peoples sample apps and they do this
also so either it is really easy to misuse the API, or there’s a bug.
I’d be fine if there was an EVENT generated for context init and context
destroy - at least then I could know when to regen all my art. I guess I
could detect when the size changes…
thoughts?
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety. "
–Benjamin Franklin
Yeah, I know. but I want it work everywhere, and it sounds like
someone has a patch for it already (see previous email in the thread).
I guess since he wants to fix it, I’d appreciate it if you two can work
out the details.
thanks,
kevinOn Wed, 12 Mar 2003, Samuel wrote:
This doesn’t seem to be a problem on Linux
try switching 
On Tuesday 11 March 2003 7:28 pm, Kevin Meinert wrote:
When I resize my window in any way (maximize, fullscreen, drag with
mouse), then the stuff in my graphics context (like tex objs, shaders,
display lists) is reset and I’m left looking at a white scene (the stuff
that isn’t displaylisted without textures).
Anyone know how to fix? Or is this a known bug in SDL? Is there a bug
list for SDL I can check in the future? What are the plans to fix?
I’ve downloaded a couple of other peoples sample apps and they do this
also so either it is really easy to misuse the API, or there’s a bug.
I’d be fine if there was an EVENT generated for context init and context
destroy - at least then I could know when to regen all my art. I guess I
could detect when the size changes…
thoughts?
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
–——------------------------------——–*
Kevin Meinert //
home - http://www.vrsource.edu/~kevin \ /
music - http://subatomic.vrsource.org / __ /
_
_\
It would be very useful if I could set the window position using SDL (I
know how to do it per platform).
Is there plans to do this? or is it one of those “not supported
everywhere so we wont do it” kinds of things?
currently my 1024x768 window comes up with the upper left corner in the
center of the screen (I seem to have to move it every time I run it).
For X11, it is already there (via environment variables):
from http://www.libsdl.org/cvs.php:
Changes for Sun Sep 15:
1.2.5: Implemented support for SDL_VIDEO_WINDOW_POS=x,y
If you are a windows hacker, you could provide a patch for the Windows
sub-system.
cu,
JohannesOn Thursday 13 March 2003 15:44, Kevin Meinert wrote:
It would be very useful if I could set the window position using SDL (I
know how to do it per platform).
Is there plans to do this? or is it one of those “not supported
everywhere so we wont do it” kinds of things?
I’ve offered to fix this, and Sam seemed to want a fix, but he hasn’t
responded to my questions of exactly how this should be fixed. Windows
must reset the OpenGL context when some settings are changed, so we need
an interface to indicate whether the context is reset; I need to know
what type of interface will be accepted. (This is one of my more major
patches that I’m maintaining a fork for, and as I hate maintaining
forks, I’d very much like to get this cleaned up and put into CVS.)
Sam, I understand that you’re busy; could you at least give an indication
that you havn’t forgotton about this?
I haven’t forgotten about this, I’m just not sure what we can do without
drastically changing the API. Since we can’t guarantee that the context
won’t be reset, I’d almost like to say that if you change the video mode
you’ll have to recreate your OpenGL context, but obviously that’s not
really desirable for resizable windows.
(I hadn’t thought of doing this via a message. Sam, would sending a
message indicating that the OpenGL context has been reset be a reasonable
way to do this that you’d consider applying to CVS? I like it because it
doesn’t add an entry point, just a message type, and it gives a way to
handle the theoretical future case where the OpenGL context is lost for
other reasons.)
Yes, that’s acceptable, although I’d like to minimize it as much as possible.
It would be just as much as a hack as anything else, bandaiding a problem in
the OpenGL driver architecture under Windows.
For reference, does MacOS X have these problems as well?
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I haven’t forgotten about this, I’m just not sure what we can do without
drastically changing the API. Since we can’t guarantee that the context
won’t be reset, I’d almost like to say that if you change the video mode
you’ll have to recreate your OpenGL context, but obviously that’s not
really desirable for resizable windows.
That would be a big concession to lowest-common-denominator-syndrome;
it’s annoying in all cases. (I hate games that make me sit around as
it reloads textures simply because I changed the resolution.)
Yes, that’s acceptable, although I’d like to minimize it as much as possible.
It would be just as much as a hack as anything else, bandaiding a problem in
the OpenGL driver architecture under Windows.
Okay; I’ll rework my current code to this when I get a chance, and send
it here when it’s had some testing.
For reference, does MacOS X have these problems as well?
I don’t know; any Mac people around?On Fri, Mar 14, 2003 at 01:04:51AM -0800, Sam Lantinga wrote:
–
Glenn Maynard