Sega Genesis sprite limit: why SGDK sprites disappear

The Sega Genesis sprite limit is usually quoted as 20 sprites per line, but in the default 320-pixel mode there is a second limit that catches people first: 320 pixels of sprites per line. Ten 32x32 sprites use it all up. On my test ROM, an eleventh 32x32 sprite vanished in all 116 frames I measured, and the VDP’s overflow flag never came on, so checking the flag would have told you nothing was wrong. To find these losses without playing the ROM, I built mdsprites, a headless checker for Mega Drive ROMs that names every sprite lost on every line of every frame.

I checked it against the real picture. Run the same ROM with the emulator’s sprite limits off and on, and any line whose pixels differ really lost something. It missed 0 of 40,998 damaged lines on the test ROM and 0 of 48,606 in ROMs written by Claude. That picture comes from Genesis Plus GX: I did not check any of this on a real console.

This is the fourth tool in the retro series, after mdprof, the SGDK profiler, sgdklint and pixcheck.

The same checker now exists for the NES, where the limit is 8 sprites per line and the overflow flag has a hardware bug of its own: nessprites.

How many sprites per scanline can the Mega Drive draw?

Twenty, or 320 pixels’ worth, whichever runs out first, in H40 (320-pixel) mode. In H32 (256-pixel) mode it is 16 and 256. Sega Retro lists the sprite counts, and an old SpritesMind thread has the pixel limit: “Either 20 sprites or 320 pixels”. That thread also has a post giving 32 sprites per line, which matches neither the other sources nor what I measured.

Here is what the checker reported on one row of the screen, with solid sprites so every lost pixel shows:

Layout on one row	Most on a line	Sprites lost per frame	Overflow flag
20 x 8x8	20	0	off
21 x 8x8	20	1	on
20 x 16x16	20	0	off
21 x 16x16	20	1	on
10 x 32x32	10	0	off
11 x 32x32	10	1	off

Eleven sprites were asked for, and ten are on screen. Nothing else is on that line.

Can the VDP overflow flag detect dropped sprites?

Only the sprite count, not the pixels. Genesis Plus GX sets the flag when a line has one sprite too many. It does not set it when the pixels run out first, and that is why the 32x32 row stays silent. BlastEm made the same call in a 2025 commit: the flag “should only be set when there are too many sprites in a line and not when there are just too many sprite pixels”. Two emulators agree, but I have no hardware reading of my own.

This matters in practice. One of Claude’s scenes below lost sprites in all 1,200 frames, and the flag was off in every one of them.

Do off-screen sprites count against the limit?

Yes. The VDP walks the list for every line, and a sprite off to the side still uses a slot and its width. I put 8 sprites on screen, which is only 256 pixels, and 4 more at x = -64, first in the list:

Same 12 sprites on one row	Most on a line	Visible sprites lost
Off-screen first, SPR_addSprite flags	10	2
Off-screen first, SPR_FLAG_AUTO_VISIBILITY	8	0
Off-screen last, SPR_addSprite flags	10	0

The screen shows six sprites and no reason for the other two to be gone. This one is easy to walk into, because SPR_addSprite does not turn on auto visibility: in SGDK’s source it passes only the VRAM and tile upload flags, and its header says visibility is on by default.

The order matters too. With the off-screen sprites last, they use the budget that the visible ones left over, and nothing is lost. The VDP draws down the link list until a budget runs out, so whatever comes last is what you lose.

A trap in SGDK 2.09: auto visibility and the screen edge

While testing this, a half off-screen sprite disappeared completely in both auto visibility modes. In SGDK 2.09, updateVisibility adds two u16 values and expects them to wrap, but C promotes them to int, so a negative X reads as far off screen. I tested one 32x32 sprite on each edge:

Sprite partly over the	No auto visibility	Auto (2.09)	Auto (2.11)
Left edge (x = -8)	shown	hidden	shown
Top edge (y = -8)	shown	hidden	shown
Right edge (x = 300)	shown	shown	shown

The fix is in the source from v2.10, which has (u16) casts in that test. But ghcr.io/stephane-d/sgdk:latest is still 2.09 today: the image’s genesis.h says so and its digest matches the registry’s. If you build with that image, sprites using auto visibility pop out as they touch the left or top edge. Building against a newer checkout, as I did for the 2.11 column, avoids it.

Does sprite flicker fix the dropouts, and what does it cost?

It spreads the damage. With 24 16x16 sprites on one line, 4 are lost in every frame. Rotate the order each frame and a different 4 are lost, the classic flicker:

24 x 16x16 on one line	Which sprites are lost	Median busy cycles per frame
Sprite engine, fixed order	the same 4, 100% of frames	14,469 (11.3%)
Sprite engine, SPR_setDepth on all 24 each frame	each one 13.8% to 17.2% of frames	46,925 (36.7%)
Hand-filled table, fixed order	the same 4, 100% of frames	34,927 (27.3%)
Hand-filled table, rotated	each one 13.8% to 17.2% of frames	35,119 (27.4%)
Sprite engine, two rows 16 pixels apart	none	14,469 (11.3%)

Rotating through the engine costs 32,456 cycles, a quarter of a frame, because SPR_setDepth re-sorts the list on each call. Rotating a hand-filled table costs 192 cycles, though filling it by hand each frame is already dearer than letting the engine keep its table. And the cheapest fix was not flicker at all: moving half the sprites down one row lost nothing and cost nothing extra.

How the checker works

mdsprites is a small libretro frontend in C, built on the same core setup as mdprof. After each frame it walks the sprite list for each line in the same way the core does, and writes down what fell off:

if (vline >= y && vline - y < h) {          /* this sprite is on this line */
  int x = p[link * 4 + 3] & 0x1ff;
  int width = 8 + ((size & 0x0c) << 1);
  int onscreen = x - 0x80 + width > 0 && x - 0x80 < vw;
  if (!stopped && seen == max_count) stopped = LOSS_COUNT;
  if (stopped) {
    /* over a limit: nothing further on this line is drawn */
    if (onscreen && !masked) note_loss(line, link, stopped);
  } else {
    seen++;
    if (x) ovr = 1; else if (ovr) masked = 1;  /* X = 0 masking */
    dots += width;
    if (dots > max_dots && onscreen && !masked) note_loss(line, link, LOSS_CUT);
    if (dots >= max_dots) stopped = LOSS_DOTS;
  }
}

It runs at about 1,345 frames per second here, 22 times real time, with scripted pad input. Its explain.py turns the output into a report you can read or hand to a model:

1200 frames checked. 1200 (100.0%) lost sprite pixels to a per-line limit.
Most sprites on one line: 10 (limit 20 in H40, 16 in H32). Widest line: 320 pixels of sprites (limit 320 in H40, 256 in H32). Largest sprite list: 22 entries (limit 80 in H40, 64 in H32).
In those frames: median 2 sprites lost, worst 2; median 42 lines affected, worst 48.
Why: dot_limit 1909
The VDP overflow flag was set in 0 of those 1200 frames (it does not see the dot limit).

The first version was wrong in a way the picture caught at once. I walked the list before each frame, but a core frame runs VBlank first and then the visible lines, so the first frame of each layout that lost sprites was off by one: 227 damaged lines that the checker had not predicted. Moving the walk after the frame took that to zero.

The comparison also flags the opposite case. It predicted 2,202 lines where the picture did not change, all in the layouts with overlapping 48x48 discs: those pixels were transparent corners or hidden behind another sprite. So a prediction means a sprite lost its slot, not always that you can see it. The checker does not read tile data, so if you want to know what shows, run the comparison.

Does Claude respect the Mega Drive sprite limit?

Mostly, and better than I expected. I asked Sonnet 5.5 for 8 scenes that crowd sprites onto lines, one run each, with two prompts: plain, and with one added sentence, “It must look right on a real console, with no sprites dropping out or flickering.” Each ran for 1,200 frames under a scripted pad. When a plain scene lost sprites, I sent the checker’s report back once and asked for a fix with the same objects, sizes and behavior.

Scene	Plain prompt	After the report	Warned
rings: 32-bullet rings from the center	3.3% of frames, worst 15 sprites	4.5%, worst 1	0%
brawler: 11 x 32x48 on one ground line	100%, worst 2	66.4%, worst 1	0%
snake: 30 x 16x16 segments	73%, worst 10	12.2%, worst 1	0%
formation, convoy, boss, stars, rain	0%	not needed	0%

A few things stood out once I read the code instead of only the percentages:

• Claude knows the numbers. Several files open with a comment working out the budget, “20 sprites / 320 px per-line limit”. The plain convoy spaces 14 trucks 40 pixels apart so that at most 10 share a line, and the formation keeps 12 x 24 pixels to 288.
• Zero losses did not always mean the same scene. The warned brawler became a 1,280-pixel scrolling street with at most 4 enemies on screen, and the warned snake refuses any move that would put more than 20 sprites on a line. The warned convoy moved the trucks to a tile plane with hardware scroll, which is a good answer but a different one. All of these are defensible, and none is what the plain prompt would give you.
• The report helped but never cleared a scene. Lost pixels fell from 684,815 to 17,660 on the snake and from 390,781 to 108,593 on the brawler, but all three still lost sprites. The brawler’s fix split each character into three hardware sprites with narrower heads and legs, and still reached 336 pixels on a line.
• One fix traded the problem for another. The rings fix skips bullets hidden behind other bullets, which brought the worst case from 15 sprites to 1. It also moved p95 CPU load from 31.5% to 100%. A check that only looks at sprites would call that a win, so read the load column too, or run the ROM through mdprof.

One run per scene and prompt is a small sample, so read this as what can happen, not as a rate. The same pattern showed up with pixel art, where one sentence about the limits also did most of the work.

Other things I measured

• rescomp is not repeatable at its top levels. The SLOW and MAX levels use a randomized genetic search. Ten builds of the same source at those levels on SGDK 2.11 lost 2 to 7 hardware sprites and 438 to 782 pixels in one layout, so a build can change your dropouts without a code change. FAST and MEDIUM gave the same ROM hash in 10 of 10.
• SGDK’s own samples are clean. Under a scripted pad, the sonic sample peaked at 5 sprites on a line and 12 in its list, the platformer at 1. Neither lost anything, so they did not stress the checker.

What I would do differently

• It finds what your input reaches. A clean run does not prove that no line can overflow. A scripted pad never walked the snake into every shape it can take.
• The walk runs once per frame, so raster tricks that change the table mid-frame make it an estimate. It counts those writes and says so. Claude’s plain rain scene wrote to the table during active display in all 1,200 frames; the picture still agreed there, but I would not rely on that in general.
• I tested the Mega Drive only. The idea carries over to the NES, where the limit is 8 sprites per line, but that needs its own walk and a different emulator core.
• Nothing here ran on real hardware or a second emulator. BlastEm as a second opinion is the next check I would add.
• The sprite table is also a DMA transfer. When the queue is too big for VBlank it can land mid-screen or, with ignore over capacity, not at all; the DMA queue post measures that with a sibling tool, mddma.

The checker, the test ROM, every generated scene with its report and screenshot, and the per-frame data are in the project folder. The 22 claude -p calls would have cost USD 3.58 at API prices; they ran on a subscription.