将 Test Drive II 从 SNES 移植到 PC,第 39 部分:完成 No‑Opponent Handoff 到 02:9016

发布: (2026年3月28日 GMT+8 01:00)
3 分钟阅读
原文: Dev.to

Source: Dev.to

概览

此检查点关闭了 SNES 选择对手 流程中最后的前端歧义。
第四个槽位已经通过秒表/时钟路径在结构上得到了解决。剩下未解决的问题是,该路径是否真的会进入与常规竞争对手车辆选择相同的下游游戏走廊,还是在 01:BE43 之后的某处分叉。

恢复的无对手路径

一个相对于回调的探针以第一次出现的 01:C1D2 为键,加上后来的 be43+17‑22:start 确认,现在能够自然地通过以下顺序恢复无对手路径:

L00C20B → 01:C1D2 → L00BE76 → 01:BE43 → L008B87 → 01:902D → 01:9111 → active_main = 02:9016

关键在于这 不是 强制的回调通道;它是一个从启动时就通过与实时回调表面的时机绑定而自然恢复的输入驱动路径。

在汇合点的状态差异

常规竞争对手基线和无对手时钟路径都在相同的时间点到达同一后续走廊(active_main = 02:9016),但它们 并未 合并为相同的状态:

路径$1C70$1C76
竞争对手基线01
时钟 / 无对手路径30

该差异在两条路径已经进入共享的下游路径后仍然可见。

更新的未解决问题

最初的开放问题是:

  1. 如何选择第四个槽位?
  2. 如何确认它?
  3. 它是否会到达游戏交接走廊?

现在的重点已经转向一个更易处理的考古目标:

在两条路径已经收敛到共享的 02:9016 走廊后,$1C76 = 0 会产生什么变化?

这将搜索从菜单计时漂移转向直接的交接后行为。

已生成的工件

为此检查点生成了以下工件:

tools/out/snes_select_opponent_no_opponent_organic_path.json
tools/out/snes_select_opponent_no_opponent_organic_path.md
snes_play_session_gate.json
snes_selection_state_contract.json
docs/snes_dos_correlation.md
docs/snes_unknowns.md

下一步

捕获并比较 02:9016 之后的第一个面向游戏的窗口,分别针对:

  • 默认竞争对手路径
  • 无对手时钟路径

此时,前端路径本身已经不再是阻碍。剩余的阻碍是识别保留的无对手状态在运行时首次可见的影响。

0 浏览
Back to Blog

相关文章

阅读更多 »

忽视代码可维护性的痛苦

我最近花了好几个小时调试代码库中一个特别棘手的问题,当时我为了赶紧的截止日期而偷工减料。本该是一个简单的修复,却……

代码整洁之道

Clean Code 的力量:解锁更好软件开发的秘密 作为开发者,你可能经常听到“clean code”这个词,但…