-- [ Picked text/plain from multipart/alternative ] I wholeheartedly agree On 5/3/07, Frank T. O'Connor <[EMAIL PROTECTED]> wrote: > > Re: /timers, That's won't fix sleep(1) returnning 9 out of 10 times in > 2ms. > I've tried it. What is does is no different from what the high res > multimedia timer does. > > The problem isn't getting a timer source at 1000Hz, it's more to do with > the implementation code. > > As someone on this list already mentioned, you need to use some additional > api functions ( like QueryPerformanceCounter() although there are others > ). > A mix of Sleep(1) + QueryPerformanceCounter will allow SS frame rates of > nearly 1k FPS while still switching back to the scheduler time to time. > > Ideally, we should be able to get 100tic/200fps w/o additional runtime > requirements from srcds.exe. That is, no need to run the whole system in > highres multimedia tic mode. I think that would be a noble goal. Doing > this > with a Sleep/QueryPerformanceCounter mix will get us close to 1k fps, > depending on the ratio of sleeps to QueryPerformanceCounter waits. > > I'd be happy with srcds.exe doing 100tic & > 250fps without external code > help. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of James Tucker > Sent: Wednesday, May 02, 2007 5:34 AM > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] Frame limiter code.... > > If you want REAL 1000Hz timer on Windows you don't want to use an > application to do it: > > http://www.microsoft.com/technet/sysinternals/information/bootini.mspx > > Specifically: > > */TIMERES=* > > * > > Sets the resolution of the system timer on the standard x86 multiprocessor > HAL (Halmps.dll). The argument is a number interpreted in hundreds of > nanoseconds, but the rate is set to the closest resolution the HAL > supports > that isn't larger than the one requested. The HAL supports the following > resolutions: Hundreds of nanoseconds Milliseconds > (ms) 9766 0.98 19532 2.00 39063 3.90 78125 7.80 The default resolution is > 7.8 ms. The system timer resolution affects the resolution of waitable > timers. Example: /TIMERES=21000 would set the timer to a resolution of 2.0 > ms. > > > Have a nice day. > > > Frank T. O'Connor wrote: > > Can anyone shed some light on which method srcds.exe is using on > > Windows to limit it's framerate (in repsect to FPS_MAX)? Is it simply > > doing a sleep() command, or some more complex algo? > > > > I know most of us are running some code (srcdsfpsboost.exe or others) > > to use winmm.lib to crank up the windows scheduler to 1000hz, but I > > doubt many of us realize how 'bad' and 'evil' this is. Forcing the > > scheduling quantum to 1ms isn't even solving our problem fully. Yeah, > > we're getting around 500hz, and we can see via stats 512fps, but > > really nothing should prevent us from getting 1000fps w/o wasting the > scheduler. > > > > winmm.lib, timeBeginPeriod, and all that jazz isn't going to fully > > correct the inaccurcy of a sleep(1) call returning 2ms later. And this > > is the inherent problem with this whole thing. I don't care if you run > > the process as REALTIME with the scheduler at 1000hz, sleep(1) will > > still more often than not return 1.9ms later. > > > > There are options to relying on sleep() exclusively (if this is what's > > done). There are options that don't require us overclocking the > > scheduler and forcing extra contex-switches, message pump pumping, > > cache dumps, and everything else that the scheduler does when it > > preempts. The options would be architecture specific, but the code would > be rather tight. > > > > Is there any interest in this? > > > > > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > --
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
