SDL_Delay()

according to MSDN,

quote:
The Sleep function suspends the execution of the current thread for at least the specified interval.

I get the impression that the main purpose of the sleep function is to give up your time slice for other processes so that your otherwise CPU intensive programs are more multi-task friendly...

See what happens when you use SleepEx

EDIT: This assumes that you are really trying to create a delay for some reason and your aren't attempting to impliment frame-rate independence... if you're not doing a delay, do what Goldfish says

[edited by - tempuself on November 11, 2003 12:56:41 PM]

Why not use a Sleep(0) inside a busy wait to avoid thrashing it too much...

while (clock() < clocksleep_end) { Sleep( 0 ); } 

- Scott "me22" McMurray
( email/MSN me22@fastmail.ca ICQ 37213887 )

quote:
Why not use a Sleep(0) inside a busy wait to avoid thrashing it too much...
while (clock() < clocksleep_end) { Sleep( 0 ); }

According to this:

quote:
Sleep(1) it doesn''t sleep for a millisecond, it sleeps for 34

clock() will be a good bit past clocksleep_end by the time it gets back.

Ro_Akira

As far as I can tell...

a) Sleep(0) returns immediately
b) SleepEx behaves he same way as Sleep

I''m doing this to limit frame rate (my movement is based on elapsed time like it should be). Right now:

LONGLONG Time;
QueryPerformanceCounter((LARGE_INTEGER *)&Time);
ElapsedTime=(FLOAT)(Time-LastTime)*TimerFrequency;
if(ElapsedTime<1.0f/60.0f)
{
// Sleep function would be nice to use here to
// avoid hogging CPU.
continue;
}
LastTime=Time;

It''s not big deal if I can''t get it, it''d just be nice to have my program use 0% of he CPU instead of 99% :-)
-Billy

quote:
Sleep(0) returns immediately

Not necessarily.

quote:
...a value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution.... - MSDN

If there are other other threads ready to run, they'll eat your time slice.

In any case, how would sleep (0) returning immediately help you?

Ro_Akira

[edited by - Ro_Akira on November 11, 2003 4:41:31 PM]

quote:Original post by Magmai Kai Holmlor
It's not best to base movement on elapsed time, this is undeterministic and not repeatable. Consider what it takes to replay a saved 'demo'. All of the timing the second iteration must match the original in order for the exact same thing(s) to occur - this will not happen in practice.

To limit the frame-rate, measure the frame-rate and if/when the frame-rate exceeds your cut-off, do a Sleep(1).

I've been thinking about this sense I read it yesterday and I can't really see why it's the "best" method... I agree that the second iteration of a sequence probably would not match the original exactly, and that your method would solve that problem... but does it have any other advantages over frame-rate independent movement?

(correct me if I'm wrong but...) it seems to me that this Sleep(1) method would not work smoothly on as many machines as an elapsed time method would...

For example, in my cheap space invaders clone, all the laser blast movements are a function of time so that one blast will travel from the bottom of the window to the top (400 pixels) in one second (or close to a second)
On machines that are too slow, this will look jerky. However, there are no machines that are so fast that the laser blast will go by too fast to see.

Now, if I tried to implement the Sleep(1) method, my game still would not run on slower machines... But now, I've introduced the possibility of a machine being so fast that you can't see my laser at all... Or am I missing something?



[edited by - tempuself on November 12, 2003 4:11:36 PM]

Hello,
It seems elapsed time movement is the best actually. Considering that if you play a game that is about 10 year old on a newer computer that can run it, sometimes the games runs so incredibly fast the player is dead before they''ve even been able to control.

As well, should games cap their frame rates say to...70 frames per second? Well as a lot of id software games show, you can have a demo that runs accurately for a game that runs hundreds of frames per second. It all depends on how you save, load, and replay the demo. It IS deterministic AND repeatable.

Frame rate dependent movement is not the way to go...sometimes though on making some clone game it works well...if you cap the frame rate....
As for repeatable motion, think about interpolation...like with animation. You pick the start and end points of movement, and the start and end points in time and interpolate if you hit different frames. Definitely not the most complex aspect of saving and reloading/replaying a demo.

-Aeroum