FluidTimestep

Notice: With the latest version of RPG Maker MV, the functionality of this plugin is already implemented in the core engine scripts, and you therefore should not use this plugin if you already have the latest version installed and have copied the new core scripts over to your project.

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.

This way someone only getting 30fps would still be able to play the game like normally with the normal game speed, and only the visual frame updates would be slower. Likewise someone with a 120hz monitor that could run the game at 120fps would get the benefit of smoother visuals but the game would still play as normal, too.

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

Commercial use Free. See Terms of use page for details.
Latest version 1.0.2
Last updated 2015-11-22
Dependencies None
Discussion topic Official RPG Maker Forums
Download Download from GitHub
Print / PDF
Print Friendly

This plugin has no options.

Table of Contents

How it works

For the interested, here is some more details about what the plugin does while keeping it relatively layman.

The plugin uses an accumulator that gets increased every time the frame updates by the amount of milliseconds since the last frame update. When the accumulator is greater than the preferred delta time (1/60th of a second), it’ll run logic updates until that is no longer true. 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 device’s frame rate 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.

The reason the delta time is set to 1/60th of a second is that everything in MV is pretty much hardcoded around the assumption that 60 updates should happen per second. This means that every ~0,016 seconds that pass, the engine updates its internal logics for things like moving sprites. Thus we lock our game logic to that, while we let the frame update run free.

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.

Changelog

version description
1.0.2 Optimization: Using performance.now() rather than Date.now() for more reliable highres timestamps.
1.0.1 Bugfix: Moved changeScene call to after updateInputData for some scene boot crashes for the debug scene. Should fix other similarly structured scenes too.
1.0.0 Initial stable release.

Page last modified: April 17, 2016