Jump to content
  • Advertisement
Sign in to follow this  
Michalson

Tiny GBA hardware capability question

This topic is 4800 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
I found this.

http://user.chem.tue.nl/jakvijn/tonc/video.htm I think this covers more of what you are looking for.
subject 	cycles
refresh 280896
scanline 1232
VDraw 197120
VBlank 83776
pixel 4
HDraw 960
HBlank 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.

Share this post


Link to post
Share on other sites
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 	cycles
refresh 280896
scanline 1232
VDraw 197120
VBlank 83776
pixel 4
HDraw 960
HBlank 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!)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!