Simulation timer with thread

SDL Development
1

I finally decided to try SLD_Thread to implement my timer.
I also decided that 100Hz must do. I ended up with this code:

Uint32 sync; // Set = SDL_Ticks() before running set = true

for(;;){
while( running==false ) SDL_Delay( 10 );
sync += frequency;
for(;;){
Uint32 now = SDL_GetTicks(); if( now > sync ) break;
Uint32 diff = sync-now; if( diff < 10 ) break;
SDL_Delay( 10 );
}
tick();
}

Any comments? This is a separate thread now, and tick() function
is does one simulation tick. The main thread keeps rendering ‘as
fast as possible’ with SDL_Delay(1) in the draw and poll events loop.

This at least appeared to work much better than with SDL_Timer.

Any further hints how to make simulation sync as well as possible
with rendering without slowing down when rendering slows down?

– Timo Suoranta – @Timo_K_Suoranta –

2

Any further hints how to make simulation sync as well as possible
with rendering without slowing down when rendering slows down?

Are you sure that a structure like this does not busy wait 3 out of 4
cycles (and the 4th time is very imprecise)? Try to benchmark how often it
skips the SDL_Delay with a variable.

If your thread busy waits often than it’s far better to simply do a busy
wait on SDL_GetTicks() in the main loop, with 10 ms you are too near to
the timer resolution capabilities to have a coherent behaviour in every
system (note, I’m not talking about different architecture but physical
machines… a slow machine will busy wait for sure on that code !)

Bye,
Gabry (gabrielegreco at tin.it)

3

I finally decided to try SLD_Thread to implement my timer.
I also decided that 100Hz must do. I ended up with this code:

Are you sure that a structure like this does not busy wait 3 out of 4
cycles (and the 4th time is very imprecise)? Try to benchmark how often it
skips the SDL_Delay with a variable.

There is no busy waiting at all in my code.

If your thread busy waits often than it’s far better to simply do a
busy wait on SDL_GetTicks() in the main loop, with 10 ms you are too
near to the timer resolution capabilities to have a coherent behaviour
in every system (note, I’m not talking about different architecture
but physical machines… a slow machine will busy wait for sure on
that code !)

Well, on slow machine my code will only wait every now and then, but
it will do processing every time when the loop runs. The tick(); call
calls the physics simulation code.

Uint32 sync; // Set = SDL_Ticks() before running set = true

for(;;){
while( running==false ) SDL_Delay( 10 );
sync += frequency;
for(;;){
Uint32 now = SDL_GetTicks(); if( now > sync ) break;
Uint32 diff = sync-now; if( diff < 10 ) break;
SDL_Delay( 10 );
}
tick(); // call physics simulation code
}

Now the actual question is that how should I synchronize the physics
simulation with rendering? I do not want to slow down the physics
simulation if the rendering is going too slow, but I am sure something
could be done to improve the synchronization. Any ideas?

– Timo Suoranta – @Timo_K_Suoranta --> From: Gabriele Greco

4

[…]

Now the actual question is that how should I synchronize the physics
simulation with rendering? I do not want to slow down the physics
simulation if the rendering is going too slow, but I am sure something
could be done to improve the synchronization. Any ideas?

Kobo Deluxe does one of three things, depending on the control/rendering
frame rate ratio:

1. Control frame rate > rendering frame rate:
	The control system is called several times per
	rendered frame.

2. Control frame rate == rendering frame rate:
	The control system is called once for each
	rendered frame.

3. Control frame rate < rendering frame rate:
	Several frames are rendered for each control
	system frame.

Kobo Deluxe does not sleep, but just runs constantly, trying to pump out
the maximum FPS - but that doesn’t really matter. It would work just as
well if an SDL_Delay(10) was inserted somewhere in the loop. (On targets
with retrace sync, it would possibly run slower, while on systems
without retrace sync, it might run smoother as a result of behaving
nicer in the eyes of the OS scheduler.)

Now, unless the rendering code does some form of interpolation between
the last two frames generated by the control system (as Kobo Deluxe does,
in order to get the smoothest possible animation), there’s obviously no
point in rendering several video frames per control system frame in case
3. Just go to sleep (SDL_Delay()), or do something else.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 22 January 2002 21:43, Timo K Suoranta wrote: