Am Mittwoch, 2. Mai 2007 schrieb [EMAIL PROTECTED]: > On Wed, 02 May 2007 14:51:17 -0400 Dennis Schridde > > <[EMAIL PROTECTED]> wrote: > >Am Mittwoch, 2. Mai 2007 schrieb Giel van Schijndel: > >> 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). > > > >Doesn't the scheduler distribute CPU time between all applications > >anyway? > >I don't think we can force it to give us all the CPU. > >Currently we only request as much as to keep a certain framerate. > >Which hits > >the limits on slow PCs, what I don't think is bad (since why would > >we like to > >drop the fps even more). > >The only reason we inserted the delay originaly, was because eg. > >laptop users > >don't need 100fps, but would like to keep their CPU idle instead. > >They can > >lower the framerate down to 1fps if they want, and that will be > >exactly what > >they get. No more, maybe less. > > > >So currently the real only issue is that there is no delay in the > >mainmenu. > > So then why remove it? It did not hurt anything correct? I have the strong (subjective) feeling that it is far more responsive now. If this is really so much of an issue, revert the change...
> If game pause, it should take up 0 CPU time. That's hardly possible, since you at least need to figure out that you are in pause state. ;) And then you might also want to get out of the pause, which would again require that the input and output systems are running... --Dennis
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
