gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Graphics > Getting a basic idea of GBA capabilities . . .

#4613 - Matto154 - Fri Apr 04, 2003 7:29 pm

Hey everyone,

I'm new here, so I would just like to introduce myself with a few questions. First of all, I'm into game graphics such as sprites and tiles and stuff. However, I'm not into programming whatsoever. I have noticed that there is very little information out there on creating graphics for the gameboy advance, most of it is for programmers and is hard to understand for someone who hates looking at code. I had a year of C++ in high school, but that was nothing. So, what I would like to know is:

1. I have heard two instances of how many colors the gameboy advance can display; that the gameboy advance can only display 256 colors at a time, with both characters and tiles. However, I also read that it uses two 256 color palettes, one for characters (16x16 color palette, or 256 color palette), and one for tiles and backgrounds. Which of these cases is true? In the second case, wouldn't it be possible for it to be displaying 512 colors in one scene?

2. Also, how many sprites can the GBA actually display at one time? I'm assuming it depends on how many colors, so lets say 16 color sprites. How many of these would the system be able to handle without slowing down to a near stop? For example, would it be possible to have a city that has a large number of citizens walking on and off screen, simulating an actual population? Also, how many sprites would be able to fit on the cart? In other words, would it be possible to have a largely diverse population, as far as sprite variation goes?

3. How much space do gba carts have on them, and how does this affect graphics? Is there any limit to how many tiles the gameboy advance can store within the cart? Same for maps, what kind of limitations do maps have, that are stored in the system? How does game speed and framerate factor into this?

4. I've seen some basic explanations of the various modes used in the programming of the gameboy advance. But, can anybody explain the exact uses of such modes, and in what instances they would be used? What mode does the typical RPG or sidescroller on gameboy advance use? What kind of limitations does each mode impose on the creation of a game?

Well, thats just about it for now. I'm sure I'll have plenty more questions with time, but the post is already way too long probably. Anyways, please give me as much information as possible, and remember I'm not a programmer, I'm an artist. So please keep it down to an understandable level of english, no programmer jargon. Anyways, thank you to anyone who attempts to answer some of my questions; your input is greatly appreciated.

Matt

#4614 - niltsair - Fri Apr 04, 2003 8:40 pm

Matto154 wrote:
Hey everyone,

Hi

Quote:
1. ...that the gameboy advance can only display 256 colors at a time, with both characters and tiles. However, I also read that it uses two 256 color palettes, one for characters (16x16 color palette, or 256 color palette), and one for tiles and backgrounds. Which of these cases is true? In the second case, wouldn't it be possible for it to be displaying 512 colors in one scene?

The Gameboy can work in many modes :
-Bitmap in 32768
-Bitmap in 256 colors
-TileMap in 256 colors
-TileMap in 16x16colors
And the palette for Sprite and Tile are independant, there's no way to tell the tile to use hte sprite palette.

Quote:
2. Also, how many sprites can the GBA actually display at one time? I'm assuming it depends on how many colors, so lets say 16 color sprites. How many of these would the system be able to handle without slowing down to a near stop? For example, would it be possible to have a city that has a large number of citizens walking on and off screen, simulating an actual population? Also, how many sprites would be able to fit on the cart? In other words, would it be possible to have a largely diverse population, as far as sprite variation goes?

-The Gba can handle 128 sprites maximum. (there's tricks to go around it, but let's stay at 128)
-Those sprites can have a height and width of 8,16,32,64 pixels.
-Those sprites have access to a pool of tiles. You can have 1024 8x8 tiles in 16 colors or 512 tiles in 256 colors.(only valid in TileMap mode, else it'S cut by half).
-Thoses sprite tiles are independant from the TileMap tiles, and have their own palette.

Quote:
3. How much space do gba carts have on them, and how does this affect graphics? Is there any limit to how many tiles the gameboy advance can store within the cart? Same for maps, what kind of limitations do maps have, that are stored in the system? How does game speed and framerate factor into this?

-A cart can use a maximum of 8mb
-No problem should arise unless you pack a lot of sound and/or try to display movie like quality animation.

Quote:
4. I've seen some basic explanations of the various modes used in the programming of the gameboy advance. But, can anybody explain the exact uses of such modes, and in what instances they would be used? What mode does the typical RPG or sidescroller on gameboy advance use? What kind of limitations does each mode impose on the creation of a game?

Bitmap:
-You address every pixel on screen.
-Every special effect have to be programmed.
-Acces to sprites. (512 tiles)
TileMap:
-You screen is divided in 8x8pixels squares.
-You can specify Maps(what tile to use at every position) that are larger than te screen and easily scroll it.
-You have access to 4 layers, one on top of the other.
-On those layer you can ue some special effects, like semi-transparence, Whitening or blackening a layer.
-Access to sprites. (1024 tiles)
-You can Rotate ans scale a map(on a special mode)
bottom line :
Because of it's many features and ease of use, games usually tak eht TileMap mode.

Hope it'll help ya.

#4625 - Matto154 - Sat Apr 05, 2003 7:25 am

Thank you, that helped clarify most of my questions. Its still a little confusing, but thats to be expected :)

#4630 - ampz - Sat Apr 05, 2003 1:01 pm

A cart can be max 32MegaByte, not 8.

#4634 - Matto154 - Sat Apr 05, 2003 5:24 pm

Quote:
And the palette for Sprite and Tile are independant, there's no way to tell the tile to use hte sprite palette.


So in other words, it CAN display a total of 512 colors at one time???

Quote:
-Access to sprites. (1024 tiles)


So thats all you can have for ALL the sprites in the entire game? And I'm assuming that is 8x8 tiles, so it would be less, 512 tiles for 16x16 sprites, and even less for larger sprites? And I'm assuming that counts all of the animation frames and such.

Quote:
-You can specify Maps(what tile to use at every position) that are larger than te screen and easily scroll it.


What is the largest map that you can have?

Quote:
-Those sprites have access to a pool of tiles. You can have 1024 8x8 tiles in 16 colors or 512 tiles in 256 colors


What if you kept it in a 256 color palette for sprites so that you can easily interchange colors for sprites . . . but only kept each sprite to under 16 colors, would that still have the side effects of using a 256 color palette?

Also, how would one go about doing a tree that you can walk around, I'm assuming you'd use a sprite, right? That would suck to have to waste sprite space in order to do all trees and other such objects, and have them, at the same time use and waste 16 color palettes.

Alright, thats it for now, sorry for being a pain.

Matt

#4635 - tepples - Sat Apr 05, 2003 5:45 pm

Matto154 wrote:
So in other words, it CAN display a total of 512 colors at one time???

Actually, 511 because sprite color 0 is never displayed (it's always transparent). If you're using blending or a high-color bitmap background, this can be greater.

Quote:
So thats all you can have for ALL the sprites in the entire game?

No. It's not like the early NES where the sprite tile data was fixed. Programs reload the sprite tile data continuously while running; see my essay for details.

Quote:
What is the largest map that you can have?

The largest map supported by hardware is 64x64 tiles (about 2 screens wide by 3 screens high) in "text" mode and 128x128 tiles in rotated mode. However, you can get infinitely large virtual maps by continuously updating the map data, copying in new entries at the "seam".

Quote:
What if you kept it in a 256 color palette for sprites so that you can easily interchange colors for sprites . . . but only kept each sprite to under 16 colors, would that still have the side effects of using a 256 color palette?

If you use 16-color sprites, you can tell each sprite to use any of the 16 sets of 16 colors.

Quote:
Also, how would one go about doing a tree that you can walk around, I'm assuming you'd use a sprite, right?

There are four background layers on the GBA, and sprites can go behind any of them, though ome games do use sprites for such objects.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#4639 - niltsair - Sat Apr 05, 2003 10:08 pm

[quote="tepples]Actually, 511 because sprite color 0 is never displayed (it's always transparent). If you're using blending or a high-color bitmap background, this can be greater.[/quote]
Actually, less than 511 :-).

-Map's Tiles with 256 colors: 255 colors
-Map's Tiles with 16 colors: 240 colors (16pal.x15 colors)

+

-Sprite's Tiles withs 256 colors : 255 colors
-Sprite's Tiles withs 16 colors : 240 colors (16pal.x15colors)

So it gives a total of :
510 or 490 or 480 colors depending on the mode you use for the tile and sprites. Because, like tepples wrote, the color 0 of each palette always indicate the see through color.

Sprites use usually kept for small movings objects though, not to do background stuff.

Also, you can at all time reload any Tiles(for sprite or Map) and change the color palette of any of those 2. If you're using 16 color palette, it's easier to change the colors, dor a set of objects, because it won't affect the other tiles that aren't using it.

So keep in mind that this 'limitation' is only a 'complication' because you can at all time reload data in video memory, you can put as much colors/tiles in Rom than you want and load them when you needs.

For the sprites, if 2 of them are using the same picture, they'll be using the same tile in memory, no need to load it twice.

Mapwise, you also needs to have to redondants tiles, else you won't be able to fit 4 layer of differentes tiles at a time :
-1 layer = 600 Tiles. 30x20tiles to fits the entire screen.
Which would bust the limit of 890 tiles. (4x600)
(You might wonder where the 890 come from, it'S from 1024tiles, but for eahc map, you lose 32 tiles space to store it)

#4642 - tepples - Sat Apr 05, 2003 11:32 pm

niltsair wrote:
So it gives a total of :
510 or 490 or 480 colors depending on the mode you use for the tile and sprites.

Add one because color 0 of the rearmost BG actually is visible as the display's ultimate background color (PALRAM[0]).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#4646 - Matto154 - Sun Apr 06, 2003 8:10 am

Oh, so I think I'm beginning to grasp it a little better now. So what you are saying is this . . . I can have as many sprites/tiles as I want, but I just can't display them all at the same time? So, for an RPG, I could be using a 16x16 color palette mode. I could dedicate like 8 of the palettes to main characters . . . while dedicating the other 8 to NPC's. Lets say I have two cities, city A and city B. Could I use the 8 NPC palettes for NPC's in city A, then completely change the 8 palettes when it comes to making completely different inhabitants for city B? That way I have a huge variety of NPC's, but they won't ever have to come in contact with one another. Is this how that would work??? So basically it is just clever use of palette swapping and a good use of video ram? Thanks again.

Matt

#4647 - niltsair - Sun Apr 06, 2003 8:19 am

gg

Last edited by niltsair on Sun Apr 06, 2003 8:22 am; edited 1 time in total

#4648 - sgeos - Sun Apr 06, 2003 8:19 am

[quote="Matto154"]I could dedicate like 8 of the palettes to main characters . . . while dedicating the other 8 to NPC's. So basically it is just clever use of palette swapping and a good use of video ram?[/quote]

Basically you can do whatever you want with VRAM. You seem to be thinking of VRAM as part of you game too much. Thats how I thought of it when I first started as well. The VRAM is just the final destination of all you gfx/map data, etc before it hits the screen.

Although it's not efficient (SP?!) I refresh a lot of VRAM every frame depending on what I'm doing.

-Brendan

#4649 - niltsair - Sun Apr 06, 2003 8:20 am

Almost correct.

A sprite can only access 1 palette. So, your main character can't be using 8 palettes, unless he's made of many sprites (say Legs sprite and Upper body sprite).

But for the rest you're right. You can change any palette at any time, same for the Tile availables for your map and sprites.

#4659 - Matto154 - Sun Apr 06, 2003 4:55 pm

Heh, I didn't mean use 8 palettes for just the main character, I meant all the main characters, such as in an RPG.

Matt

#4702 - Quirky - Mon Apr 07, 2003 7:56 am

You can do what you like with the palettes. The hardware doesn't know that sprite 0 is a "main character" or a status overlay or anything, it just knows it's a 16*16 sprite with 4 bits per pixel colour depth, priority 1, at location x, y using palette 2 (or whatever) it's up to you to make it behave like a "main character" in a RPG...

#5361 - Ninja - Sat Apr 26, 2003 1:17 am

tepples wrote:
No. It's not like the early NES where the sprite tile data was fixed. Programs reload the sprite tile data continuously while running; see my essay for details.


Interesting.... According to your essay, sprites can be unloaded and loaded again fast enough for animation without caching multiple frames of the same sprite? I haven't tested it yet myself, but I was double buffering my sprites in my current test programs, so that there would be no delay in the loading time.

#5365 - tepples - Sat Apr 26, 2003 3:27 am

Ninja wrote:
According to ["Managing Sprite Cel VRAM" by Damian Yerrick], sprites can be unloaded and loaded again fast enough for animation without caching multiple frames of the same sprite?

True. About the only time you need to cache sprite cels in RAM is if you're compressing your cels, and even then, you can usually use EWRAM to cache decompressed cels unless you're multibooting.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#6875 - Alunze - Wed Jun 04, 2003 1:39 am

A question, what exactly is "caching"? I've seen that term used many times and I've just realized I don't know what it means (weird eh?) XD

#6932 - tepples - Wed Jun 04, 2003 6:48 pm

To "cache" an object means to store it temporarily in a faster section of memory. For example, uncompressed EWRAM and VRAM can be faster than compressed ROM. When applied to the result of a calculation, caching is often called "memoizing."
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.