Gamesager wrote: ↑03 Apr 2025, 11:57
Yeah, the point of this was just to get back up to the 237 cap instead of 225. For halo I am using rtss reflex cap set to 237 with the in game minimum frame rate set above that and it feels much better than the auto cap for me at least.
Yes, the Reflex/ULLM cap is pretty conservative.
You can use tighter capping for extremely-accurate framepacing (e.g. just 1% below) or looser capping for looser framepacing (e.g. 5% below). The problem is framepacing is jittered by many things, even by things like power management.
That said, if you use the same capping mechansim (e.g. in-game capping mechanism, or external driver/RTSS-based capping mechanism)
It is the latency differential of the shortest frametimes. (1/225)-(1/237) = 0.23ms difference. Assuming average lag (top/center/bottom lags: Screen center instead of worst-case bottom-of-screen-edge lag), screen center is halftime (0.5/0.23ms) = ~0.1ms difference!
There's bigger latency differences between different capping mechanisms (e.g. internal vs external) than there is with these capping numbers (assuming using same capping mechanism). In this case, you've usually got one full refreshtime of lag differential; gigantic compared to the cap-number differences.
Nice to optimize both though (switch to internal capping mechanism + higher cap if possible); just that if you could only target ONE optimization -- choose a lower in-game cap switches the capping mechanism from the laggier external cap to a less laggy internal cap.
Yes, Reflex/ULLM is higher lag than an in-game cap, but it's lower lag than the worse (GSYNC turning into VSYNC ON because your framerate went too high), thanks to the latency ladder. It's lovely having Reflex/ULLM because lots of games don't let you do an in-game framerate cap; but an in-game framerate cap is usually lower lag than any external capping mechanism.
Chief Blur Buster wrote:The latency ladder is:
- (Highest Lag) VSYNC-based hardware capping
- (In-Between Lag) Driver-based software capping
- (Lowest lag) Game-based software capping
More about the two-cap technique; which is not commonly used by most of us;
If in-game framerate caps are only best-effort approximations and very jittery in frametimes (e.g. 220fps in-game cap jitters badly from 1/200sec to 1/240sec frametimes) -- Then it can overlap too frequently with the laggy external cap (being used as the fallback) and create weird lagfeel issues. So you need a safety margin between the internal in-game cap and the external framerate cap, to prevent weirdnesses.
External frame rate caps are usually much more glassfloor (especially RTSS-based frame rate caps). So the two-cap method can (instead of lag improvements) be used as motion fluidity improvements in certain stuttery games, where an in-game cap marginally lower than an external cap. The in-game cap is the low-lag one, and the external cap is the low-stutter one, so in things like emulator situations (e.g. 60fps GSYNC during 240Hz VRR), sometimes a 60fps emulator cap and a 61fps G-SYNC cap, can make RetroArch run much more smoothly in very stuttery emulator modules. So that's ANOTHER use case of the dual-cap method...
Also see
"latency guard" in-game cap + "stutter guard" external cap, sometimes used to smooth-out framegen while making framegen a bit lower latency. That's for non-latency-critical non-esports use cases where you want lower framegen lag AND lower stutters (without worrying about the lowest-possible lag). It also helps some games that don't seem to do "VSYNC ON" properly, can sometimes framepace beautifully with this weird trick.
Obviously I'm just covering all the bases of all the weird ways to do the "two caps" tricks -- very niche tweak as it is.