ItInsightsWorld SoftwareDevelopment Case Study: G-Diffuser v1.0.0, native-60, and a four-way Nintendo 3DS Release Plan

What should a SoftwareDevelopment review take from G-Diffuser v1.0.0? The port of the F-Zero X decompilation to Nintendo 3DS is, first, a delivery record: one person directed the work, one long-lived Claude session orchestrated it, 147 subagents built the first phase, and many more carried the second. The phase boundaries are explicit: 2026-08-11 to 09-03 covers the 24-day sprint that reached native-60 and 60 fps in 3D on New 3DS; 2026-09-07 to 10-19 covers the 43-day extension that added Old 3DS support, a native renderer, and the 64DD Expansion Kit. The published coverage is four-way.

For engineering teams, the value is not the novelty of a retro racer. It is the way the program documented hardware pacing, memory constraints, agent throughput, and dated claims while turning a black screen into a playable product surface.

Measured outcomes to track

• Hardware median, full Grand Prix, New 3DS, end of first phase: 59.6 fps, up from 12–20 fps in the first emulator race.
• Tenth-percentile floor in 30-machine crowds, first phase: 51.4 fps, up from 25–35.
• Frames pinned to the 60 cap, first phase: 53%, up from 14% one week earlier.
• Calendar pressure: 15 active days across the first phase's 24 calendar days, with three pauses when the weekly plan allowance ran out.
• Agent consumption, first phase only: 3.17 B tokens across all sessions and agents.
• API list-price projection, first phase only: $4,974 when published rates are applied, including Fable at $10/$50 per MTok and 1-hour cache writes.
• Change volume: 250 commits touched the 3DS port in the first phase, frozen 2026-10-08 from the v0.9.0 docs and not re-verified against final history.
• Code surface: 15,039 lines under port/3ds plus 48 pure-delta patches, first-phase count.

What v1.0.0 added

• v1.0.0 added 3 released console builds from one source tree: Old 3DS, New 3DS, and New 3DS with the Expansion Kit.
• Three released console builds are the delivery outcome; 199 internal progress notes were written during the second phase.
• The second phase spanned 43 days calendar: 2026-09-07 to 10-19 inclusive.

The numbers above are dated. The first phase's hardware values and token/cost figures were measured through 2026-09-03 and have not been re-run for v1.0.0.

Hardware evidence and UI states

v1.0, New 3DS: the Expansion Kit's Select Mode (COURSE EDIT, CREATE MACHINE); the bottom screen is DASH's idle view.

v1.0, New 3DS, mid-race: DASH on the bottom screen with energy, position, lap times and the course map.

The clips and photos below are from v0.9 (2026-09), before DASH replaced the debug console on the bottom screen.

open clip v0.9: Grand Prix on a New 3DS. The bottom screen is the port's debug menu: 59.8 fps, heap, build id.

open clip v0.9: handheld, mid-race. Native 60 Hz pacing; no interpolation.

Title screen, launched from the Homebrew Launcher (.3dsx).

Select Mode.

Select Machine.

Blue Falcon.

Build scope and gameplay surface

Three released console builds come from one source tree. They boot from the HOME menu (.cia) or the Homebrew Launcher (.3dsx): a base build for Old 3DS / 2DS, a base build for New 3DS / New 2DS XL, and a New 3DS build with the 64DD Expansion Kit. The Expansion Kit path includes a course editor and machine creator playable with a user-supplied disk image. Every build reads prebaked asset archives from the SD card; no ROM or disk image ever ships with the game.

The playable surface covers the whole game: Grand Prix, Time Trial, Practice, Death Race, and the machine editor screens. Audio uses the real DSP, stereoscopic 3D remains on the slider, and the bottom-screen dashboard ships with three HUD layouts and an idle view outside races. Lifecycle behavior includes HOME suspend, resume, close, lid sleep and power-off.

The New 3DS build preserves the first phase's native-60 frame pacing. The Old 3DS build reaches a comparable result through a different route. At v1.0.0, with no ini, both builds default to the native renderer, where [perf] preset = auto. The New 3DS's first-phase render-thread/per-draw-stereo path is still built in and reachable with an explicit ini.

Stack inventory

• decomp: the F-Zero X decompilation (inspectredc/fzerox), untouched upstream, plus a patch stack.
• libultraship: the N64 runtime by Kenix3, untouched upstream, including a 13-line newlib fix that lets it build on devkitARM; it still draws every menu and non-race screen.
• port/3ds: 15,039 lines as of the first phase, since grown into a citro3d rendering backend, stereo, audio, input, menu, lifecycle, render thread, profilers, packaging.
• native renderer: added in the second phase; an owned interpreter that skips the per-frame display-list walk for race geometry and becomes the v1.0.0 default on both consoles.

Comparison table: first-phase pacing on New 3DS

Checkpoint	Median	p10	At 60 cap
08-14 first race (emulator)	12–20	–	–
08-21 first hardware run	48–50	–	–
08-28 release-grade build	~51	~40 (crowds, MINIMAL)	–
09-02 Round 1: Mainline before the campaign	51.3	39.2	9%
09-02 Round 2: Bridge memos (brfast)	57.2	46.6	29%
09-02 Round 3: HUD atlas · triangle memo · TMEM · audio	56.0	48.0	32%
09-02 Round 4: Render thread on core 2 (pipe)	57.6	44.6	14%
09-02 to 09-03 Round 5: Ahead mode · bridge on main · auto rival detail	59.6	51.4	53%

Step-by-step delivery: first phase

1. 08-11 to 08-14: Research moved into execution. A feasibility dossier defined the target, a plan was written for a team of agents, five parallel foundation streams were opened, six boot bugs were cleared, and the first race appeared at 12–20 fps in the emulator.
2. 08-20 to 08-22: The build crossed from visual defects to a real console. Fog, HUD, livery, shadow and sky were addressed; the loadblock discovery took menus from 27 to 60 fps; the first hardware run on 08-21 produced wow it runs amazing; audio arrived the same evening.
3. 08-27 to 08-28: The work hardened into product grade. A Five-agent fleet drop brought stereo armed, touch menu and rival detail; a GPU vertex-transform moonshot was built and shelved; README legal notice and release package followed.
4. 09-01 to 09-02: Lifecycle and the last major lever were handled. The HOME crash and close-from-HOME hang were fixed; a bridge output cache was proven a NO-GO and replaced by memoizing each sub-display-list's classification instead of re-scanning it every frame; the LOCKED-60 campaign launched with four parallel levers.
5. 09-02 to 09-03: Multi-core work carried the headline. A render thread on core 2, one-frame-ahead mode, bridge on main, and auto rival detail reached median 59.6 with 53% of frames at the 60 cap; a crash was fixed, viewport placement was corrected, and stereo markers were anchored.

Step-by-step delivery: second phase

The second phase was not originally planned. It ran 09-07 to 10-19, 43 calendar days, and changed the scope from a single New 3DS achievement to a four-way release plan.

1. 09-07 to 09-29: Scoping shifted into memory fit. The Old 3DS milestone, previously written off, was restarted; parallel agents fit the build into its 64 MB app region, halved the RDRAM arena, streamed audio instead of keeping it resident, and capped texture uploads. On 2026-09-29, in the first hardware session on a real Old 3DS, the shipped New-3DS-era, 16 MiB RDRAM build died at boot while the -DGDX_3DS_O3DS=ON profile, built to fit the console's memory grant, booted and raced the same session at about 10 fps.
2. 09-29 to 09-30: The team located the real costs. A narrowed audio lock cut the race-wall wait on the Old 3DS by about 20 ms a frame; frame skipping ended the game's accidental slow motion; a first retained-mode renderer won big in the emulator and barely moved the number on hardware.
3. 09-30 to 10-01: A probe changed the plan. Hardware performance counters showed the real limit was instruction-cache misses, not instruction count. A pose-replay fallback was built and worked, then was set aside on the user's call: we should go for a real 60! i still believe it has to be possible.
4. 10-01 to 10-02: The native renderer was rebuilt around the cache instead of around instruction counts, with one small loop per race category, sized to fit the 16 KB instruction cache. Median frame time on a 2D Grand Prix race reached 16.5 ms.
5. 10-03 to 10-08: Stereo at 60 reached the Old 3DS. A per-eye resubmit with its own swap-pacing mode reached 59–60 fps in 3D on most Grand Prix courses; the heaviest courses, Silence and Sand Ocean, can still trip the frame-skip safety net to a steady 30 fps mid-race.
6. 10-08 to 10-19: The Expansion Kit, dashboard and release were finished. The 64DD Expansion Kit was verified tick-for-tick identical under the native renderer and booted on the Old 3DS, which then proved too slow to release it on; DASH shipped; a standing adversarial review audited the merged result before the v1.0.0 release.

Common engineering pitfalls in this port

• Emulator success can mislead hardware planning: the first retained-mode renderer won big in the emulator but barely moved the number on hardware, and the first race was only 12–20 fps outside a real console.
• Memory budgets can kill the boot path before performance matters: the 16 MiB RDRAM build died at boot on Old 3DS, while the fit profile needed the 64 MB app region.
• Instruction count is not the whole story: counters redirected the work toward instruction-cache misses, leading to the 16 KB instruction cache constraint behind the native renderer.
• Dated claims need explicit boundaries: first-phase numbers were measured through 2026-09-03 and were not re-run for v1.0.0; the 250 commit count was frozen on 2026-10-08 from v0.9.0 docs.
• Default settings can hide alternate engineering paths: the first-phase render-thread/per-draw-stereo path remains built in, but explicit ini is now required because v1.0.0 defaults both builds to the native renderer.

FAQ: what release engineers should ask

Did the release ship one binary for every handheld?

No. The delivery unit was 3 released console builds from one source tree, and the published outcome is described as Three released console builds covering Old 3DS, New 3DS, and New 3DS with the Expansion Kit.

What was the headline first-phase hardware result?

On New 3DS, the first phase ended with 59.6 fps median in full Grand Prix, 51.4 fps at the tenth-percentile floor in 30-machine crowds, and 53% of frames at the 60 cap, up from 14% one week earlier.

How large was the agentic work?

The first phase used 147 subagents, consumed 3.17 B tokens across all sessions and agents, and was estimated at $4,974 using published API list prices, including Fable at $10/$50 per MTok and 1-hour cache writes.

What parts of the record should be treated cautiously?

The first-phase hardware, token, and cost figures were not re-run for v1.0.0. The 250 commits and 15,039 lines are first-phase counts, with the commit figure frozen from v0.9.0 docs on 2026-10-08.

Action suggestions for teams running agentic engineering

1. Freeze the source of every performance claim. In this case, each measured value is tied to git history, research documents, hardware logs, or session transcripts.
2. Run emulator and hardware checkpoints as separate gates. The project's own pacing table shows why a first emulator race is not evidence of final console behavior.
3. Profile before rewriting. The second phase changed direction after counters showed instruction-cache misses rather than instruction count, leading to the native renderer sized for the 16 KB instruction cache.
4. Treat memory fit as a release constraint. The Old 3DS milestone moved only after the build was refitted to the 64 MB app region and the 16 MiB RDRAM assumption was abandoned.
5. Keep alternate paths documented and reachable. The first-phase render-thread/per-draw-stereo path remains in the tree, but is no longer default without an explicit ini.

For readers of ItInsightsWorld's SoftwareDevelopment column, the transferable lesson is operational: a complex port becomes auditable when scope, pacing, cost, dated measurements, and release defaults are written into the same engineering record. This report is published by IT Insights. Author: James Hartley. Editorial contact: contact@itinsights.com.