Hi,
I am currently not delaying by hand in my main loop and just hope for
SDL_GL_SwapWindow() to sync with the screen. Which also works perfectly
fine for as long as the application is in the foreground.
However if the application is minimized or something else hides the
window completely the application will instantly consume 100% CPU. I
assume that’s because that function becomes a noop of some sort.
What’s the best way to deal with that?
Regards,
Armin
You can handle the minimize event and just wait for the restore event.On Sat, Mar 5, 2011 at 4:32 AM, Armin Ronacher <armin.ronacher at active-4.com>wrote:
Hi,
I am currently not delaying by hand in my main loop and just hope for
SDL_GL_SwapWindow() to sync with the screen. Which also works perfectly
fine for as long as the application is in the foreground.However if the application is minimized or something else hides the window
completely the application will instantly consume 100% CPU. I assume that’s
because that function becomes a noop of some sort.What’s the best way to deal with that?
Regards,
Armin
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
Here are the window events for reference:
http://wiki.libsdl.org/moin.cgi/SDL_WindowEventIDOn Sat, Mar 5, 2011 at 10:11 AM, Sam Lantinga <@slouken> wrote:
You can handle the minimize event and just wait for the restore event.
On Sat, Mar 5, 2011 at 4:32 AM, Armin Ronacher < armin.ronacher at active-4.com> wrote:
Hi,
I am currently not delaying by hand in my main loop and just hope for
SDL_GL_SwapWindow() to sync with the screen. Which also works perfectly
fine for as long as the application is in the foreground.However if the application is minimized or something else hides the window
completely the application will instantly consume 100% CPU. I assume that’s
because that function becomes a noop of some sort.What’s the best way to deal with that?
Regards,
Armin
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
Hi,On 3/5/11 7:11 PM, Sam Lantinga wrote:
You can handle the minimize event and just wait for the restore event.
That does not work because if a window moves over my window the same
thing happens. It does not have to be minimized.
Regards,
Armin
Oh, interesting. Can you enter a bug at http://bugzilla.libsdl.org and
include what platform you’re seeing this behavior on?
Thanks!On Sat, Mar 5, 2011 at 11:14 AM, Armin Ronacher <armin.ronacher at active-4.com wrote:
Hi,
On 3/5/11 7:11 PM, Sam Lantinga wrote:
You can handle the minimize event and just wait for the restore event.
That does not work because if a window moves over my window the same thing
happens. It does not have to be minimized.Regards,
Armin
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
Hi,
You can handle the minimize event and just wait for the restore event.
That does not work because if a window moves over my window the same thing happens. It does not have to be minimized.
Although you may not need to actually do this if there is a better method,
you could try to run a phase locked loop (PLL).
Basically, you measure or calculate the approximate expected period
of the synchronising signal P, and change your algorithm so you only
call SDL_GL_SwapWindow() at time P - E where E is suitably small,
eg 10% of P.
By keeping the timer running, you will measure E’, the time waiting
for SDL_GL_SwapWindow() to return, and if E’ is close to zero,
something is wrong!
So (a) you can ensure you don’t hog the CPU by using a timer to schedule
the Swap call, and (b) you can detect when the signal is abnormal.
Abnormal might not be “window minimised or covered up”: it might
be a resolution change or anything else (dog ate monitor cable …)
This technique is quite general, it can be used to synchronise with
any external periodic event. In my case it was used to synchronise
with mains Alternating Current to control the intensity of lights.
It is also used to lock onto radio signals (Super-heterodyne circuit
I think).
PLL should be used in professional games = simulations to ensure a constant framerate.
To my knowledge it isn’t. Games are a bit tricky because load varies suddenly,
so PLL needs to be combined with load prediction. If you have a sudden change
(a big explosion or whatever) it should be rendered with minimal quality first,
the load measured and the quality pushed up until the load is just enough
to fit in the frame time.
The usual way to handle this problem in simulations is to throw huge amounts
of money at the simulator … hence the small difference between Microsoft
Flight Simulator and an passenger aircraft simulator.
Just for fun: I recall some years ago seeing one of the first 3D movies made,
shown on an IMax screen. This was real footage taken on the International
Space Station. At the beginning a satellite is being deployed an there’s
an accident and the astronaut goes flying off into space, a-la 2001…
Yea, its real footage alright … real footage of a simulated accident.
Later the real footage of the actual deployment including docking of
the space shuttle is shown. [The point: the simulation was itself 3D and
indistinguishable from the real thing … well it fooled me anyhow :]On 06/03/2011, at 6:14 AM, Armin Ronacher wrote:
On 3/5/11 7:11 PM, Sam Lantinga wrote:
–
john skaller
@john_skaller
Hi,On 3/6/11 11:03 AM, john skaller wrote:
Basically, you measure or calculate the approximate expected period
of the synchronising signal P, and change your algorithm so you only
call SDL_GL_SwapWindow() at time P - E where E is suitably small,
eg 10% of P.
I am doing something even simpler currently. I artificially limit it
additionally to 200Hz by delaying with SDL_Delay. That works good
enough for the time being but it’s somewhat of a hack.
Regards,
Armin
Hi,
Basically, you measure or calculate the approximate expected period
of the synchronising signal P, and change your algorithm so you only
call SDL_GL_SwapWindow() at time P - E where E is suitably small,
eg 10% of P.
I am doing something even simpler currently. I artificially limit it additionally to 200Hz by delaying with SDL_Delay. That works good enough for the time being but it’s somewhat of a hack.
That depends on whether you consider the frame sync signal to be reliable or not.
Your OP suggests that signal isn’t reliable. Using a PLL to track its frequency and
status IS reliable, though it takes some experimentation to get the tracking
parameters right.
Note on my Mac the Nehe demos stop dead when in a window and the window
loses mouse focus. I have no idea why, but that’s another case.
Different platforms may behave differently.
And as mentioned a PLL can also assist in overload resulting in overshooting
your time frame. In turn this allows higher quality graphics rendering to be deployed
when there is time and downgraded when there isn’t. I guess this applies to mixing
sound as well, where timing is probably even more critical than graphics.
Ultimately real time systems (such as games) can only work by monitoring
(polling/sampling) external events and attempting to synchronise with them, and this also
includes noise rejection. Self-synchronising calls (as SDL_GL_SwapWindow() seems to be)
and interrupt driven code seems to be the easy way for simple applications but in the
long run for more complex applications actually gets in the way, there’s more and more
tendancy to buffer away these locked operations (eg signals setting a flag, or synchronised
calls being de-synchronised by putting them in a thread) and using a single synchronisation
source (namely a timer).
This is basically what an Operating System does. And at the heart of it, a game is
a Real Time operating system :)On 07/03/2011, at 1:19 AM, Armin Ronacher wrote:
On 3/6/11 11:03 AM, john skaller wrote:
–
john skaller
@john_skaller