将《测试驾驶II》从超级任天堂移植到个人电脑，第四部分：验证、清理与当前阻碍
到了本代码仓库的第二周，技术风险已经发生了变化。
问题不再是“我们的脚本数量不足”，而是“我们已有足够多的可运行组件，以至于错误的进展看起来也可能令人信服。”
正因如此，3月6日至3月19日的历史记录才显得如此重要。这一阶段，asmdump 工具将考古成果转化为契约，将渲染器缺陷转化为隔离的测试用例，并开始清理自身生成的冗余信息。
验证变得可执行
2026年3月6日提交的 c5ec8be 引入了首个真正的验证策略层：
tools/check_regression_gates.pytools/validate_callback_contracts.pyvalidation/regression_gates_intro.jsoncrom_analysis/docs/callback_state_contracts.jsoncrom_analysis/docs/validation_gates.md
这是该代码仓库工程模型的一次重大转变。
在此之前，进展主要通过以下方式追踪：
- 渲染输出
- 跟踪日志
- 文字说明笔记
在此之后，仓库便能够对以下内容进行编码声明：
- 某一帧或过渡效果仅允许在已知范围内发生偏移
- 在特定检查点，此回调函数与状态元组必须仍然成立
- 此提升后的场景窗口具有机器可验证的关卡
截至3月19日的路线图快照，当前的验证基线已非常明确：
- 回调契约：
18/18项通过 - 回归关卡：
6/6项通过
这并不意味着开场动画的问题已经完全解决，而是表明仓库现在拥有了一个受保护的基础。未来的考古工作和运行时开发可以在不悄无声息地破坏已理解窗口的前提下继续推进。
渲染器缺陷改用合成测试用例，而非临时截图
2026年3月19日的清理提交 1663f43 很容易被误认为只是日常维护，但其意义远不止于此。
它新增了针对性的渲染器检查：
tools/check_obj_vertical_flip.pytools/check_bg_layer_priority.py
这些脚本会生成极小的场景，每个场景只有一个明确目的：
- 验证非正方形垂直镜像的 OBJ 路径
- 验证 BG4 层与瓦片优先级的排序逻辑
这正是本项目所需的正确类型的渲染器测试。虽然捕获的大尺寸帧窗口很有用，但它们难以隔离单一规则；而小型合成场景则能更清晰地一次只回答一个问题。
目前，仓库会在多个渲染器中检查这些测试用例：
- Python 简易路径
- Python
mode7-ppu路径 - SDL 运行时
当同一场景可通过多种实现方式运行时，这种交叉验证正是移植项目所需要的。
清理本身就是产品工作的一部分
当前仓库的状态清楚地揭示了清理工作的动机。
工作树中已经包含：
- 可变的
.mesen-config输出文件 - 庞大的
tools/out目录树 - 生成的设计包
- 探针日志
- 帧转储文件
- 临时桥接输出
若不主动清理，已提交的结果、一次性中间文件与过时实验之间的界限会迅速变得模糊不清。
这正是 1663f43 和 6076df3 提交所要解决的问题：
- 更严格的忽略策略
- 生成产物的清理目标
- 移除已被追踪的构建产物与缓存文件
- 推动删除无用内容的压力机制
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
