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
