Sprites per scanline limit?

[FireFox]

So I was doing some stress testing while implementing a new component management system and I found a really weird graphical bug where some sprites towards the bottom layer were getting drawn with a black bar over the top of them when drawing 39 or more sprites. I found that the original Game Boy had a sprite per scanline limit of about 10, but I couldn't find any documentation for if there was a sprite per scanline limit for the GBA, and whether I was hitting it or not.

Here are some images of the glitch in question. The sprite on the far right is player controlled and drawn over the top of the other sprites. The sprite on the far left is the lowest layer/first sprite.

[Chano]

From GBATEK:

Maximum Number of Sprites per Line
The total available OBJ rendering cycles per line are

1210 (=304*4-6) If "H-Blank Interval Free" bit in DISPCNT register is 0
954 (=240*4-6) If "H-Blank Interval Free" bit in DISPCNT register is 1

The required rendering cycles are (depending on horizontal OBJ size)

Cycles per <n> Pixels OBJ Type OBJ Type Screen Pixel Range
n*1 cycles Normal OBJs 8..64 pixels
10+n*2 cycles Rotation/Scaling OBJs 8..64 pixels (area clipped)
10+n*2 cycles Rotation/Scaling OBJs 16..128 pixels (double size)

Caution:
The maximum number of OBJs per line is also affected by undisplayed (offscreen) OBJs which are having higher priority than displayed OBJs.
To avoid this, move displayed OBJs to the begin of OAM memory (ie. OBJ0 has highest priority, OBJ127 lowest).
Otherwise (in case that the program logic expects OBJs at fixed positions in OAM) at least take care to set the OBJ size of undisplayed OBJs to 8x8 with Rotation/Scaling disabled (this reduces the overload).
Does the above also apply for VERTICALLY OFFSCREEN (or VERTICALLY not on CURRENT LINE) sprites ?

[FireFox]

Is it possible that number is a bit off? Doing the math, my sprite is 32 pixels wide, and everything was rendering fine when I had 38 of them rendering on screen. This would equate to 32 * 38 horizonal pixels, which is 1216 being rendered, greater than what's specified in those specs, 1210.
I think I see what could be the error though, it says 1210 was calculated from 304*4-6. Dunno where it gets this 304 from, but it looks like it should have been 308, being 240 pixels wide + 68 for H-blanking.
This would explain why me rendering 38 sprites was fine but 39 caused it to glitch, with 39 sprites drawing 1248 pixels would would exceed a limit of 308 * 4 - 6 or 1226, but be fine for rendering 38 sprites drawing 1216 pixels per line.

[WinterMute]

Definitely possible the number is wrong - there are 1232 cycles per line which should equate to 1232 pixels for normal sprites ( 1164 if OAM access is allowed in hblank). Scaled/rotated sprites take 10 + 2 cycles per pixel.

In practice you shouldn't hit the limits for normal sprites since they generally won't overlap. Large rotated/scaled sprites might be more of an issue.

[Nikonov_94]

Hello,

I was having the same issue, and there was actually an issue with the number of pixels, I was at 1264 instead of 1232. So, FireFox, did you solve your problem the same way?

[FireFox]

Hello,

I was having the same issue, and there was actually an issue with the number of pixels, I was at 1264 instead of 1232. So, FireFox, did you solve your problem the same way?

Technically it's more of a feature of the GBA hardware rather than an issue from what I understood. Basically just don't try to line up too many sprites on the same scanline, so the "solution" is more game-specific to whatever is happening in your game.