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.

Beginners > #include screws up output

#24300 - underthesun - Sun Aug 01, 2004 3:27 am

I dont know why, but

Code:
/*
 * 1x97 map data
 */
const unsigned short kroegerbw_Map[97] = {
0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007,
0x0008, 0x0009, 0x000a, 0x000b, 0x000c, 0x000d, 0x000e, 0x000f,
0x0010, 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, 0x0016, 0x0017,
0x0018, 0x0019, 0x001a, 0x001b, 0x001c, 0x001d, 0x001e, 0x001f,
0x0020, 0x0021, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027,
0x0028, 0x0029, 0x002a, 0x002b, 0x002c, 0x002d, 0x002e, 0x002f,
0x0030, 0x0031, 0x0032, 0x0033, 0x0034, 0x0035, 0x0036, 0x0037,
0x0038, 0x0039, 0x003a, 0x003b, 0x003c, 0x003d, 0x003e, 0x003f,
0x0040, 0x0041, 0x0042, 0x0043, 0x0044, 0x0045, 0x0046, 0x0047,
0x0048, 0x0049, 0x004a, 0x004b, 0x004c, 0x004d, 0x004e, 0x004f,
0x0050, 0x0051, 0x0052, 0x0053, 0x0054, 0x0055, 0x0056, 0x0057,
0x0058, 0x0059, 0x005a, 0x005b, 0x005c, 0x005d, 0x005e, 0x005f,
0x0060
};


including the above with an #include clause screws up my program, by making my sprite look like sif it's been shredded..

and when I remove the #include my sprite goes back to normal. the above is a map file for a font tile.

i'm currently using visual ham (although not using hamLib). is it possible that because HAM puts all code in wram or something, and the memory runs out.. or..? Im completely baffled. If anybody got any ideas, thanks in advance :)

edit: more info : i am currently in mode 0, and enabling / disabling the backgrounds have no effects. the only sprite on the game screws up.. ill try post an image soon.
_________________
I am just a gba noob. be gentle :p

#24304 - underthesun - Sun Aug 01, 2004 3:47 am

[Images not permitted - Click here to view it]

and also, not using include, basically pasting the code to the stuff still screws it up. O_O the weirdest error i've ever had..
_________________
I am just a gba noob. be gentle :p

#24309 - sajiimori - Sun Aug 01, 2004 6:38 am

It might be an alignment issue. Try declaring the array this way:
Code:

const unsigned short kroegerbw_Map[97] __attribute__((aligned (4)))

Edit: actually, the relevant alignment would be on the later objects, but as a rule you'll want all your global data to be 4 byte aligned.

#24312 - underthesun - Sun Aug 01, 2004 10:37 am

sorry, but i dont really understand how to actually implement that, never seen such __ in C before..

anyhow i found my way around this problem, thanks v. much anyways :)
_________________
I am just a gba noob. be gentle :p

#24314 - col - Sun Aug 01, 2004 12:44 pm

underthesun wrote:
sorry, but i dont really understand how to actually implement that, never seen such __ in C before..

anyhow i found my way around this problem, thanks v. much anyways :)


If you post a problem, then find a solution yourself, it is normal practice to explain the solution you found. This way, others with similar problems can possibly get some help without starting a new thread on the same old subject !

col

#24323 - tepples - Sun Aug 01, 2004 4:32 pm

underthesun wrote:
sorry, but i dont really understand how to actually implement that, never seen such __ in C before..

It's a GCC extension. Try reading through the GCC manual and becoming familiar with the extra features that GCC's C frontend adds to the language.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#24328 - sajiimori - Sun Aug 01, 2004 5:18 pm

Thankfully you don't have to implement it -- it's already implemented in GCC. You only have to use it, and I pasted the exact code you need so I don't understand your confusion.

Was your solution to compile the array seperately? Or put it at the end of the file? Either of those would be a quick workaround because then the array wouldn't screw up the alignment of later data objects. In the end, you'll want to have the alignment attribute available to you.

#24356 - underthesun - Mon Aug 02, 2004 3:48 am

col wrote:


If you post a problem, then find a solution yourself, it is normal practice to explain the solution you found. This way, others with similar problems can possibly get some help without starting a new thread on the same old subject !

col


Oh, sorry, the problem wasn't actually fixed, but rather i just ended up not using the map file. It was done by gfx2gba, and i realised I didnt really need that map file. The array is a map for a font tile, (which later I just stopped using the map, and have a Bitmap instead)..

that is, i have this long 8 x 776 bitmap file of this font called kroeger, and all these fonts are slotted on an 8x8 basis. To actually generate a tile for this is easy, just gfx2gba as a normal sprite. But i specified it as a map file, and that screws things up because of compression, and that the map file isn't really needed. Thankfully it's not needed, i just stopped using the map file, and all seems to be fine. The problem seems to still be mysterious though :(..

So yeah, my solution was not to use it at all, since its not needed, and i have no idea what happens.. I just started learning C a while ago, and doing gba programming is an excuse for learning C i guess.. thanks for the helps.

I'll do a bit more research on gcc extensions. thanks!
_________________
I am just a gba noob. be gentle :p