Topic on Talk:The Elder Scrolls V: Skyrim

As always people confuse refresh rate and frame rate.
I mean if you're not picky you could use "Hertz" to measure everything that happens in a given time, sure..
But besides what I wrote in the previous link (technically wise)... let's just allow the little physicist inside me to speak....

Hertzes (cycles per second) measure something periodical, something that has always a constantly steady behavior (like display buffer update time, CPU clock, properphysics engine timestep and so on).
On the other hand frame rate -in games- is all but consistent, not only because you move around and different things to render mean different performance, but even within a single second, you could have the first half with 50 frames and the second half with 30. It's still 80FPS but you can't say it's running at 80Hz

Back to the actual Skyrim question it must be said that game devs have been pretty lazy at coding, especially considering similar issues have been around and have been reported since Oblivion times (this, FO3 and FNV deserve a check)
But what is really happening? What are the actual problems? After 2 days I'm feeling somewhat like mr. Vorontsov (aka ENB series). I mean.. it's a bit queer when you read that 57.6 fps cap is the solution..

Anyway, I hope the followings are the actual facts (bold, given I don't even own the game)

We can distinguish TWO different issues groups linked to the infamous iPresentInterval[info on its values] (where X is whatever actual refresh time game engine run at):

1. Those which happen when framerate < X
   • Stuttering and input lag (which is the normality when you have low fps coupled with non-triple-buffered v-sync)
     • Disable built-in v-sync and use 3rd party tools if you really need it. Nvidia CP setting reported working, requires confirm
     • Many suggest to run the game in borderless fullscreen mode. I can't be sure, but that might probably tamper with v-sync, same as before
   • Stuttering due to unsynchronized graphics and physics engines. This seems too moronic to be true. Really. It needs to be verified has I explain at the end
   • Hiccups caused by race conditions on slow systems
     • Only possible thing is trying to mess around with threading settings
2. Those which happen when framerate > X
   
   • Dull physics.
   • Calendar out of sync
     • This is subtle. It may even ruin your savegame. Fix here
   • Flickering water
   • Mouse speed messed up
     • It should be possible to utterly adjust both X and Y axis speeds separately
   • Others I'm damn sure I'll have missed

In the end capping framerate at X is the least common solution for every one of these issues

Now, there's one big still open question: what the heck is this X??
Common sense would suggest 30 or 60 FPS, that since the arrival of progressive scan are the 2 de facto used rates (the former especially on console ports)

But this is Gamebryo Creation engine! Indeed, more convincing explanations seemed to suggest appropriate engine refresh time should be assumed to be 64 updates per second.
I'm not taking this for granted, since I'd like something.. more reliable to convince me, though this odd value could perfectly explain why there was so much confusion in this regard

Some testing would be required. If the unsynchronized graphics and physics engines thread is right, monitoring micro-stuttering would be the easiest thing to check this claim
But we can't rely just on framerates.. We'll need frames time. FCAT, MSI afterburner, fraps, whatever should be fine.

Finally, I'd like to talk about 2 other... things.
One is using hacked d3d9.dll (or tools) to force the amount of rendered ahead frames (maybe not?) and to limit fps, so no external tool would be needed (it's a pity the stutter removers were never ported to TES:V)
The other involves overclocking the display refresh rate, and tweaking iFPSClamp variable. If X=64Hz is proven, this would be the only way to have both fixed gameplay and vsync

Thanks for reading.

EDIT: Another thing worth notice is setting processor affinity.
For as much this -together with any other < 2013 info- may have been deflected by driver issues [both AMD (fixed in 13.2) and nvidia]
EDIT2: driver issues.. or workarounds (aka "in an ideal world this shouldn't be up to the driver") in the first place. Take everything with a pinch of salt