Loren Osborn wrote:
at earliest convienience. What sleep(0) or usleep(0) do in Unix/Linux I’m
not so sure of… (May yeild… may act as NOP… haven’t tried it…)
sleep(0) returns instantly on Linux (always good to have the glibc
source code floating around ;))–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
Something that I have seen done, with varying amounts of sucess is something
like: (Please excuse my pseudo-code)starttime = gettimeofday()
if ( x < 10ms ) /* Give other processes a change */
sleep(0)
I don’t think this is guaranteed to work very well. Historically sleep(0) has
meant “give up my time slice” but was never documented, and I won’t complain
if it returns right away (I hear it does is some places).
Try sched_yield() instead.
} else {
usleep((x/(10ms))*10000us)
usleep() and nanosleep() want to sleep at least the requested
interval, but select() may timeout before its time, so it should be safer.
The problem is that sleep(0) isn’t as predictable/portable as we might
hope… If I remember correctly from FileNET, something like this works
reasonably well on WinNT, but I wouldn’t trust it on Linux.
Oh, c’mon… like any code is going to be totally crossplatform anyways. No matter what sort of code you’re dealing with, be it
audio/video/timer/networking, it’ll never be crossplatform without a certain amount of tweaking, so why even bother? Let’s just
treat each platform as a separate kettle of fish and be done with it.
Crossplatform compatibility is not a natural occurence, this is why SDL exists. (Besides, if code was inherantly more
crossplatform, you’d be out of a job!) So expect it to be full of various wierd hackies…
Something else which I seem to be blenderizing is what this is actually about - timing (in terms of operations per second) or
timers (in terms of hooking and repeating action)… I got slipped up and therefore started yabbering on about hardware timers.
Whee. I wouldn’t mind seeing timing functions, something like this:
SDL_StartTiming(1);
while (!done)
{
/* shit happens */
SDL_GL_SwapBuffers(); // or your preferred flip command
SDL_IncrementTimingFrames(1);
}
SDL_EndTiming(1);
SDL_ReportTiming(1);
Which would wrap hardware timing functions etc. as necessary.
Anybody else think that this’d be cool? Granted that you can do it with the current timing apparatus… I tried it and my assistant
programmer on Kosmos Online went up in arms and started muttering about death threats because it was low resolution. What I’m
suggesting is very hi-res, and we could use hardware timing dinguses.
Regards,
-Loren
Good to see you on the ML by the way. I still remember that amazing looking sandwich 
Cheers,
Nich