MAC_High_Hz_Fixes - Fixes for various problems with >60Hz monitors

Mac15001900 · 2024-09-19T02:53:01+0900

Synopsis 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? Spoiler: 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. 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. Attachments MAC_High_Hz_Fixes.js 3.4 KB · Views: 134 oldVersions.zip 1.3 KB · Views: 35

● ARCHIVED · READ-ONLY

Started by Mac15001900 Sep 18, 2024, 05:53 PM 48 posts Page 3 of 3 View original ↗

RicoRob

#41 Jul 24, 2025, 12:29 PM Source

AquaEcho said:
You probably should update to 1.6.2 anyway because otherwise many plugins won't work

Robro33 said:
Out of curiosity, may I ask why not?

The issue is that some old plugins I have might not work with 1.6 actually. I've seen enough stories about plugins breaking and also bad performance. Those might be fixed by now, but at this point I don't care to test it.
1.5.1 has been working great for me all these 6+ years and I simply don't want to change it.
TheAM-Dol

#42 Jul 24, 2025, 12:52 PM Source

RicoRob said:
I don't care to test it.
It doesn't take long. Copy you 1.5.1 core scripts to make a backup.
Update, copy the 1.6.1 scripts to your game, test. If things break, you can just return to how things were with the 1.5.1 scripts you made a back up of.

Anyways, I can't speak for Mac, so maybe he can support 1.5.1, but I can say there are going to be many plugins that expect users to use the current version.
ShadowDragon

#43 Jul 24, 2025, 06:16 PM Source

RicoRob said:
The issue is that some old plugins I have might not work with 1.6 actually. I've seen enough stories about plugins breaking and also bad performance. Those might be fixed by now, but at this point I don't care to test it.
1.5.1 has been working great for me all these 6+ years and I simply don't want to change it.
In case you want support, you got to change "each" const and let to var to make
it work, let and const are ES6, supported by version 1.6.x.

const = constant rate so it cannot change during run time
let = block scroped variable, so it can only change inside that scope function.
var = can always change.

there are some nice explanation how const, let and var operate inside
an "if condition".

but feel to try it (as it may or may not get desired effect!
RicoRob

#44 Jul 24, 2025, 09:56 PM Source

ShadowDragon said:
In case you want support, you got to change "each" const and let to var to make
it work, let and const are ES6, supported by version 1.6.x.

const = constant rate so it cannot change during run time
let = block scroped variable, so it can only change inside that scope function.
var = can always change.

there are some nice explanation how const, let and var operate inside
an "if condition".

but feel to try it (as it may or may not get desired effect!
Thank you.

There was only one "let" to replace and no "const".

The console showed: Uncaught SyntaxError: Unexpected token => (on line 84)

But changing line 84 to "void function (alias) {" and adding '"use strict";' before it got rid of the console message.
ShadowDragon

#45 Jul 25, 2025, 07:57 AM Source

if there was an arrow "=>" this is a shortcut for "function", so it should
it coded a slightly different, but I need to check that, and strict needs to
be probably be removed.

in your case, it might not be needed, but I don't have the time to see what
needs to be changed more, I try when I do so, or someone can guide you
further.
ryu4456

#46 Aug 28, 2025, 07:14 PM Source

I was experiencing issues with excessive speed or inaccurate playtime due to my high-refresh rate monitor. Kido's GraphicsRenderFix.js didn't work for me, but MAC_High_Hz_Fixes.js worked like a charm. However, this plugin doesn't work on older MV games, such as those with 46,432,256-byte exe files.
muffinswords

#47 Oct 11, 2025, 10:31 AM Source

This fixed a serious freeze problem I was having so thank you.

Unfortunately, I am running into a bug using it alongside Moghunter's Scene File, which redoes the save screen. For some reason Yanfly's Core is also mentioned in the bug.

YEP_CoreEngine.js:1098 TypeError: Cannot set property 'opacity' of undefined
at Scene_Load.Scene_File.update (MOG_SceneFile.js:456)
at Function.SceneManager.updateScene (rpg_managers.js:2024)
at Function.SceneManager.updateScene (MAC_High_Hz_Fixes.js:86)
at Function.SceneManager.updateMain (MAC_High_Hz_Fixes.js:52)
at Function.SceneManager.update (MAC_High_Hz_Fixes.js:26)

EDIT: Placing Mog's plugin above this one stopped the bug as far as I can tell.
Mac15001900

#48 Jun 9, 2026, 09:58 PM Source

Version 1.2 is now available

Bugfixes:
- Reverted the behaviour of Game_Interpreter.checkFreeze to default; it was unintentionally affected by Graphics.frameCount changes, making it more lenient. This should fix any issues with infinite loops (e.g. autorun events with no waits at all) causing even more lag than they normally would, like what @Anatis experienced.

I've also added a zip in the original post where I'll be adding old versions of this plugin - so if an update ever causes problems, people can easily revert it.

Needless to say, you probably shouldn't be making infinite loops in your games anyway - if an autorun event is supposed to run once every frame, add a 1 frame wait to it. Unless you actually want your event to run the 100,000 commands per frame after which the interpreter gives up.

But alas, as promised, I will make sure this plugin is compatible with any RM use case, so if you do make an infinite command loop it will now lag your game normally :p

@muffinswords I wasn't able to replicate this unfortunately. This does look like a more complex issue that involves more plugins. I know it's been a while since your post, but if you were able to make a demo where this problem happens it would be awesome. Even if it can be fixed by reordering plugins, this kind of problem really shouldn't have happened because of MAC_High_Hz_Fixes in the first place, so I'd be very interested in investigating it.