3.6 KiB
Space Taxi -- open items
Things worth doing, not commitments. Started 2026-10-05, when Space Taxi moved out of JoeyLib's tree into this repository; JoeyLib's own list (library and platform work) stays in JoeyLib.
-
The C64's flown-sprite warp. The level-name intro animates its warp by cycling the colors of a static star field painted into screen RAM, on every target (stTitle.c,
starPaletteApplyin stRender.c). The C64 flies seven star sprites out along its rays instead. That version, carry-flag exact ($44F8/$4500/$450C/$4513/ $467A, the star velocity tables back in genC64Data.py), is kept inpatches/spriteWarp.patchfor reference: it was made against the working tree of 2026-10-05 before the warp's layout and pacing were redone, so it no longer applies as it stands. Measured then, the sprite warp ran 16.6-17.0 fps on the IIgs against the palette's 29.2 (the bar was 30); ST 29.2 against the palette's 23.3, Amiga PAL 12.3 against 18.8/13.6, DOS ~29.9 both ways. On the IIgs the cost is per-call overhead in save-and-draw and restore (~1.75k and ~1.25k cycles a star), not bytes moved, so it becomes feasible with a leaner save/draw/restore path for small cels in JoeyLib. The ST's palette warp was slow for a LIBRARY reason, fixed in JoeyLib 2026-10-06 with no game change: every jlPaletteSet made the ST HAL requantize its whole per-scanline palette table (3200 entries, ~38 ms of 8 MHz 68000 each, Hatari profiler); it now requantizes only the palette that changed. Warp on the ST, page flips per second inside the warp from a Hatari io_write trace (same method before and after): 13.5 -> 53.6 fps; the title's logo 17.4 -> 20.7. (The 23.3 above predates the 2026-10-05 intro-pacing change; this method gives 13.5 on the tree just before the fix.) JoeyLib also gained an STe build, which Space Taxi gets withmake ste(build/ste, STe and Mega STe only): the warp runs the same 53.6 on an STe and 56.8 on a Mega STe. Other ports' palette paths were not touched by this fix. -
Does $4523 really leave sprites 0-6 enabled? The level-name setup ($4523..$4665, stIntroEnter in stTitle.c) never clears the enable bits of sprites 0-6 on the C64, but the port does. Settle it from the disassembly (every $D015 write on the path into the intro), and check it in VICE if the bytes leave doubt. Dropped out of JoeyLib's TODO in the 2026-10-05 split; restored 2026-10-06.
-
What the C64 gate cannot reach.
tools/stsim/gate.sh c64holds all 25 screens to the real game, but only along the attract demo's machinery: its table RNG ($446A; a real game reads the SID noise oscillator, which the port stands in for with an LCG), one cabbie, and whatever the searched streams happen to do. Two-to-four-cabbie turns, the bonus cab at $3.00, refuelling on a fuel pad ($6E23's pump half), a crash with an UP fare aboard and the shift's end are exercised by no ride (gcov over the 25 rides shows exactly what is reached; level A's ride covers the hatch exit, $6BFB). -
Ticks that overrun a frame. When a tick's work does not fit in one frame (level V's row shift, the speech player), the C64 flushes its sprites mid-frame and a collision near the top of the screen reaches the read a tick late (MECHANICS.md). The port assumes every tick fits; modeling it needs the C64's cycle timing per tick. Seen only on a level-V ride whose cab hit the top border on a shift tick.