'ello, mates.
I just recently switched my game library to SDL 1.3 for the
support of OpenGL +3.x and easier-to-handle rendering contexts. The
switch went quite nicely, for the most part… but I’ve found that
whenever I enlarge my window, my entire scene goes black and keyboard
input stops being handled. In short, my program becomes unresponsive.
I’ve read about contexts being destroyed on resizes, but I was under
the impression that this is no longer the case in SDL 1.3 (and it
never was for me using 1.2 either).
As a snippet (I've never used a mailing list before, so forgive
me if this is not the standard approach to solving this problem), I’ve
included my code for handling the window resize. It’s nothing verbose
or spectacular:
/* The window has raised an event. /
case SDL_WINDOWEVENT:
{
switch(event.window.event)
{
case SDL_WINDOWEVENT_RESIZED:
{
/ Update the viewport. */
windowWidth = event.window.data1;
windowHeight = event.window.data2;
glViewport(0, 0, windowWidth, windowHeight);
/* Acknowledge any callbacks. */
for(GLint i = 0; i < windowResizedFuncs.size(); ++i)
windowResizedFuncs[i](windowWidth, windowHeight);
} break;
}
} break;
I spend a lot of time on Freenode in #SDL, and I haven't found
someone who has been able to help me with this situation. I’ll
appreciate any insight I can get.
Information on my computer:
Model: Dell Studio 1747
CPU: Intel i7 Quad
OS: Slackware64 13.37
WM: Scrotwm (tiling) – I thought that this might be the problem,
since my window isn’t set to be resizable, but a tiling window manager
does what it pleases with the windows.
Other SDL APIs in use: SDL_TTF (worked fine, even after switching
everything to 1.3)
Thanks!
Jeaye
I think OpenGL automatically cleans up the textures after a resize, but I’m
not positive. After a resize, just load up the textures again.On Wed, May 11, 2011 at 1:09 AM, wrote:
'ello, mates.
I just recently switched my game library to SDL 1.3 for the support of
OpenGL +3.x and easier-to-handle rendering contexts. The switch went quite
nicely, for the most part… but I’ve found that whenever I enlarge my
window, my entire scene goes black and keyboard input stops being handled.
In short, my program becomes unresponsive. I’ve read about contexts being
destroyed on resizes, but I was under the impression that this is no longer
the case in SDL 1.3 (and it never was for me using 1.2 either).
As a snippet (I've never used a mailing list before, so forgive me if
this is not the standard approach to solving this problem), I’ve included my
code for handling the window resize. It’s nothing verbose or spectacular:
/* The window has raised an event. /
case SDL_WINDOWEVENT:
{
switch(event.window.event)
{
case SDL_WINDOWEVENT_RESIZED:
{
/ Update the viewport. */
windowWidth = event.window.data1;
windowHeight = event.window.data2;
glViewport(0, 0, windowWidth, windowHeight);
/* Acknowledge any callbacks. */
for(GLint i = 0; i < windowResizedFuncs.size(); ++i)
windowResizedFuncs[i](windowWidth, windowHeight);
} break;
}
} break;
I spend a lot of time on Freenode in #SDL, and I haven't found someone
who has been able to help me with this situation. I’ll appreciate any
insight I can get.
Information on my computer:
Model: Dell Studio 1747
CPU: Intel i7 Quad
OS: Slackware64 13.37
WM: Scrotwm (tiling) – I thought that this might be the problem, since my
window isn’t set to be resizable, but a tiling window manager does what it
pleases with the windows.
Other SDL APIs in use: SDL_TTF (worked fine, even after switching
everything to 1.3)
Thanks!
Jeaye
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I’m quite certain the texture loading is not the problem here.
I did some tests using a different window manager, and I didn’t have
this problem at all. It seems to be that, given a tiling window
manager that dynamically sizes windows, regardless of their flags, SDL
1.3 apps freeze up when made bigger. The resizing worked perfectly on
a non-tiling window manager (after setting the resizable flag), and it
continues to crash on Scrotwm (even with the resizable flag).
Quoting Alex Barry <alex.barry at gmail.com>:> I think OpenGL automatically cleans up the textures after a resize, but I’m
not positive. After a resize, just load up the textures again.
I'm quite certain the texture loading is not the problem here. I did
some tests using a different window manager, and I didn’t have this problem
at all. It seems to be that, given a tiling window manager that dynamically
sizes windows, regardless of their flags, SDL 1.3 apps freeze up when made
bigger. The resizing worked perfectly on a non-tiling window manager (after
setting the resizable flag), and it continues to crash on Scrotwm (even with
the resizable flag).
Quoting Alex Barry <alex.barry at gmail.com>:
I think OpenGL automatically cleans up the textures after a resize, but
I’m
not positive. After a resize, just load up the textures again.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Howdy,
I think that SDL on windows is the source of the problem. I might be
mistaken given I have only used SDL 1.3, but in linux we can resize windows
or toggle fullscreen in almost no time at all, whereas in windows it has
been said that “the opengl context goes away/is destroyed” but I don’t know
if this is a behavior inherent of windows or of SDL 1.2 (and maybe SDL
1.3).
Cheers,
ChristianOn Wed, May 11, 2011 at 2:11 PM, wrote:
If I remember correctly, destruction of OpenGL context is platform
dependent. So on some platforms you might keep the same context after
a resize and on other platforms it might be destroyed. If you’re not
absolutely certain that your context isn’t destroyed, it would be a
good thing to check.–
Terry Welsh
mogumbo ‘at’ gmail.com
www.reallyslick.com
Message: 4
Date: Wed, 11 May 2011 12:11:39 -0600
From: jeaye@arrownext.com
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL 1.3 + OpenGL 3.x + Resize window
Message-ID: <20110511121139.kzuebtgiw4skcc84 at arrownext.com>
Content-Type: text/plain; ? ? ? charset=ISO-8859-1; ? ? DelSp=“Yes”;
? ? ? ?format=“flowed”
? ? ? I’m quite certain the texture loading is not the problem here.
I did some tests using a different window manager, and I didn’t have
this problem at all. It seems to be that, given a tiling window
manager that dynamically sizes windows, regardless of their flags, SDL
1.3 apps freeze up when made bigger. The resizing worked perfectly on
a non-tiling window manager (after setting the resizable flag), and it
continues to crash on Scrotwm (even with the resizable flag).
Quoting Alex Barry <alex.barry at gmail.com>:
I think OpenGL automatically cleans up the textures after a resize, but I’m
not positive. ?After a resize, just load up the textures again.
Quoting Christian Leger <chrism.leger at gmail.com>:
Howdy,
I think that SDL on windows is the source of the problem. I might be
mistaken given I have only used SDL 1.3, but in linux we can resize windows
or toggle fullscreen in almost no time at all, whereas in windows it has
been said that “the opengl context goes away/is destroyed” but I don’t know
if this is a behavior inherent of windows or of SDL 1.2 (and maybe SDL
1.3).
Cheers,
Christian
Chrisitian,
I appreciate your reply. I’m, however, on Slackware64 13.37 and
my window manager is Scrotwm (it seems to be the problem). Resizing
works perfectly fine using KDE, BlackBox, and XFCE (which are all
floating window based), but it does not work in Scrotwm, which is a
tiling window manager that dynamically resizes/arrange windows to
match specific patterns.
Quoting Terry Welsh :
If I remember correctly, destruction of OpenGL context is platform
dependent. So on some platforms you might keep the same context after
a resize and on other platforms it might be destroyed. If you’re not
absolutely certain that your context isn’t destroyed, it would be a
good thing to check.
Terry Welsh
mogumbo ‘at’ gmail.com
www.reallyslick.com
Terry,
It’s not my ‘platform’ that is the problem, I think… since
resizing works nicely when I use a floating window manager. I’m
willing to say that this is an SDL 1.3 disorder, where it fails to
cooperate with tiling window managers. I’d like to point out that SDL
1.2 had no trouble with tiling, and this behavior only arose after
switching to SDL 1.3.
Thank you for all of your replies. What are your opinions? What is the
suggested course of action?
Hi,
I suspected you were in linux (tiling WM doesn’t connote windows) but I just
had a reflex reaction to point out that this misbehaves in windows :-)On Wed, May 11, 2011 at 4:36 PM, wrote:
Quoting Christian Leger <@Christian_Leger>:
Howdy,
I think that SDL on windows is the source of the problem. I might be
mistaken given I have only used SDL 1.3, but in linux we can resize
windows
or toggle fullscreen in almost no time at all, whereas in windows it has
been said that “the opengl context goes away/is destroyed” but I don’t
know
if this is a behavior inherent of windows or of SDL 1.2 (and maybe SDL
1.3).
Cheers,
Christian
Chrisitian,
I appreciate your reply. I’m, however, on Slackware64 13.37 and my
window manager is Scrotwm (it seems to be the problem). Resizing works
perfectly fine using KDE, BlackBox, and XFCE (which are all floating window
based), but it does not work in Scrotwm, which is a tiling window manager
that dynamically resizes/arrange windows to match specific patterns.
Quoting Terry Welsh :
If I remember correctly, destruction of OpenGL context is platform
dependent. So on some platforms you might keep the same context after
a resize and on other platforms it might be destroyed. If you’re not
absolutely certain that your context isn’t destroyed, it would be a
good thing to check.
Terry Welsh
mogumbo ‘at’ gmail.com
www.reallyslick.com
Terry,
It’s not my ‘platform’ that is the problem, I think… since resizing
works nicely when I use a floating window manager. I’m willing to say that
this is an SDL 1.3 disorder, where it fails to cooperate with tiling window
managers. I’d like to point out that SDL 1.2 had no trouble with tiling, and
this behavior only arose after switching to SDL 1.3.
Thank you for all of your replies. What are your opinions? What is the
suggested course of action?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org