设为首页收藏本站同能贴吧 切换语言 繁体中文
开启辅助访问 切换到窄版
扫描二维码关注官方公众号
返回列表
+ 发新帖
查看: 70|回复: 0

[转载发布] MAC_High_Hz_Fixes - Fixes for various problems with >60Hz monitors

[复制链接]
累计送礼:
0 个
累计收礼:
1 个
  • TA的每日心情
    开心
    2026-7-12 04:10
  • 签到天数: 209 天

    连续签到: 2 天

    [LV.7]常住居民III

    7523

    主题

    864

    回帖

    3万

    积分

    管理员

    Rank: 9Rank: 9Rank: 9

    VIP
    7
    卡币
    29053
    OK点
    16
    推广点
    0
    同能卷
    50
    积分
    37470

    灌水之王

    发表于 1 小时前 | 显示全部楼层 |阅读模式
    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.


    本贴来自国际rpgmaker官方论坛作者:Mac15001900处,因国际论坛即将永久关站,为了存档多年珍贵资料,署名转载到本论坛存档,由于官方帖子为英文原帖,需要中文翻译请点击论坛顶部切换语言为中文就可以将帖子翻译成中文浏览,方便大家随时查看,原文地址:https://forums.rpgmakerweb.com/threads/mac_high_hz_fixes-fixes-for-various-problems-with-60hz-monitors.171990/

    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有账号?立即注册

    x
    天天去同能,天天有童年!
    回复 送礼论坛版权

    使用道具 举报

    文明发言,和谐互动
    文明发言,和谐互动
    高级模式
    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    简体中文
    繁體中文
    English(英语)
    日本語(日语)
    Deutsch(德语)
    Русский язык(俄语)
    بالعربية(阿拉伯语)
    Türkçe(土耳其语)
    Português(葡萄牙语)
    ภาษาไทย(泰国语)
    한어(朝鲜语/韩语)
    Français(法语)
    关闭

    幸运抽奖

    社区每日抽奖来袭,快来试试你是欧皇还是非酋~

    立即查看

    聊天机器人
    Loading...

    QQ|Archiver|手机版|小黑屋|同能RPG制作大师 ( 沪ICP备12027754号-3 )

    GMT+8, 2026-7-30 19:34 , Processed in 0.138818 second(s), 57 queries .

    Powered by Discuz! X3.4

    Copyright © 2001-2020, Tencent Cloud.

    快速回复 返回顶部 返回列表