I’ve recently started putting together a framwork for SDL apps (it could
logically be any app, but I’m building SDL apps with it) based on control
objects which loop over a list of objects and act on them, e.g. a DrawController
which acts on Drawable objects and draws them.
So, my main loop looks something like this:
for every controller
do pre-frame operations
for every controller
do current-frame operations (in my test app, this includes flipping the
frame buffer in a DrawController method)
for every controller
do post-frame operations
SDL_Delay(50);
The app compiles successully and in a test environment draws a red box etc etc.
However, once the box has been drawn, nothing else happens. The execution
continues (debug messages still print to the console) but the the box doesn’t
move and the window stops rendering properly - the Windows hourglass cursor is
displayed if I put the cursor inside of the SDL window rather than the SDL
pointer, and if I drag the console over the title bar, it leaves ‘trails’ rather
than repainting properly.
Has anyone else experienced a similar problem? Is there something I’ve missed? I
have a similar app which works on a simple loop and it works perfectly.
Your abstract sounds pretty good, but from the results I’d guess your buffer isn’t actually getting flipped. Also, is your program checking for events? Not doing so can make Windows angry…> ----- Original Message -----
From: fred.the.fish@gmail.com (Harry Wagstaff)
To: sdl at libsdl.org
Sent: Wednesday, October 22, 2008 2:55:10 PM
Subject: [SDL] SDL Window ‘not responding’?
I’ve recently started putting together a framwork for SDL apps (it could
logically be any app, but I’m building SDL apps with it) based on control
objects which loop over a list of objects and act on them, e.g. a DrawController
which acts on Drawable objects and draws them.
So, my main loop looks something like this:
for every controller
do pre-frame operations
for every controller
do current-frame operations (in my test app, this includes flipping the
frame buffer in a DrawController method)
for every controller
do post-frame operations
SDL_Delay(50);
The app compiles successully and in a test environment draws a red box etc etc.
However, once the box has been drawn, nothing else happens. The execution
continues (debug messages still print to the console) but the the box doesn’t
move and the window stops rendering properly - the Windows hourglass cursor is
displayed if I put the cursor inside of the SDL window rather than the SDL
pointer, and if I drag the console over the title bar, it leaves ‘trails’ rather
than repainting properly.
Has anyone else experienced a similar problem? Is there something I’ve missed? I
have a similar app which works on a simple loop and it works perfectly.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Mason Wheeler <masonwheeler yahoo.com> writes:
Your abstract sounds pretty good, but from the results I’d guess your buffer
isn’t actually getting
flipped. Also, is your program checking for events? Not doing so can make
Windows angry…
Turns out that not only was the program not checking for events (fixing this
made the app respond again but the rectangle still didn’t move), but I actually
wasn’t moving the destination rectangle (oops!).
I was setting the target rectangle to what I assumed was a copy of the source
rectangle but I have no idea what it ended up being set as because, although I
was adding to the x value of the rectangle, nothing was moving. Once this was
fixed the rectangle set off on its merry way across my screen.
Thanks!
Has anyone else experienced a similar problem? Is there
something I’ve missed?
Problem with something like this is it could be a number of things but I’d look at getting stuck in a loop. Last time this happened to me I’d been daft enough to compare a signed int to an unsigned int which, at least in MinGW, means they get compared as unsigned ints so “if (-3 < 126)” would have been interpreted as “if (4,294,967,292 < 126)”. I can’t remember exactly how it went but it was counting from a fairly low number towards (2^32)-4 reading bytes all the way, I’m sure it would have produced some hilarious error if I’d left it.
Either way, this is the point at which I start stepping through things and using variable watches to see just what the numbers are doing.— On Wed, 10/22/08, Harry Wagstaff <fred.the.fish at gmail.com> wrote: