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.

C/C++ > Graphic -> .h file

#51511 - stevos - Sat Aug 20, 2005 9:36 pm

I've just read through the tonc tutorial and have written my first thing, a really simple unbeatable pong game.

So now I'm working on sprites. I'm on a Mac, and the utility posted on this site doesn't seem to work at all (maybe I'm tossing it the wrong image format). Anyway, I have code written to read the colors from any image format and convert them to the BGR15 format. I was planning on just generating a .c file to hold this data. But! If you download the tonc source and go to /code/gfx/gba_pic.c, it doesn't make any sense to me. So the gba_picData holds a bunch of unsigned ints which will actually be interpreted by the GBA as 4 bit quantities, which are then used as indecies into the lookup table gba_picPal. This is fine. But gba_picPal doesn't appear to hold color values, unless I'm reading it totally wrong.

Also, I understand that for 1D images you need to make tiles and then place them horizontally. How high/wide are the tiles supposed to be? 32x32? Or are they 32 high by however wide your sprite is?

Yeah, I'm dumb. I need this stuff to be spelled out to me. And maybe it was spelled out in tonc but I am too blind to see it! So thanks for help in advance guys.

When I get this done I will release this utility for sure (Mac).

#51611 - Cearn - Mon Aug 22, 2005 9:25 am

stevos wrote:
I've just read through the tonc tutorial and have written my first thing, a really simple unbeatable pong game.

So now I'm working on sprites. I'm on a Mac, and the utility posted on this site doesn't seem to work at all (maybe I'm tossing it the wrong image format). Anyway, I have code written to read the colors from any image format and convert them to the BGR15 format. I was planning on just generating a .c file to hold this data. But! If you download the tonc source and go to /code/gfx/gba_pic.c, it doesn't make any sense to me. So the gba_picData holds a bunch of unsigned ints which will actually be interpreted by the GBA as 4 bit quantities ...

8bit. It's a background. (a mode 4 background in fact)
Quote:
... , which are then used as indices into the lookup table gba_picPal. This is fine. But gba_picPal doesn't appear to hold color values, unless I'm reading it totally wrong.

Code:

const unsigned int gba_picPal[8]=
{
    0x698c7c1f, 0x3a734108, 0x5b182508, 0x63185f18,
    0x6b186718, 0x72b66f18, 0x7b187718, 0x777b7f18
};

I admit it may look a bit strange, but in the end data is data and types are just for show. Well, mostly anyway. On little endian systems (like ARM and intel) the u32
{ 0x698c7c1f } is the same as two u16
{ 0x7c1f, 0x698c } or four bytes
{ 0x1f, 0x7c, 0x8c, 0x69 }.
The 0x7c1f may be recognized as a 15bit red+blue = magenta, the rest are more difficult to explain. That's for little endian systems, for big-endian (like the mac, or so I'm told), the u16 and u8 are read/stored the other way around:
{ 0x698c7c1f } ==
{ 0x698c, 0x7c1f } ==
{ 0x69, 0x8c, 9x7c, 0x1f }
You may have to switch the bytes of your exported arrays to match the byte-order of the GBA.

Quote:
Also, I understand that for 1D images you need to make tiles and then place them horizontally. How high/wide are the tiles supposed to be? 32x32? Or are they 32 high by however wide your sprite is?

GBA tiles are always 8x8. For bigger sprites, say WxH, first cut the bitmap into blocks of WxH tiles, and make a W wide column out of those. Then repeat the process, but this time with 8x8 blocks.
Code:

// Each space is one 8x8 tile: A, B, C are 32x24 sprites
// (yes I know those don't really exist, humour me)
 ____ ____ ____
|    |    |    |
| A  | B  | C  |
|____|____|____|

// go to 32 wide column
 ____
|    |
| A  |
|____|
|    |
| B  |
|____|
|    |
| C  |
|____|

// go to 8 wide column
 __
|_A0|
|_A1|
|_A2|

// A3 to A10

|A11|
 ---
|_B0|
| B1|
// etc

But wait, columns are vertical? Yes, but the point is that you need groups of 8x8 pixels. Converting a bigger bitmap directly to 8x8 tiles is kind of a drag, but when you have an 8 pixel wide bitmap, that part is actually already done, and it can then be exported like any other bitmap.
What really matters in 1D mode is that the different tiles of a sprite are stored in consecutive cells; when you look at it on a tile-viewer they'll be placed horizontally but that's only a representation detail.

#51652 - stevos - Mon Aug 22, 2005 6:59 pm

Thanks for the reply!

I've got the palette working fine it seems. I didn't have to swap my colors because let's say 0x7FFF was color 1 on intel, on mine it's just going to be color 0. (Except that I need to fix that because color 0 is supposed to be transparent). Anyway, I think unless there is some required order for palettes (like light to dark or something) I am okay.

I decided it was a 4 bit index because:
pic_Width = 240, pic_Height = 160, so 240x160 = 38400.

But we're only using 9600 unsigned integers to hold that data. Which means that each integer has to hold 4 pieces of data. So something like
Code:

0x04040404
looks to me like
0x04 | 04 | 04 | 04
.

Then I remember that integers are 32 bits so if you need to fit 4 pieces into 1 integer, it's an 8 bit quantity. My code was still right, but only magically.

Right now my utility takes any image file as input and creates .c and .h files containing a (I think) proper palette and a C array of indices into that palette. I also am tiling the image by just grabbing chunks that are WIDTH x 8 and lining them up next to each other. I actually think that minus the transparency issue (is the 0th item in the array supposed to just not get used then?) I am doing these things correctly.
This should be suitable for a 8 bit sprite in 1D mapping mode in mode3?