gbadev.org forum archive

I have been reading a lot of faqs about graphics modes and now I am throughly confused.

I have managed to get mode 4 to work with 3 64x64 sprites bouncing around the screen. I used pcx2gba and pcx2sprite to create my resources, included the header files, load the data in with a nested fornext loop (for the pic) and setting up the oam stuff.

I am used to coding things like c64's in asm and having a variety of choices is driving me mad. I have all this info my head about how this stuff works -- but I am missing a key element somewhere that links it all together.... so here comes a stream of questions:

1. Using mode 4 is basically bitmap with sprite access, no other bg's are available (except another frame right?)
2. Text modes (mode 1) are really just tiles linked together; sprites? I create a large bitmap divided into 8x8pixel chunks, load that in as my tileset and then dump the tiles I need into sprite memory and display them on the screen... or are sprites a different system all together? Part of me thinks that the tiles are different system from sprites. I can display 128 sprites and I can also display a different set of itles correct?

So in a side scroller rtype game, you would use a tileset (say in mode 1) to represent the the background stars (BG0), the landscape (BG1), the interface data/score (BG2) and lastly a transperant layer of plasma clouds (BG3) (or could it be that the last bg is a large opponent -- to big to represent in sprites?). The ship, bullets, enemies, hidded objects (say for physical collision with backgrounds) are all sprites.. correct?

mode 2 operation has only three layers available and one is capable of doing rotation and scaling.. the layer that has this different capability does it still have the same abilities and functions the same as the the other text/tileset layers?

(breathe...)

wbochar

wbochar wrote:

1. Using mode 4 is basically bitmap with sprite access, no other bg's are available (except another frame right?)

Correct. However you can rotate and scale any of the bitmap modes.

Quote:

Text modes (mode 1) are really just tiles linked together; sprites? I create a large bitmap divided into 8x8pixel chunks, load that in as my tileset and then dump the tiles I need into sprite memory and display them on the screen... or are sprites a different system all together?

Tile backgrounds use the first 64 KB of VRAM. Sprites are made of tiles as well, but they use the last 32 KB (in tile BG modes) or the last 16 KB (in bitmap BG modes).

Quote:

Part of me thinks that the tiles are different system from sprites. I can display 128 sprites and I can also display a different set of itles correct?

Yes. You can display sprites with up to 1024 unique 16-color tiles at once, which are distinct from the up to 1792 or so unique 16-color tiles you can fit in VRAM and still have room for four 32x32 tile maps. (Each BG can access only 1024 of these tiles however.)

Quote:

So in a side scroller rtype game, you would use a tileset (say in mode 1) to represent the the background stars (BG0), the landscape (BG1), the interface data/score (BG2) and lastly a transperant layer of plasma clouds (BG3)

Super Mario World for Super NES draws clouds, playfield, and parallax backdrop in three backgrounds. It seems to use sprites for the status bar. (Do the GBA ports of games in SM All*Stars, called Super Mario Advance, work the same way?)

Because older systems such as the NES supported only 64 sprite pixels on a scanline, NES games on the other hand typically had to draw status bars (other than the vertical healthbars of Super Mario 2 and the Mega Man series) as a BG, using mid-screen writes to the scroll registers to switch between playfield and status bar on BG0. The Super NES, however, supported 256 sprite pixels per scanline, and the GBA can draw well over 900, making sprite-based status bars dead easy if you can spare the VRAM. And yes, you probably can spare the VRAM if you dynamically update VRAM as explained in my white paper on managing sprite cel VRAM.

Quote:

(or could it be that the last bg is a large opponent -- to big to represent in sprites?).

[echo]Nothing is too big for sprites.[/echo] Even on the NES, a system with 8x8 pixel sprites, Super Mario was 16x32 pixels because he was made of a 2x4 grid of sprites moved by software as a single unit. It becomes even crazier on the Super NES and GBA with their more powerful sprite processors.

Quote:

The ship, bullets, enemies, hidded objects (say for physical collision with backgrounds) are all sprites.. correct?

If an object is hidden, you don't need to write it out to the OAM to be drawn; to test for collision against the background, you'd most likely test against your map data structures.

Quote:

mode 2 operation has only three layers available and one is capable of doing rotation and scaling.. the layer that has this different capability does it still have the same abilities and functions the same as the the other text/tileset layers?

You're confusing mode 1 and mode 2.
Mode 1 - two text tile layers as in mode 1 and one rot/scale tile layer
Mode 2 - two rot/scale tile layers

Rot/scale tile layers can be bigger and can be rotated and stretched in addition to scrolled, but they must be square, can't be 16-color, can't use flipping, and can't use more than 256 unique tiles.

If you're still confused, try learning one mode at a time.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I am doing something horribly wrong and I am having trouble still..

Code:

... header stuff ....
#define OAMmem    ((u16*)0x7000000)
#define VideoBuffer    ((volatile u16*)0x6000000)
#define BackBuffer    ((volatile u16*)0x600A000)
#define OAMdata    ((volatile u16*)0x6010000)
#define BGTileMem ((volatile u16*)0x6004000)
#define BGPaletteMem ((volatile u16*)0x5000000)
#define OBJPaletteMem ((volatile u16*)0x5000200)

... main.c ...

//Background 0
REG_BG0CNT = BIT02 | BIT07;
SetMode(MODE_0 | BG0_ENABLE );

u16 x,y,i;
//Load Pallette (from a pcx2sprite file .h)
for (i=0;i<256;i++) BGPaletteMem[i]=gem_hexaPalette[i];
//Load pixels from .h (its a 64x64 image)
for(i=0;i<64*64;i++) BGTileMem[i]=gem_hexaData[i];

//Load the map into the VideoBuffer (8x8 pixel tiles)
for (y=0;y<8;y++)
{
   for (x=0;x<8;x++)
   {
      VideoBuffer[x+y*8]=map[x+y*8];
   }
}

..... map data ....

const u16 map[] =
{0x0000,0x0001,0x0002,0x0030,0x0004,0x0000,0x0000,0x0000,0x0000,0x0000};

I get a blank white screen. I enabled the offset registers and move the screen around to take a look.. I get some tiles showing up offscreen much farther down the line.
When I check the emu's memory, everything seems to be ok except for the map. What am I doing wrong? I keep goofing it up and I am having problems figuring out a stable spot to start from so I can experiment.

Everything should work in a 8x8pixel tile. If I load the bitmap data into the tilemem then point to the first segment in my map (0x0000) I should gt that 8x8 pixel square appearing in the top lefthand corner..

[bonk] brain hurts..

wbochar

BIT02 and BIT07 are not much less magical than (1 << 2) and (1 << 7). Use meaningful names.

Is that the entirety of your map data? It's only 10 elements yet you are reading 64 elements.

I don't know what size of hardware map you are using (didn't feel like decoding your BG control register), but there's no map size that's 8 tiles wide so it doesn't make much sense to multiply y by 8 when loading your map data. The minimum BG size is 256x256 pixels, which is 32x32 tiles.

If you still have trouble, post a complete example that can be compiled, with a readable BG control register, but excluding array initializers (like map data) -- just put the array size then {...}.

I am getting the hang of this...

Thanks alot for the time and wisdom. I got it to work.

wbochar

ps: hmm didnr have the right register on and was etting garbage from some wierd place that I was pointing to :)

gbadev.org forum archive

Beginners > Confusion over Mode Choices...

#29590 - wbochar - Mon Nov 22, 2004 6:12 am

#29592 - tepples - Mon Nov 22, 2004 6:44 am

#30029 - wbochar - Sat Nov 27, 2004 8:54 pm

#30033 - sajiimori - Sat Nov 27, 2004 9:39 pm

#30179 - wbochar - Mon Nov 29, 2004 4:45 am