Sprites per scanline limit?

Post Reply
FireFox
Posts: 5
Joined: Sun Mar 17, 2019 10:16 am

Sprites per scanline limit?

Post by FireFox » Sun May 26, 2019 8:55 am

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.

Image

Image

Image

Chano
Posts: 28
Joined: Fri Dec 12, 2008 7:38 pm

Re: Sprites per scanline limit?

Post by Chano » Mon May 27, 2019 9:28 am

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
Posts: 5
Joined: Sun Mar 17, 2019 10:16 am

Re: Sprites per scanline limit?

Post by FireFox » Thu May 30, 2019 11:08 am

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
Site Admin
Posts: 1403
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: Sprites per scanline limit?

Post by WinterMute » Mon Jun 03, 2019 9:48 pm

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.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests