iFPSClamp Equivalent?

[FiftyTifty]

Fer those that don't know, the use of GetTickCount() in a game's renderer causes frames to be dropped when you lack a 64hz display. Doesn't sound like too big an issue, but if you were to limit, say, Oblivion to 30fps, you'll notice that it doesn't feel smooth, whereas Morrowind is just fine at 30fps.

Same goes for OpenMW vs Morrowind. 30Fps in OpenMW feels rather poor, Morrowind @ 30fps is just dandy. And it's still the case with the new OSG renderer.

A wee while ago, back in the days of Ogre, I posted a thread talkin' about the use of GetTickCount(), 'n' replacing it with some TimeGetTime() wizardry; it's what the fabled Stutter Remover mods did, after all.

And since the renderer changed to using OSG, and having achieved some level of performance parity with vanilla Morrowind, sans the water shader, I took a gander at the source code; see if I would be able to do it meself.

Trouble is, OSG has a rather large number of third party binaries, and it's those that use GetTickCount. Bit overwhelming, really.


Now, here's me question.

Bethesda implemented the iFPSClamp setting in their post-Morrowind games, and when you set it to the locked framerate, the game is smooth, whereas without it, it ain't. For example, Oblivion @ 30fps + iFPSClamp=30 is as smooth as Morrowind @ 30fps. Same deal with Skyrim/Fallout 3/Fallout new vegas/Fallout 4 @ 30fps + iFPSClamp=30 vs Morrowind @ 30fps.

So, me question is, would it all be possible to implement some equivalent to iFPSClamp? It'd do wonders for making the game feel smooth, especially once the framerate reaches sub 45fps due to mods, and/or for those of us with lesser hardware.

[TheMechanist]

Offtopic: I just love the way you use written dialect Please add recorded voice overs to your posts Is that Irish or more of a Scotsman tongue? I'm not too familiar with English dialects

Ontopic: I barely got what you were talking about. Nothing to say here *fliesaway*

[Ravenwing]

Is that a separate option/function than simply capping the framerate? If so I don't know, but if all you're doing is trying to cap the framerate, then the function is in your settings.cfg file. This will explain where it is on your system https://wiki.openmw.org/index.php?title=Settings, and you can just edit it using any text editor. I tried limiting mine, but it didn't really make anything seem smoother.

[FiftyTifty]

Is that a separate option/function than simply capping the framerate? If so I don't know, but if all you're doing is trying to cap the framerate, then the function is in your settings.cfg file. This will explain where it is on your system https://wiki.openmw.org/index.php?title=Settings, and you can just edit it using any text editor. I tried limiting mine, but it didn't really make anything seem smoother.

No, that's not what it does at all.

Basically, the renderer syncs to a max of 64hz due to the use of GetTickCount, which is inferior to TimeGetTime. This can result in stutter and a reduction in "smoothness", due to the dropped frames.

In the newer Bethesda games, where this issue arises, the iFPSClamp setting allows you to sync the game to a specific framerate. This remedies the dropping of frames, at the cost of slow-motion when the framerate is below the specified number, as well as the game speeding up when the framerate exceeds said number.

Locking the framerate, in conjunction with iFPSClamp, results in the game being much smoother, due to there no longer being any frames dropped.


I was proposing this, as it would perhaps be an easier task to do, than to sort through a gigabyte's worth of code and replace all the instances of GetTickCount in OSG's 3rd party dependencies.

[Ravenwing]

Got it. So I tried it out in Skyrim and I see what you mean. It's a really strange concept, but you're right, capping the framerate in conjunction with clamping makes it just a bit smoother. It seems like a useful setting at any framerate!

[Lagahan]

The physics tickrate seems to be set to run at 60fps at all times in this, there's a bug about it on the bug tracker. Gives problems when the framerate is below and above 60, I can pull 120-140fps steady in OpenMW atm but the physics only update at 60 causing jittering on my 120hz monitor.

You can see it pretty clearly here if you watch this video at 60fps on chrome: https://www.youtube.com/watch?v=2J2hKuq-Q8A.
Here's the bugtracker issue for it: https://bugs.openmw.org/issues/2737

I think the issue with increasing or decreasing the physics tickrate is that it might cause collision detection issues, and is much harder to run at higher framerates.

[FiftyTifty]

The physics tickrate seems to be set to run at 60fps at all times in this, there's a bug about it on the bug tracker. Gives problems when the framerate is below and above 60, I can pull 120-140fps steady in OpenMW atm but the physics only update at 60 causing jittering on my 120hz monitor.

You can see it pretty clearly here if you watch this video at 60fps on chrome: https://www.youtube.com/watch?v=2J2hKuq-Q8A.
Here's the bugtracker issue for it: https://bugs.openmw.org/issues/2737

I think the issue with increasing or decreasing the physics tickrate is that it might cause collision detection issues, and is much harder to run at higher framerates.

Just downloaded the latest Nightly from Ace's thread. No dice; even with the physics remedied, it's still got the same lack of fluidity than the game should, at it's respective framerate.

So aye. Fairly certain it's to do with GetTickCount being used (rather than TimeGetTime) in OSG, though it would be good ta get a pro's insight.

[scrawl]

I think another cause for the lack of smoothness was bug 3052. Unfortunately, this one relies on a fix to OSG not just OpenMW. The latest OSG and OpenMW-OSG repositories do have this fix, but I don't think Ace's nightlies have been updated to this new OSG version yet.

Regarding that timing function, I doubt that is the issue, but you can check the osg/Timer code here. I don't see a GetTickCount in that code.

[FiftyTifty]

I think another cause for the lack of smoothness was bug 3052. Unfortunately, this one relies on a fix to OSG not just OpenMW. The latest OSG and OpenMW-OSG repositories do have this fix, but I don't think Ace's nightlies have been updated to this new OSG version yet.

Regarding that timing function, I doubt that is the issue, but you can check the osg/Timer code here. I don't see a GetTickCount in that code.

The reason why I think it's the issue, is because the same ol' behavior is exhibited in Oblivion and newer games; use of GetTickCount in the renderer causes dropped frames, making the game feel less smooth than it should.

The Stutter Remover mods, for Oblivion, Fallout 3 & Fallout New Vegas replace the GetTickCount calls with TimeGetTime. Thusly, the problem is resolved and the games are far smoother.


And as I stated in me first post, it's not that OSG uses it in the provided source files, but 'em 3rd party resources that it requires? Hoo-boy.

[scrawl]

Well yes, OSG (can) use some external dependencies, but these are only used for things like loading exotic 3D model formats, definitely not frame timing, that is osg::Timer's job. And, for the record, we don't actually use any of these optional OSG dependencies. You can compile a "lean" build of OSG by choosing the right build options, and OpenMW will still run exactly the same.