Deji wrote:And no, don't set your refreshrate higher than your monitor can do at that given resolution.
You'll want to keep com_maxfps at 125 so you can exploit the physics bugs (faster strafe jumping), though it might produce the tearing some people complain about (esp. on LCD monitors with a high response time).
Just in case you don't know (I suspect you already do):
FPS and Refresh rate are seperate. Your monitor can have a refresh rate of 75Hz and will be showing 75 images per second, but the computer/game can be generating 125FPS quite happily in the background. All that happens is that the monitor misses displaying some frames which have been generated.
There are a few advantages to setting your FPS and Refresh to the same value, but it's not a big deal.
"Maybe you have some bird ideas. Maybe that’s the best you can do."
― Terry A. Davis
thanks Foo, yeah I knew about the difference between the refesh rate and the fps.
My intention was to set my com_maxfps and r_displayrate to 25 so that they would be in sync with each other. But i wasnt sure if my moniters refreshrate was going to hold it back from reaching 125 refresh rate.
When i set r_displayrate to 125, I do notice some image degridation...but i dont notice a smoother movement, so i just set it back to r_displayrate 0 and called it a day :\
What really makes things smoother is vsync (vertical refresh synchronization). Setting r_displayrefresh to the same value as com_maxfps doesn't accomplish what vsync does. Vsync completely eliminates tearing: when the videocard outputs more than 1 frame per vertical retrace (refresh) of the monitor, the image in the screen is split between two sequential frames that are (partially) displayed simultaneously.
Vsync is controlled by r_swapinterval in Q3 or can be enabled in most video card drivers. Although r_swapinterval looks significantly smoother in many cases, vsync should be disabled in Q3 because it causes great mouse input lag. For some reason this doesn't seem to be the case in CPMA, so i keep it enabled in that mod.
But it does (though you may not notice it): it waits for all GL operations to finish. You need this cvar set with some video drivers to prevent tearing, flickering, etc.
^misantropia^ wrote:You need this cvar set with some video drivers to prevent tearing, flickering, etc.
All common video cards that less than 4 or 5 years old can force vsync through (Windows) drivers. On a GF4 or Radeon 9800 r_finish 1 or 0 doesn't cause any visual difference, while r_swapinterval does effectively enable vsync like the drivers can do.
In a Q3 config that i downloaded the comments for r_finish said that this cvar affects mouse input lag, but that's only true when the cvar is actually functional (when you have a card+drivers that need/support it).
Tearing seems to be less obvious in vertex mode btw.
There was an interesting thread about game smoothness and the swapinterval command on the osp forums (it was osp related). I will link ya when the forums come back.
Eraser wrote:On average vsync cuts your effective framerate in half though.
That depends on what your refresh rate is. Smart people set their monitor to 120 Hz or 100 Hz. I would only recommend using vsync in CPMa though (the only mod i know that doesn't suffer from input lag caused by vsync).
@dzjepp: i posted in that thread in the OSP forum too. There isn't any extremely useful info in that thread. Just someone complaining about the forced com_maxfps 125 in OSP.