Not for any practical purposes, simply from an interest point of view, does anyone know what the maximum number of sprites/sprite pixels (since GBA supports rotation/scaling, pixels is probably more important) per scanline. I've searched with Google, but I see to only be able to find detailed rendering specs for the original Gameboy (40 overall, 10/scanline); GBA specs seem to only include the maximum number of sprites overall (128 OAM entries). With it's "fast" processor (if you work it out there are over 1000 cycles per scanline), might it be that the GBA has no scanline limitations?

It depends on the properties of your sprites. Size, the double-size flag, which mode you're using, etc. It's not dependant on CPU, since the PPU is doing the drawing, but they are on the same clock.

http://www.work.de/nocash/gbatek.htm#lcdobjoverview

At best the PPU has 1210 cycles per scanline, and with plain sprites it takes 1 cycle to put 1 pixel, so you can work it out from there given the width(s) of your sprites. After 1210 cycles the PPU goes to the next scanline, so any left over sprites aren't drawn.

Rating up, this is exactly the kind of information was I looking for.

Quote:Original post by PnP Bios
I found this.

http://user.chem.tue.nl/jakvijn/tonc/video.htm I think this covers more of what you are looking for.

subject 	cyclesrefresh 	280896scanline 	1232VDraw 	197120VBlank 	83776pixel 	4HDraw 	960HBlank 	272

It looks like each sprite is blitted directly into video ram, so the limmit isn't how many sprites per scan line, but rather a velocity of how many scaled and rotated sprites per second.

It's sort of like the dreamcast. It doesn't matter how much geometry you send to the video card, but it will limmit how fast you can turn the geometry into pixels.

Unless you are running in Mode 4-6 (which few games do since they are insanely limited), there is no "blitting to video ram". Mainly because there is no screen buffer as you are used to in PC or next gen console programming. 2D consoles in general do not run in a bitmap video mode (not sure about the Pokemon[Gameboy] Mini though), which is why consoles were throwing around sprites and scrolling backgrounds long before the PC and it's general purpose display. Instead the image is literally drawn one horizontal line at a time, while the screen is being refreshed (in effect there is only enough space for 2 rendered lines at a time, the one being rendered, and the one being sent to the display). This is why 2D consoles are normally limited in the number of sprites that can intersect horizontally - if you have too many sprites on a single line, it will take too many cycles to draw them all and you'll miss the point where the electron beam starts drawing the next line (technically portable consoles don't need CRT type drawing, but the method sticks because it lets you do a lot with very little memory - even GBA only has 96KB of video ram [SNES had 64KB and the NES had 2KB but outputted a 256x240 [25 color] image!)