FluidTimestep -- Fix the game speed

[Galenmereth]

​

Important: if you're using MV 1.1.0 or newer, you don't need this plugin
​

Introduction


Makes the game run at normal speed (animation, movement, and anything else) regardless of framerate. By default, MV run on a 144hz monitor would run at 144fps and everything would move at 2,4 times normal speed. Likewise, if someone ran the game and only managed 30fps, everything would move at half normal speed.


 


While simply limiting the framerate to 60 is one solution, it wouldn’t solve the problem where a player getting sub-60 frames per second would experience the game’s speed being slower than normal. At 30fps, the game would move at half normal speed. The solution used in this plugin makes it so logic updates in the engine always occur at the rate of 60 times per second, while the display gets updated as fast as the user’s device can handle it.


 


Inspired by http://gafferongames.com/game-physics/fix-your-timestep/

Before asking for help, please read the documentation page to see if it might already be covered there. That page will be updated over time and always be the most current documentation available for the plugin.


Latest version


1.0.2 - 2015-11-22


Features

• Visual frame updates are independent of logic updates so that movement, animations, and all other gameplay elements move at the normal speed regardless of the device frame rate.
  

How to use


Add the plugin to your game and check the parameter settings for help. The Help section contains general information and a link the plugin's documentation page.


Documentation


Official documentation page


Download


GitHub (if you're using MV 1.1.0 or newer, you don't need this plugin)


Dependencies


None


FAQ


No items yet


Credit


Tor Damian Design


Terms of use


Free for non-commercial and commercial use. See terms of use for the full terms.

 

[Prescott]

Wow, this is super helpful, and really makes the game playable on a wide variety of systems. I can't tell you how much I hate it when games run at 40 fps that are supposed to go 60 and everything is just super slow, while other 30 fps games look much smoother.

Thanks for this, very much!

 

[Galenmereth]

I have to mention that someone playing the game at 30fps would naturally get some "stuttering" visually, as that's what a lower fps would do. But it should be significantly less of a problem than running the game at half game speed

A few nice benefits I've noticed so far from running the game at a higher framerate using this:

• The mouse feels more responsive since its visual position keeps getting updated every frame update
• Drag and drop in my game is even smoother, because despite the logic and input only updating 60 times per second, visually it gets to catch up at double the speed.
• Overall it looks smoother visually, since it gets updated at my display's nature refresh rate visually.

 

[Roguedeus]

This combined with masked's Smooth Scroll plugin can do wonders for quality of game play.

Thanks for this!

 

[fallenlorelei]

Omgosh!

Thank you x100!

I made my game on a 144hz monitor and didn't realize the fast rates was a *thing.* I thought it was a quirk of the program! So I had slowed ALL of my events down to like x4 slower just so they would look normal. For conversations, I had to wait "Wait 120 frame" commands so it went at an average pace. Then when I finally uploaded my first draft and tried it out on my work computer, holy crap. Everything was so slow, it was ridiculous. Needless to say I was upset and frustrated that I thought I had a decent game ready for the public, but instead had to go back, edit all of my events and movement speeds, and "guess" what a normal speed was.

Rant aside. This is amazing. Thanks again. =]

 

[Iavra]

How would you know that 1 iteration of your while-loop lasts exactly 1/60s?


/edit: Just read the linked article. Funny enough, i remember reading that some time ago, but forgot about it.

 

[Galenmereth]

@Iavra: While the accumulator var is greater than the delta time var, it'll run logic updates until that is no longer true. The accumulator is increased every visual frame update by the time in milliseconds since the last update, while the delta time is set to 1.0 / 60.0, i.e. 1/60th of a second. This means that if your framerate is faster than 60fps, it will skip doing logic updates until the accumulator has time to build up to the delta time, hindering logic updates happening too fast. Reversely, if the framerate is below 60fps, it will run the logic updates multiple times per frame update to "keep up" logic-wise. Thus both 30fps and 120fps make the characters move the same number of pixels over the same time, but the smoothness of the motion will vary. This is generally the optimal solution since framerate won't impede gameplay.

Some additional info for the curious:

The reason the delta time is set to 1.0 / 60.0 is that everything in MV is pretty much hardcoded around the assumption that 60 updates should happen per second. Thus we lock our game logic to that, while we let the frame update run free. Now optimally we would take time and delta time into consideration in all things that move and animate in MV; if we did we could minimize jittering on "awkward" framerates by having movement and positional logic take the time and delta time into consideration. We could even implement alpha difference to "smooth" the awkward in-between positional updates. But this would require us to alter so many of the fundamental objects in MV that plugin compatibility would go down the drain.

So what you may notice is that sometimes on some framerates there appears to be a tiny bit of visual jitter when moving here and there. It very rarely occurs intermittently on my 120hz refresh rate too, and I noticed it on 144hz a bit more. This is because sometimes we end up with logic updates and screen updates that don't play too well together to be 100% smooth, but the only way to solve it would be to rewrite pretty much all the movement logic in the engine, and I don't think it's worth it. A miniscule occasional visual jitter is still better than the default behavior, I'd say  And for anyone on a 60hz monitor running the game at 60fps, nothing should look different whatsoever.

 

[Iavra]

Yeah, i know. I missed the part where you calculated the time used by the last frame.

 

[tsunetakaryu]

Mate, I found a minor bug with this plugin enabled, while I press F9 or use the main menu ( or any other way ) to call the debug scene, sometimes the game will be freeze. 

 

[Galenmereth]

Version updated from 1.0.0 to 1.0.1

Changes:

• Bugfix: Moved changeScene call to after updateInputData for some scene boot crashes for the debug scene. Should fix other similarly structured scenes too.

Thanks to @tsunetakaryu for reporting this bug.

Please see the documentation page for the full changelog.

 

[tsunetakaryu]

yep, no freezing anymore. Thanks! 

 

[orlando]

(removed)

 

[Galenmereth]

Version updated to 1.0.2

Changes:

• Using performance.now() rather than Date.now() for more reliable highres timestamps.

Thanks to @blubberblubb for the post on this.

Please see the documentation page for the full changelog.

 

[jackseg]

Hello,

I don't understand, don't work for me.

I use now FPSLimit.js for 60fps, it work but I want test your plugin 

We must do something special?

I have 120Hz screen.

Thanks.

 

[Galenmereth]

Disable FPSLimit plugin

 

[jackseg]

I may be stupid but not at this level 
FPSLimit is disable when I test your plugin.

 

[Galenmereth]

What happens when you playtest? Does the game still run too fast? If so, does it help if you place TDDP_FluidTimestep at the very end of the plugin list?

 

[jackseg]

You have right, I'm stupid 

The speed is good. I was wrong because with F2, it still shows allways 120FPS and not 60, but in play you feel the difference.

Thanks for your help.

 

[Galenmereth]

That's good to hear though, then it works perfectly

 

[jackseg]

So it's normal not to display 60fps with F2 key ?