Sign in to follow this  
  • entries
    570
  • comments
    2427
  • views
    216091

Untitled

Sign in to follow this  

89 views

Whee! I finally got a sprite onto my screen. I tell you, its a real pain in the ass. But it r prettah -



The pain comes from the fact that you have to manually load the sprite into GBA memory. Well, that isn't the nasty part, because the GBA has a custom DMA (Direct Memory Access) chip that lets you memcpy stuff really really fast. Which is nice.

The problem is that you also have to hand load in the palettes and shiznit. MS Paint, sadly, doesn't do palettes very well... I'm still mucking around with various conversion tools to make all my old textures and stuff convert over to a raw image format.

Speaking of raw images - the GBA actually doesn't even have a file system, so you have to pack everything into the binary. Right now I'm just jamming the image data into a .cpp file and compiling it in; seems to work but I think its really messy. I've heard about some kind of filesystem lib for the GBA, but that sounds fishy (slow) to me.

The problem is, right now, that when you generate the image file you access the data via globals. Like you'll get a header -

#ifndef __TILE1__
#define __TILE1__

#define tile1PalLen 512
extern const unsigned short tile1Pal[256];

#define tile1TilesLen 4096
extern const unsigned short tile1Tiles[2048];

#endif // __TILE1__


Which is shit. It reminds me too much of C, and I'm using C++ for a reason.

Now, the solution I'm thinking of is probably going to be some RAII spiffyness. I want to have all the image data stored in one class which keeps control over all of the pointers (into the binary) so you'd retrieve the image like -

ImageDataManager::getImage( "tile1" );

Noting here that we're using either a namespace or a monostate, not a singleton. Probably a namespace.

Anyway - the trick to this is getting all of those pesky image files to register themselves with the manager class automagically. This is where RAII comes in - here's what our new image header might look like -


#ifndef __TILE1__
#define __TILE1__

#define tile1PalLen 512
extern const unsigned short tile1Pal[256];

#define tile1TilesLen 4096
extern const unsigned short tile1Tiles[2048];

ImageDataManager::RAIIStub foo( "tile1", tile1Pal,
tile1PalLen, tile1Tiles, tile1TilesLen );


#endif // __TILE1__


Now, when the application is launched, all of our handy RAIIStubs are initialized right before the call to int main(..). This means we can auto-populate our manager with the image data and not have to worry about grabbing specific archaic C-style global variable mischief, because our handy OOP will do that for us :]

The last part to figure out for this is how to hack the exporters so that I can automagically insert the RAII code into the image file, so I never have to worry about it again. Or, I can try some trickery and write my own application to stick it in there. Or I could do it by hand.

In any case - hooray C++!
Sign in to follow this  


4 Comments


Recommended Comments

Oy, I forgot how ugly GBA stuff was. I worked on some GBA stuff about 4 years ago -- and I must say, it was terrible. Packing into the binary was awful. I think I used a too called "bmp2gba" or something like that to convert images to header files -- but even so, terrible. Good luck on the image manager--I am sure the gba world would thank you.

Share this comment


Link to comment
Congrats on the sprite.

It seems like I made a little tool for image conversion. I'm not sure if it'll be of any help.

The GBFS can be found on this page. I've played with it and it makes things easier but I'm not sure about speed. It's on this page.

Share this comment


Link to comment
Yeah, the GBFS seems really sketchy to me - the filesystem is "appended" to the binary, so it seems like you'd still need to compile it to update the contents. I mean, I have a 80% finished thing like it which supports arbitrary per-file compression/encryption stuff, and it could probably be just plugged into the GBA stuff to work fine.

All the same, it seems like it would just be easier to continue the way I'm doing it. The makefile searches for all *.c and *.cpp files and links them in; since the image data is in said files and automatically registers its data with the manager at load-time, I can just drop the images into the build path and reference them magically from within the code. Sure, I'd have to rebuild it to update the contents, but I suspect that's the case for essentially every solution.

But yeah :]

Share this comment


Link to comment
Compared with most consoles though the DS and GBA are a complete joy to develop on. At least thats my experience.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now