Dennis Schridde schreef:
> Am Mittwoch, 2. Mai 2007 schrieb Giel van Schijndel:
>   
>> Dennis Schridde schreef:
>>     
>>> Am Mittwoch, 2. Mai 2007 schrieb [EMAIL PROTECTED]:
>>>       
>>>> Why was this removed?
>>>>
>>>> "  SDL_Delay(20);  //Added to prevent busy loop, and get CPU time
>>>> back when paused! "
>>>>
>>>> WZ eats all CPU time now, even when paused?
>>>>         
>>> Of course not...
>>> We still have the SDL_framerateDelay...
>>>       
>> Which does not call SDL_Delay if we don't reach our requested frame
>> rate, and that in turn results in CPU hogging. Apart from that I believe
>> that SDL_framerateDelay doesn't get called in the menus. So I think we
>> at least need an explicit SDL_Delay(1) call, maybe only if
>> SDL_framerateDelay didn't call SDL_Delay.
>>     
> I didn't recognize any sideeffects, but it might be possible that we now eat 
> the CPU in the menu or on slow computers. Maybe we should setup a 
> minimum-delay for sdl-framerate.
> SDL_Delay(1) wont work as expected afaik, since the minimum tick precission 
> guaranteed by SDL is 10ms.
>   
Almost correct, that is the precision of the kernel's CPU scheduler
although I believe most Linux versions 2.6 have a time slice of 1 msec.
Apart from that an SDL_Delay(1) call is just an explicit call to yield
the current process so the kernel can use the remaining CPU time and
divide it among other processes.

Also SDL_Delay guarantees nothing about the amount of time that will be
waited, only that it will be "at least" the time you specify. So a call
like SDL_Delay(20) could very well result in losing CPU for 750 ms (if
the OS's scheduler decided so).

I believe that on GNU/Linux SDL_Delay is implemented by one of the
sleep, nanosleep functionset. (Just look those up in your manpages or C
library documentation)
> After looking through that mess (imo) of a mainloop, I think I will try to 
> refactor it asap. I currently have a fully event based system in mind, which 
> I tested in the framework I set up for my work on the terrain renderer.
>   
An event driven system seems a lot nicer indeed. Although some parts
probably still require to be run once every frame or something (for
example the sound code requires an audio_Update/sound_Update call every
now and then to keep buffers and sources filled&synced).

-- 
Giel

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to