stirner wrote:Up until now I had been using an external framerate limiter because FRAPS shows drastic improvements in frame frequency stability as opposed to the Source engine's internal fps_max cvar: i.imgur.com/Bb4nGOf.png vs. i.imgur.com/xVmoO3D.png
This is normal: External framerate capping is superior if your goal is motion fluidity. For example, VSYNC ON double-buffered, combined with a powerful GPU, can lead to ultrasmooth motion that looks wonderful with strobing.
However, best possible frame frequency stability isn't equal to best possible input lag.
stirner wrote:with an internal cap:
0ms-?ms: gather input data
?ms: initiate rendering of frame #1
?ms: finish rendering
10ms: switch buffers
10-?ms: gather input data
?ms: initiate rendering of frame #2
?ms: finish rendering
20ms: switch buffers
etc.
This is incorrect during VSYNC OFF. The switch buffers often happens virtually instantly upon finishing rendering. The tearline occurs at the raster location where the screen is "still scanning". This is what happens with either VSYNC OFF or GSYNC:
0ms-?ms: gather input data
?ms: initiate rendering of frame #1
?ms: finish rendering
AND switch buffers
10-?ms: gather input data
?ms: initiate rendering of frame #2
?ms: finish rendering
AND switch buffers
20-?ms: gather input data
?ms: initiate rendering of frame #3
?ms: finish rendering
AND switch buffers
The image data gets onto the cable within microseconds of the buffer switch. It does not occur at grandular frame refresh intervals. There is a concept known as the "horizontal scanrate" (number of scanlines drawn per second), which carried over from the old CRT days. Data is transmitted at a finite speed over the cable. At 120Hz 1080p, the horizontal scanrate is typically about 135KHz (as seen in Custom Resolution Utilities), which is 135,000 rows of pixels per second. One row of pixels get pushed into the video cable in 1/135000th of a second. You can do a buffer flip at any time during a 1/135000th second granularity, rather than a 1/120th sec granularity. This is how tearlines occur, they are essentially refresh-cycle "
splices" between an old refresh and a new refresh, caused by a buffer flip in the middle of a refresh cycle!
stirner wrote:When exactly does the internal code initiate rendering?
Game engine dependant. Some of them do just-in-time rendering techniques, while others just simply begin rendering immediately after the previous frame.
stirner wrote:The GPU naturally needs time to render a frame, varying amounts of time at that - how does the code decide that it is time for the rendering process to be initiated in order for the rendering interval to be maintained? I mean, the game cannot know how long the GPU will need to render a certain frame.
This is true, and a common cause of stutter. Fortunately, adjacent frames usually have very similiar scene complexities (you're usually viewing in the same direction or almost the same direction), so frametimes are usually similar, but it varies by game engine. If you hate this, just simply use external framerate capping to smooth things out, if smoother is more important than less lag. Those are often two opposing goals.
stirner wrote:If the GPU really did delay swapping of buffers instead of delaying the rendering with an external cap, then the simulation would have to look extremely smooth, less microstutter-y and frame tearing should be mostly unnoticeable as long as rendering finishes within the capped interval
Again,
smoothness (consistent frame delivery) goal is different from low lag goal. They can be sometimes mutually opposing goals as a trade-off.
If you want perfect fluidity on a non-GSYNC monitor, and don't care about lag, use the following:
1. VSYNC ON (external capping)
2. Double buffering, not triple buffering
3. Gaming mouse with good 1000Hz mode
4. Powerful enough GPU
5. Frame rate exactly matching refresh rate.
6. Adjust detail down until framerate stays capped out without dropping.
7. Run game engines that are capable of capping out at frame rates matching refresh rate.
Motion can look really beautiful (Sega arcade or Nintendo 8-bit platformer style smoothness of scrolling) when you combine #1-7 simultaneously. It especially looks really good with motion-blur-reducing strobe-backlight technologies (LightBoost, ULMB, Turbo240, and BENQ Blur Reduction).
I actually use VSYNC ON for solo gameplay when lag is not critical since motion on strobe backlights (LightBoost/ULMB) looks nicer with VSYNC ON.