This is a plugin that, unless you've done something similar yourself, you'd almost certainly benefit from adding to your game, no matter what kind of game it is. Let me explain why.
MV games have the tendency to break in various ways when they're played on a monitor with a refresh rate higher than 60Hz, even if they work perfectly fine otherwise. This is not the fault of their developers, but the core scripts that in many places fail to account for the fact that such devices exist.
Things that can happen when an MV game is played on a high refresh rate monitor include:
- Inaccurately counted playtime
- Inaccurate FPS counter
- Some plugins' animations and other effects playing faster than they should
- CPU usage climbing considerably higher than it should
- And rarely the game just freezing completely
This plugin, as you might have guessed, fixes those issues.
How does this work?
You don't need to know that to use this plugin, but if you're curious, read ahead.
If you have a good understanding of RM's code, it might be quicker for you to look through the plugin file - there are comments indicating what changes were made.
MV games run at 60 frames per second. Or at least they try to: they render frames as often as they can, but run game logic so that it always happens 60 times per second, even if this results in multiple logical frames happening during a single frame.
Now, this works out fine if "as often as they can" is 60 times per second. But what if we have a monitor and a computer that can handle more? Then the engine will draw more frames, even though game logic still only runs 60 times per second. This often leads to the exact same image being redrawn multiple times, as multiple frames are drawn before anything visible changes, causing a higher than needed CPU load. So there's our first optimisation: only draw a new frame if it will be different than the previous one (or at least it's possible for it to be different). On my 165Hz screen, this halves CPU usage, without affecting the game in any way.
Now, there are some more things that run on the "as often as they can" cycle. This includes the FPS counter, which rather uselessly counts all those attempt to draw a frame. Even if the game is lagging (e.g. can only handle 40 real frames per second) it can still show a much higher value.
Similarly, Graphics.frameCount also gets updated too often, which leads to a multiple different effects. For one, playtime will be counted inaccurately (e.g. up to twice as much as on a 120Hz screen). Various plugins that use Graphics.frameCount for timing might also have that timing go a lot faster.
Example of an animation added by a plugin
The same animation on a 165Hz screen (without MAC_High_Hz_Fixes)
Now, as to the rare thing that can freeze the entire game. The freeze is actually purely graphical - you'll still be able to hear sounds, just that what's drawn on screen won't ever change. It's caused by a bug in Graphics.render that could theoretically happen on 60Hz screens too, but high refresh rates make it exponentially more likely. More discussion about it can be found in this thread.
MV games run at 60 frames per second. Or at least they try to: they render frames as often as they can, but run game logic so that it always happens 60 times per second, even if this results in multiple logical frames happening during a single frame.
Now, this works out fine if "as often as they can" is 60 times per second. But what if we have a monitor and a computer that can handle more? Then the engine will draw more frames, even though game logic still only runs 60 times per second. This often leads to the exact same image being redrawn multiple times, as multiple frames are drawn before anything visible changes, causing a higher than needed CPU load. So there's our first optimisation: only draw a new frame if it will be different than the previous one (or at least it's possible for it to be different). On my 165Hz screen, this halves CPU usage, without affecting the game in any way.
Now, there are some more things that run on the "as often as they can" cycle. This includes the FPS counter, which rather uselessly counts all those attempt to draw a frame. Even if the game is lagging (e.g. can only handle 40 real frames per second) it can still show a much higher value.
Similarly, Graphics.frameCount also gets updated too often, which leads to a multiple different effects. For one, playtime will be counted inaccurately (e.g. up to twice as much as on a 120Hz screen). Various plugins that use Graphics.frameCount for timing might also have that timing go a lot faster.
Example of an animation added by a plugin
The same animation on a 165Hz screen (without MAC_High_Hz_Fixes)
Now, as to the rare thing that can freeze the entire game. The freeze is actually purely graphical - you'll still be able to hear sounds, just that what's drawn on screen won't ever change. It's caused by a bug in Graphics.render that could theoretically happen on 60Hz screens too, but high refresh rates make it exponentially more likely. More discussion about it can be found in this thread.
Special thanks
I didn't exactly come up with all of this myself; half of those fixes wouldn't exist without the help of others. So I'd like to thank:
kido0617 for the fix for the game freeze, and @TheAM-Dol for bringing it to my attention
@caethyril for the fix to Graphics.frameCount and additional insight about the likely cause of the game freeze bug
@chaucer and @Arthran for their insight in the discussion about the CPU usage optimisation, as well as @TheAM-Dol and @Robro33 for their help in testing it for unintended consequences
Plugin compatibility
If you're already using fixes to some of those problems, place this plugin below them (though in general you should also be able to just remove them now).
If you're using Chau_SceneStabilizer, place MAC_High_Hz_Fixes below it.
If there are any other incompatibilities you discover, please let me know! I think it's quite important to make this plugin available to everyone, and I'll try to fix any issues like this.
Terms
This plugin is available under the MIT Licence. You're free to use it in any games, commercial or not, or use the code in your own plugins. Credit is appreciated, but not required.