SGDK performance: a lint for slow code, tested on 40 AI games

The SGDK performance problems that cost the most are often lines that look harmless. I measured the common ones on a cost-table ROM: s16 / s16 compiles to a libgcc call and costs 613 cycles, while u16 / u16 is a 117-cycle divu; u16 % FIX16(2.7) costs 1,062 cycles against 168 for u16 % 20; and SGDK 2.09’s own muls() turned into a 270-cycle __mulsi3 call when GCC could prove one operand was positive. A frame on an NTSC Mega Drive is 128,005 cycles of a 68000, so one of these in a 48-particle loop is a third of a frame.

I turned the table into sgdklint, a Python script that reads an SGDK project, works out which code runs every frame, and flags those patterns there with their measured cost. Then I tested it on 40 small games written by Claude. It pointed at a cause in all 3 games that dropped frames. Handing its output back to the model, though, helped less than simply asking for faster code, except on the smallest model. This post has the cost table, the lint, and both results.

This is the second post in the retro series, after mdprof, the SGDK profiler that measured everything below.

Why is my SGDK game slow? The costs of ordinary C on a 68000

The 68000 multiplies 16 by 16 bits and divides 32 by 16 bits in hardware, and nothing wider. Anything else goes to a libgcc routine, and C’s promotion rules send code there more often than the source suggests. Here is what GCC 13.2 (the SGDK 2.09 Docker image) produced and what it cost, per operation, on top of a loop that does an add instead:

Code	Cycles	GCC emitted
s32 / s32	617	__divsi3
s16 / s16	613	__divsi3
u16 / u16	117	divu
s32 % s32	1,041	__modsi3
u16 % 20	168	divu
u16 % FIX16(2.7)	1,062	__modsi3
(u16 - 240) / 30	640	__divsi3
u16 / 10	77	mulu by a reciprocal
s32 / 8	23	shifts
SGDK divs(s32, s16)	139	divs
s32 * s32 or s16 * s32	268	__mulsi3
s16 * s16, SGDK muls()	35	muls
float add / multiply	1,147 / 2,285	software float, plus 1,046 to convert to s32
F16_mul, F32_mul	59, 305	muls, __mulsi3

Three of these surprised me. GCC does not use divs for s16 / s16, most likely because the quotient of -32768 / -1 does not fit in the 16 bits divs returns, so it calls the 32-bit routine. FIX16(2.7) expands to a cast to fix16, which is signed, so a u16 % FIX16(2.7) becomes a signed 32-bit modulo. And (u16 - 240) is an int that may be negative, so dividing it by a constant costs as much as a full 32-bit division.

The SGDK calls matter more than the arithmetic, because they are bigger:

SGDK call	Cycles	Share of a frame
40 x VDP_setTileMapXY (one row)	12,966	10%
VDP_fillTileMapRect, the same row	732	0.6%
VDP_setTileMapDataRect, the same row from RAM	1,470	1.1%
VDP_drawText, 19 characters	3,673	2.9%
sprintf(buf, "SCORE %ld", v)	12,582	9.8%
intToStr(v, buf, 7)	2,881	2.3%
SPR_addSprite + SPR_releaseSprite	1,865	1.5%
VDP_loadTileData, 64 tiles by CPU	17,604	14%
VDP_drawImageEx 128x64, uncompressed	22,630	18%
VDP_drawImageEx 128x64, LZ4W (FAST)	138,263	108%
VDP_drawImageEx 128x64, APLIB	549,823	430%

My test image compressed to 1% with LZ4W and 31% with APLIB, so real art will unpack at other speeds. The order of magnitude is the point: a compressed image drawn every frame costs one to four frames here. The SpritesMind thread where a game slowed down with four enemies ended the same way, with BEST-compressed sprites unpacked live.

How the costs were measured

Each case is a function the ROM runs once per frame for 64 frames, with operands in volatile globals so GCC cannot fold the work away:

#define ARITH(name, expr) \
    NO_INLINE void name(void) { s32 acc = 0; for (u16 i = 0; i < REPS; i++) acc += (expr); sink = acc; }

ARITH(base_s16_2, as16 + bs16)          // baseline: the same loop with an add
ARITH(div_s16_var, as16 / bs16)
ARITH(mod_u16_fix16c, au16 % FIX16(2.7))

mdprof runs the ROM headless in Genesis Plus GX and writes the busy cycles of every frame. The cost of an operation is the phase’s mean minus its baseline’s, divided by 40 repetitions; cases longer than a frame are summed per game-loop pass. The spread between frames was under 1 cycle per operation for the arithmetic and about 25 cycles per call for most SGDK functions (the compressed images varied more). A script reads the disassembly so the table can say what GCC emitted. The whole ROM runs 4,000 frames in under 5 seconds.

What sgdklint checks

The lint is about 920 lines of Python with no dependencies. It strips comments and preprocessor lines, tokenizes the C, and walks each function’s statements. A while (TRUE), while (1) or for (;;) is a game loop: its body and every function it calls run every frame, and so do functions passed to SYS_setVIntCallback. Inside that code it flags the divisions and multiplies that become libgcc calls, float, VDP_setTileMapXY in a loop, images and tilesets loaded every frame, text and sprintf, sprite allocation, and calls that block (waitMs, PAL_fadeOut(..., FALSE)).

Types come from the project’s declarations plus a list of SGDK return types, which is how it knows that random() is a u16 and cosFix16() a signed fix16. When a loop has constant bounds it multiplies them out, so a redraw hidden behind an if still shows its size:

$ python3 lint/sgdklint.py testrom/src
main.c:99: heavy in 2 loops [tile-loop] VDP_setTileMapXY in a loop: 324 cycles per tile;
  VDP_fillTileMapRect is 18 per tile, VDP_setTileMapDataRect 37 (one 40-tile row: 12,966 vs
  732 vs 1,470). Here: 1,120 passes x 324 = 362,880 cycles (283% of a frame)
main.c:73: guarded in 2 loops [div] '/' on 32-bit / 32-bit: 617 cycles (s32 / s32); SGDK
  divu()/divs() is 133-139, a shift is 23. Here: 24 passes x 617 = 14,808 cycles (12% of a frame)

That is the test ROM from the profiler post, where mdprof measured the same redraw at 334,924 cycles: the estimate was 8% high. On SGDK’s own samples (v2.10 tag) the two game samples, platformer and sonic, get no findings. The first version flagged 12 lines in sonic, all float literals inside FIX32(1.5), which the compiler folds into integers, so the lint now skips those. Outside the benchmark sample, which is slow on purpose, the other 17 findings are demos drawing text every frame: real costs, but deliberate.

Does AI-written SGDK code run fast enough?

Mostly yes. I gave Claude 10 small game tasks (starfield, bullet pattern, platformer, snake, breakout, particles, homing enemies, scroller, HUD, pong), each as one prompt asking for a complete SGDK 2.09 main.c with tiles as arrays in the code. Sonnet 5.5 wrote each twice, Opus 5.5 and Haiku 5.5 once, through claude -p with tools off. Each game was built (compiler errors went back to the model, up to 3 rounds), linted, and profiled for 1,260 frames with a scripted pad. The screenshots show real games: bricks, platforms, hills, a starfield.

Model	Games	Built first try	Mean CPU load	Games that dropped frames
Sonnet 5.5	20	18	7.7%	2 (10 frames)
Opus 5.5	10	10	7.4%	1 (6 frames)
Haiku 5.5	10	0	11.2%	0

The failures were API drift, not speed. Haiku wrote pre-2.0 SGDK: 9 of 10 games used deprecated names (TILE_USERINDEX 25 times) and 7 of 10 the old VDP_setSprite signature, and all 10 built after one or two rounds with the compiler output. Sonnet’s two failures were SYS_doVSync, which does not exist, and fix16Mul, which current SGDK replaced with F16_mul.

Most of Claude’s games already did what the lint asks: text redrawn only when the score changes, tilemaps written a row at a time, fixed point instead of float. Across the 30 Sonnet and Opus games, lint v2 raised 3 heavy and 14 hot or frame findings. Haiku’s 10 games got 2 and 19.

Did the lint find what dropped frames?

Three games dropped frames. The first version of the lint listed two of the causes as minor “guarded” findings and missed the third. I fixed the lint after reading the profiles, so the version in the repo is the second one.

• Opus platformer, 6 dropped frames. drawLevel redraws the 40x28 level with one VDP_setTileMapXY per tile whenever a level starts, 127,700 cycles in one frame. The first lint flagged it as “guarded” among five other findings. The second multiplies the loop bounds and puts it on top as heavy, at 283% of a frame.
• Sonnet particles, run 1, 5 dropped frames. Each explosion spawns 48 particles with random() % FIX16(2.7) for the speed: the signed modulo above, 48 times. Lint v2 reports 50,976 cycles (40% of a frame) for that line, which v1 had called a modulo of unknown type. mdprof showed another 33,000 cycles in __mulsi3, which no source line explains: GCC had turned F16_mul into a library call.
• Sonnet particles, run 2, 5 dropped frames. cosFix16(angle) * speed with an s32 speed: two 268-cycle multiplies per particle. Lint v1 only flagged 32 x 32-bit multiplies; v2 flags 16 x 32 too.

The third case taught me the most. Given lint v2’s advice, Sonnet changed the line to SGDK’s muls(), which the cost table says is 35 cycles. The profile did not move: still 22,596 cycles of __mulsi3 per explosion. SGDK 2.09’s muls() is plain C,

FORCE_INLINE s32 muls(s16 op1, s16 op2)
{
    return op1 * op2;
}

with the inline-assembly version commented out below it, and the same on SGDK master today. Once it is inlined, GCC knows speed is between 256 and 1023 and treats it as unsigned, and with one signed and one unsigned operand it falls back to __mulsi3. I reproduced it in the cost ROM: muls(s16, 256 + u16 % 768) costs 270 cycles. A source lint cannot see that. The profiler can.

Should you feed the lint output to the AI?

For each game I ran three fix rounds from the same first version: one with lint v1’s output, one with lint v2’s, and one with only “make it run faster on the real hardware without changing what it does”.

Model	Fix	Mean load change	Dropped frames after
Sonnet 5.5	lint v1 / lint v2 / plain	-0.13 / -0.14 / -1.42 points	5 / 5 / 0
Opus 5.5	lint v1 / lint v2 / plain	-0.09 / -0.10 / -1.83 points	2 / 2 / 0
Haiku 5.5	lint v1 / lint v2 / plain	-2.55 / -2.63 / +2.73 points	0 / 0 / 880

On Sonnet and Opus the plain request won clearly. Their code had few lint findings, so a lint-driven fix touched little, while “make it faster” got them to rework the hot loops themselves: precomputed sprite attributes, pointer walks, the Opus level redraw done as one VDP_setTileMapDataRect call. Every dropped frame went away, but not always because the work got smaller: the Sonnet particle game’s busiest frame was 95% busy before and 98% after, so it now just fits, with no margin.

Haiku went the other way. Its slow spots were exactly what the lint flags: one HUD did 32-bit % and / in a loop and redrew text and a tile row every frame, at 19.0% load; with the lint output it came down to 3.7%. Asked only to make the code faster, Haiku rewrote its scroller’s column upload with raw VDP port writes, and the result spent 74% of all cycles in one function and dropped 880 frames out of 1,200.

So the lint is a good map for a weak model and a checklist for a human, but a strong model does better when asked for speed directly. Either way, profile afterwards: the lint-guided muls() fix shows that the advice can be right on paper and wrong in the binary.

What broke and what I would do differently

• Lint v1 ranked two of the three causes low and missed the third, and I improved it with the answers in hand. Lint v2 pointing at a cause in all 3 is therefore a result on the data it was tuned on, not a fresh test.
• A static lint cannot see early exits. In the Opus snake, a food-placement retry loop of 64 that usually stops on the first try is reported as 64 x 1,041 cycles.
• My scripted pad never triggered some paths, like Breakout’s brick redraw, which runs once at level start before the measured frames.
• One prompt per task and one or two reps per model is a small sample. The Sonnet repeats agreed on the broad picture (7.7% mean load, the same particle problem in both runs), but I would not rank the models on it.
• These are emulator cycles from Genesis Plus GX. Nothing here was checked on a real console.

Next I would make the lint read mdprof’s output, so a finding says how many cycles that line really took in a run instead of an estimate. The next post in the series moves from code to art: a pixel art checker for each console’s palette and tile limits, tested on 72 images drawn by Claude.

The code, the cost-table ROM, every generated game with its build errors, lint output and profile, and the screenshots are in the project folder. The 185 claude -p calls would have cost USD 15.97 at API prices; they ran on a subscription.