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.

DS development > Generating .h image files?

#142356 - JeffMan - Mon Oct 08, 2007 7:05 pm

I'd like to actually try getting a project started, using the manual by Jaeden Amero in the sticky, and I'm at the standstill. It seems that every single tutorial, manual, and programming example I come across assumes that I have this magically generated header file that contains image data in a different format for use with dmaCopy. However, I have yet to actually find instructions on how to make these header files.

The manual I'm looking at says to use gfx2gba, and then to use hConvert on its output files. First of all, on the contrary to the manual's opinion, gfx2gba does not, in fact, generate any header files of any sort. It just gives me a .pal file and a .raw file. hConvert then fails, of course, since there's no header file to convert.

I did find something called wingrit, which DOES give me a wonderful header file. Unfortunately, dmaCopy takes a void* as the source data for some reason, and I can't pass the int array from the header file.

How do I do this simple task of taking an image and generating whatever header files are necessary for dmaCopy?

#142357 - Ishi - Mon Oct 08, 2007 7:31 pm

I haven't done anything on gba or used these converter programs, but I would've thought you could just cast the int* to a void* and pass that to dmaCopy.

Code:
int a[10];
void* b = (void*)a;

#142358 - SaruCoder - Mon Oct 08, 2007 7:36 pm

I use wingrit to process my image files into .h and .c files. The palette and raster data are stored as unsigned shorts (16bit). So in dmaCopy, you have to cast the pointers as unsigned short pointers (u16*).

Using embedded image files is ok for reasonably sized images. But if they get too big or you use a lot of them, then I think most people would recommend the libfat approach. Which someone will explain later because I haven't explored that avenue yet.

#142360 - JeffMan - Mon Oct 08, 2007 7:45 pm

Thanks, but casting to either (void*) or (u16*) is a no-go. I probably should have been more specific and posted my code, so here it is:

splash.h
Code:
#ifndef __SPLASH__
#define __SPLASH__

#define splashBitmapLen 98304
extern const unsigned int splashBitmap[24576];

#endif


main.cpp
Code:
void displaySplash() {
   dmaCopy(splashBitmap, BG_BMP_RAM_SUB(0), splashBitmapLen);
}

#142361 - tepples - Mon Oct 08, 2007 7:45 pm

SaruCoder wrote:
Using embedded image files is ok for reasonably sized images. But if they get too big or you use a lot of them, then I think most people would recommend the libfat approach.

Or if you are using image files based on Creative Commons licensed work, as you can't statically link Creative Commons licensed works into software unless the works are also made available under a license designed for software (such as a GNU license).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#142370 - JeffMan - Mon Oct 08, 2007 8:04 pm

Ah, heheh, just got it. It was actually the second argument screwing things up, so I casted that to a (void*) and it compiled. Thanks for the help.

Except I'm getting a black screen now when I run the program so I'll have to figure that out on my own.

#142373 - Lazy1 - Mon Oct 08, 2007 8:08 pm

These days it's better to load images from a filesystem rather than link them into the binary itself.