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: [email protected] 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
