SGDK slowdown: can Claude fix it from a profiler report?

Can an AI fix slowdown in an SGDK game if you hand it a profiler report? In my test, not in one shot. A Mega Drive scene that Claude had written ran at 36 game loops per second instead of 60. I sent it back to Sonnet 5.5 with five kinds of report: none, a DMA report, a CPU profile by function, both, and both plus the cost of each game loop. It reached 60 in 0 of 15 tries. None came back faster than 36, and 11 came back slower. When Claude Code could build and profile its own changes with one script, it reached 60 in 3 of 3 runs, for USD 0.27 to 0.82 each.

The script is mdperf, which runs a ROM through my two earlier checkers, mdprof (68000 cycles per function) and mddma (DMA per frame), and adds up what each game loop costs. Everything ran headless in the Genesis Plus GX emulator. None of it was checked on a real console.

Which report helps fix slowdown in an SGDK game?

The two slow scenes come from the DMA post, where Claude was told the scene “must run at a steady 60 fps on a real NTSC console” and still missed:

• fighters: two 96x112 fighters drawn in software into RAM and streamed to VRAM. 36.0 game loops per second.
• title: a 256x160 logo of 640 unique tiles, regenerated in code every frame. 32.0.

Each fix was one claude -p call with no tools: the unchanged main.c, one kind of report, and “fix the slowdown without changing what the scene shows”. I built the reply with SGDK 2.11 and measured frames 700 to 1,499 of a 1,500-frame run with a scripted pad. Three runs per cell. “Round 2” sent each fighters result back with the same kind of report about its own new numbers.

Scene	Report	Round 1 (loops/s)	Round 2
title (32.0)	none, just the loop rate	60, 60, 60	not needed
	DMA (mddma)	60, 60, 60	not needed
	CPU by function (mdprof)	60, 60, 60	not needed
	both	60, 60, 60	not needed
fighters (36.0)	none, just the loop rate	36.0, 30.1, 36.0	44.3, 58.6, 30.1
	DMA	30.0, 30.0, 25.9	20.2, 36.0, 36.0
	CPU by function	36.0, 36.0, 30.0	44.4, 36.0, 51.6
	both	25.7, 25.9, 30.1	36.0, 44.3, 36.0
	both + game loop costs	35.9, 25.9, 25.9	36.0, 36.0, 45.0

The title scene was easy. Every fix found the tile generator, made it cheaper (mostly with tables built at startup), and reached 60, with or without a report. The DMA report said the DMA was clean and Claude read that correctly. On the CPU profile, the generator had been inlined into main, so the profile only said main.isra.0 54%; Claude guessed the cause anyway. All 12 fixed versions showed a frame 1,000 byte-identical to the original’s.

The fighters scene beat every report. Round two helped (12 of 15 got faster than their input), but nothing reached 60.

Why did the profiler report not help?

Here is the part of the original’s profile that mattered:

busiest frames:
  frame 704: 127903 busy cycles (100% of a frame), idle entered at line -1
        50566  fillRect
        42948  renderFighter
        18336  memset_
         9409  flushQueue

mdprof reports video frames, and a frame cannot be busier than 100%. When one game loop runs for two frames, each frame shows only its own slice. All 9 replies that had the CPU report read this slice as the whole cost and put one fighter’s render at 100k to 128k cycles: “about 110k cycles, which is nearly a whole frame’s budget”.

Counted per game loop, the render is much bigger. The loops that rendered a fighter took two frames and 215,375 busy cycles on average. Loops with no render took 20,440. So one render costs about 195,000 cycles, 1.5 frames on its own.

That explains the favorite fix. Twelve of the 15 round-one replies (and all 15 after round two) rendered each fighter one 32-pixel column per frame, right before that column’s DMA. With a 110k render that looks like 37k per frame. With the real 195k it is about 65k per fighter, and both fighters now render in every frame: 130,000 plus the 20,000 base, over the 128,005 cycles of an NTSC frame. Every column also walks all the rectangles of the fighter, so the slowest loop got more expensive in 10 of 15 runs (226,410 cycles before, up to 277,021 after).

So I added a game loop section to the report:

== Game loops (mdperf) ==
budget: 128,005 cycles per video frame (NTSC); a game loop that needs more misses the next VBlank and the frame is shown twice
game loops measured: 479
  160 loops took 1 video frame: busy cycles 20,329 to 20,515 (mean 20,440, 16% of one frame at most)
  319 loops took 2 video frames: busy cycles 211,305 to 226,410 (mean 215,375, 177% of one frame at most)

It did not help either. The three replies that got it still estimated the render at 100k to 112k cycles, and that kind of report went 0 for 6 over two rounds. The number was there, and Claude read past it.

Can Claude fix SGDK slowdown if it can run the profiler itself?

Yes, here. I put the fighters scene in a folder with a check.sh that builds src/main.c with SGDK 2.11 and prints the full mdperf report. Claude Code (Sonnet 5.5) got Read, Edit, Write and Bash(./check.sh), a USD 4 cap, and the same instruction: fix it without changing what the scene shows, stop at 60 or when stuck. Claude Code also let through read-only commands like grep and sed -n, and Claude often piped check.sh through tail or grep; its attempts to edit with a Python script were refused.

Run	check.sh calls	Loops/s at the end	Slowest loop (cycles)	Mean CPU load	Time	USD at API prices
1	5	60.0	115,747	19.9%	2 min	0.27
2	5	60.0	21,751	16.6%	3 min	0.39
3	26	60.0	107,608	19.7%	7 min	0.82

It did not start out smarter. In two of the three runs, the first measured edit was the column split again, at 25.9 loops per second. The difference is that the next check.sh said so. All three ended up caching poses: the idle animation has six frames but only three distinct images (idleBob = {0, 1, 2, 2, 1, 0}), and the second fighter never punches. Run 2 went furthest and drew every pose once at startup:

static void renderAllPoses(void)
{
    for (u16 a = 0; a < 2; a++)
        for (u16 fr = 0; fr < ANIM_FRAMES; fr++)
            if (a == 1 || fr < 3)          /* idle 3..5 repeat 0..2 */
                for (u16 c = 0; c < CHUNKS; c++)
                    renderColumn(poseBuf[poseIdx[a][fr]], a, fr, c);
    /* punch frame 5 shares pose 0 with idle frame 0 (identical pixels) */
}

That costs 43,008 bytes of the Mega Drive’s 64 KB of work RAM, which Claude pointed out itself. Runs 1 and 3 cached only the idle poses (about 16 KB and 32 KB, by Claude’s count) and still render punches live, so their slowest loops sit at 84% to 90% of a frame. That is not much headroom.

One round-two reply without tools found the same idea and reached 58.6: it cached the idle poses, but its punch frames still took two video frames.

Did the fixes change what the scene shows?

A fix that draws less is not a fix, and Claude said it had not checked: “I did not compare rendered frames pixel by pixel.” So I did. same_scene.py runs the original and a fix with both fighters standing still (no d-pad, so positions do not depend on the frame rate), presses punch every 90 frames, saves every video frame from 400 to 1,499, and compares the distinct pictures of each half of the screen. The original shows 7 distinct images of the left fighter and 3 of the right. All three loop fixes, and the 58.6 one, showed the same 7 and 3, pixel for pixel, none missing, none new. Walking and punch latency were not checked.

How mdperf works

mdperf is a short Python wrapper. It runs mddma and mdprof on the same ROM with the same pad script, and checks that both logged the same CPU load in every frame (they did, 0 mismatches in every run, because the emulation is deterministic). Then it adds the loop view from mdprof’s per-frame CSV:

starts = [f for f in frames if prof[f]["loop_start"] == "1"]
for a, b in zip(starts, starts[1:]):
    loops.append(dict(frame=a, frames=b - a,
                      busy=sum(int(prof[f]["busy_cycles"]) for f in range(a, b))))

A game loop starts in the frame where the CPU leaves SGDK’s wait for VBlank. Its cost is every busy cycle until the next one starts. On your own project, after make:

python3 tools/mdperf.py path/to/project --input 100-400:R --input 120-124:A --out report/

It needs the mddma and mdprof builds from their project folders (Docker only, nothing installed on the host).

What I would do differently

• Run the loop with weaker reports. All three loop runs had the full report. I do not know whether check.sh printing only the loop rate would have done as well; my guess from round two is that the loop matters more than the report, but I did not measure it. (Measured since: with only the loop rate, Claude Code still reached 60 in 4 of 4 runs by switching code off, and a per-game-loop profile cut the checks; see Does Claude need a profiler to fix SGDK slowdown?)
• Make the profile itself show the loop. mdprof’s “busiest frames” should list functions per game loop, not per video frame, so the biggest number in the report is the true one. The loop section came last in the report, and the estimates in the replies match the per-frame numbers, not the loop ones.
• Test a scene where DMA is the cause. Both scenes here were CPU-bound, which is what the earlier test produced. A DMA-bound scene could favor the DMA report.

Three runs per cell is a small sample: read the one-shot cells as “never got there”, not as rates. The 43 one-shot calls would have cost USD 5.35 at API prices and the three loop runs USD 1.48; they ran on a subscription.

This is the sixth tool in the retro series, after a lint for slow SGDK code and a sprite limit checker, among others. The same lesson showed up outside retro code: in the tsc hook test, Claude Code also did better when a check ran and answered back than when it was only told about one. Every prompt, reply, report and per-frame CSV is in the project folder.