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
