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.

Coding > Query about sprite loading the PERN way?

#117678 - neilio - Tue Feb 06, 2007 3:32 pm

I'm trying to follow the Pern Project guide on loading sprites into object graphics memory and I don't quite get the way in which it's loaded..

Quote:

Code:

   //copy the sprite grahics in obj graphics mem
   for(i = 0; i < 64 * 64 / 2; i++)
      OBJ_GFXMem[sprite1.gfxID * 16 + i] = spriteData[i]; 
 

...

The last thing we do is copy in our sprite graphics and palette. OBJ_GFXMem is defined in gba.h as 0x06010000. We then offset that address the correct number of sprite characters by multiplying the starting character by 16 (each character is based on an 8x8 16 color character, this is 64 pixels at 4 bits apiece for 32 bytes, or 16 shorts which is the type of our arrays). In our case the gfxID is 0 so this is not needed but when we do more sprites this will become very important.


We're copying in data for a 64 x 64 sprite in 256 colour (that much I know), and I kind of get why we're multiplying the sprite by 16. I'm guessing that the 64 * 64 in the For definition are because we're working with a 64 x 64 sprite, but I don't get the division by 2. Is this division related to using shorts in the sprite data?

I know this is a pretty newb question but any help is appreciated![/quote]
_________________
I'd like to think this signature is under development, but it isn't.

#117696 - sgeos - Tue Feb 06, 2007 6:40 pm

Too many magic numbers...
A 16 color tile is 0x20 bytes- each pixel is half a byte.
A 256 color tile is 0x40 bytes- each pixel is a byte.
OBJ tile RAM is 0x8000 bytes (0x4000 in bitmapped modes).

64 = 0x40.
64 * 64 = 0x1000.
64 * 64 / 2 = 0x800.

The sprite is 64 by 64? 8 by 8 tiles... 64 tiles.
0x40 tiles * 0x20 per tile = 0x800.

64 * 64 is the size of the sprite data.
The are 2 pixels per byte, so there is a divide by 2.
A little confusing.

You are working with shorts? If it is, you need to divide the memory size by 2 to correct the number of loop iterations.
Example:
Code:
u8 * 8 = 64 bits = 8 writes @ u8
u16 * 8 / 2 = 64 bits = 4 writes @ u16

-Brendan

#117733 - neilio - Wed Feb 07, 2007 12:33 am

Thanks, that helped :)

In the Pern tutorials the sprite is loaded through an object file but since the pcx2sprite is apparently out of date when it comes to compiling with devkitPro, I've switched over to using a .c header file with the sprite data in, seems to be working fine.

Something I've noticed, Pern's Day 3 Tutorial 1 sprite demo doesn't work properly as the sprite is displayed as what looks like a 64 x 32 pixel sprite instead of a 64 x 64 pixel sprite. I'm guessing this is to do with the OAM settings but I'm not clear on where the problem is.
_________________
I'd like to think this signature is under development, but it isn't.

#117751 - sgeos - Wed Feb 07, 2007 2:45 am

Very welcome. The content in the pern project is good, but the tutorial does have its flaws.

The devkitpro audio/PlayBoyScout example uses a pcx image. It is "compiled" using bin2o. Looking at it might be worth your time.

As far as the sprite size goes... I'd use either gbatek, visualboy or the devkit headers to figure out what is going on.

-Brendan

#117835 - neilio - Thu Feb 08, 2007 12:32 am

Problem sorted... for some reason, the tutorial code had the correct flag for 1D mapping and in the downloadable source code had it wrongly set to 2D mapping, hence the sprite tile issues.
_________________
I'd like to think this signature is under development, but it isn't.

#117850 - sgeos - Thu Feb 08, 2007 2:08 am

This happens. I often use VBA to make sure that my data is being loaded correctly. I'm glad you got it sorted out.

-Brendan