#23957 - Lord Maz - Sun Jul 25, 2004 2:16 pm
Hi, I've just started writing on a graphics converter that should do exactly what the name implies: convert graphics :P. I've noticed on several threads on this forum that people recommend against saving bitmap data in a header file, and by searching around I've figured out why.. but I'm still not sure about the how else i should do it.
The best would be if the bitmaps could be converted to .o-files that the compiler could link - but I don't know how those files should look like. Does anyone have any good links where i could read up about it? I've found some souces from other converters that do this, but just copying code ain't good m'kay...
The most important thing about this converter is that it should be simple to use and I don't want to spend an eternity writing it. Thanks for any constructive replies.
/Maz
#23958 - poslundc - Sun Jul 25, 2004 3:16 pm
You can still generate your data as a C array, just as you would in a header file if you like. But instead of saving it as a .h file, save it as a .c file, and don't #include it, but rather pass it to the compiler on the command line eg.
gcc myData.c main.c
Then you can create a header file called myData.h that has the same declarations as your .c data file, but declares them as extern and without actually specifying what the data is. This is then what gets #included into your main C program.
This is the "proper" way to link to external data in a C program.
There are several other methods as well (all of which are quicker to compile than using C arrays) but this is the simplest and closest to using .h files.
Dan.
#23961 - f(DarkAngel) - Sun Jul 25, 2004 3:26 pm
Optionally, you can .incbin the raw image file.
_________________
death scream...
#23962 - Lord Maz - Sun Jul 25, 2004 3:30 pm
| Quote: |
You can still generate your data as a C array, just as you would in a header file if you like. But instead of saving it as a .h file, save it as a .c file, and don't #include it, but rather pass it to the compiler on the command line eg.
gcc myData.c main.c
Then you can create a header file called myData.h that has the same declarations as your .c data file, but declares them as extern and without actually specifying what the data is. This is then what gets #included into your main C program.
This is the "proper" way to link to external data in a C program.
There are several other methods as well (all of which are quicker to compile than using C arrays) but this is the simplest and closest to using .h files.
Dan.
|
Yeah, I was actually thinking about that but won't compile times (when doing a full compile) become insanely large after a while? I figured that if the bitmaps are pre-compiled and just linked into the project, it only has to be done whenever the graphics change. Am i wrong?
#23963 - poslundc - Sun Jul 25, 2004 3:49 pm
Yes, the data only needs to be recompiled when it changes. (This is when makefiles become useful.)
But for small projects, even a total recompile should never be a big deal. I'm speaking from some experience, and I'm compiling on a 466 MHz PowerMac.
- You will probably code, and recode, many MANY converters over the course of programming a GBA game.
- You should code them in such a way that the code that writes the output file is kept separate (insulated) from the code that does all of the processing of the image.
That way, as your project grows and if compile times becomes more of a pain, you can start encoding in assembly, or using one of the techniques for including raw image data (such as .incbin, or GBFS).
Dan.
#23967 - Lord Maz - Sun Jul 25, 2004 6:38 pm
Well, the problem is, the project I'm on is not a small one. Right now it takes about 8 minutes to do a full compile on my 2GHz Pentium, and it's still rising every month.
However, after more searching, I've found some info about it at http://www.devrs.com/gba/files/gbadevfaqs.php. Not sure I can use that info, but I'll try and come back here if it doesn't work :)
#23969 - sajiimori - Sun Jul 25, 2004 7:10 pm
IMO, it's way better to output raw binaries and convert them to .o files using objcopy. If and when that becomes cumbersome (perhaps due to global namespace clutter), you can switch to one big .o file that has a filesystem.
#23970 - tepples - Sun Jul 25, 2004 7:10 pm
Eight minutes with a batch file recompiling everything, or eight minutes with a makefile compiling only files that depend on files that have changed?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#23990 - dagamer34 - Mon Jul 26, 2004 2:26 am
| Lord Maz wrote: |
Well, the problem is, the project I'm on is not a small one. Right now it takes about 8 minutes to do a full compile on my 2GHz Pentium, and it's still rising every month.
However, after more searching, I've found some info about it at http://www.devrs.com/gba/files/gbadevfaqs.php. Not sure I can use that info, but I'll try and come back here if it doesn't work :) |
Do you run clean after every compile to clean up intermediate files? That really slows compile time especially when you only change one or two things around...
_________________
Little kids and Playstation 2's don't mix. :(
#23997 - Lord Maz - Mon Jul 26, 2004 5:38 am
| dagamer34 wrote: |
| Lord Maz wrote: | Well, the problem is, the project I'm on is not a small one. Right now it takes about 8 minutes to do a full compile on my 2GHz Pentium, and it's still rising every month.
However, after more searching, I've found some info about it at http://www.devrs.com/gba/files/gbadevfaqs.php. Not sure I can use that info, but I'll try and come back here if it doesn't work :) |
Do you run clean after every compile to clean up intermediate files? That really slows compile time especially when you only change one or two things around... |
No, I don't, but since we're on a CVS i need to do full compiles fairly often. Committing code that hasn't been fully compiled breaks it for the others nearly all the time, there's always another "multiple defined object" or something else you've forgotten to fix.
Thanks sajiimori, one big .o-file that has a filesystem sounds like a neat solution. I'll look into it.
#24004 - col - Mon Jul 26, 2004 12:58 pm
| Lord Maz wrote: |
...Committing code that hasn't been fully compiled breaks it for the others nearly all the time, there's always another "multiple defined object" or something else you've forgotten to fix. ...
|
That's a little surprising - with a properly configured makefile, you should be able to avoid having to re-compile the whole project in most instances?
How are the dependencies processed in your makefile?
cheers
Col
#24016 - Lord Maz - Mon Jul 26, 2004 6:01 pm
To be honest - I wish i knew ;) I haven't been messing around with makefiles and such much before I started with this GBA project, and even though I do know what you're talking about (been reading up about the basics atleast) I'm not sure how we're handling it.
Anyway, that's not the point - nearly all of you are off-topic ;) If you have info about how objectfiles work, please post it. I'm grateful for any help.
#24025 - dagamer34 - Mon Jul 26, 2004 8:05 pm
| Lord Maz wrote: |
To be honest - I wish i knew ;) I haven't been messing around with makefiles and such much before I started with this GBA project, and even though I do know what you're talking about (been reading up about the basics atleast) I'm not sure how we're handling it.
Anyway, that's not the point - nearly all of you are off-topic ;) If you have info about how objectfiles work, please post it. I'm grateful for any help. |
We're all off-topic? I thought the topic was to try and help you? Or were we wrong?
_________________
Little kids and Playstation 2's don't mix. :(
#24027 - sajiimori - Mon Jul 26, 2004 8:22 pm
It may sound a little ungrateful to call everybody "offtopic" when they're trying to help, but I can understand his position when people are trying to argue him into doing things their way (i.e. C files as resources).
Full recompiles are a fact of life. On my current project we're using a filesystem, and when it changes most modules have to be rebuilt because make doesn't know which files each module is accessing.
#24031 - torne - Mon Jul 26, 2004 9:01 pm
objdump to convert binaries to object files has always worked fine for me. =)
#24035 - batblaster - Mon Jul 26, 2004 9:22 pm
Before writing yours did you see already all others available ??? I'm writing this not because you can't write yours but if you need to convert gfx soon you can use one already available like Kaleid (very fast and good)...
_________________
Batblaster / 7 Raven Studios Co. Ltd
------------------------------------------
#24067 - Lord Maz - Tue Jul 27, 2004 10:42 am
Mm, I could use something made by someone else (we've been doing it so far) but that doesn't give me the level of control I'm looking for.
Sajiimori, I didn't mean to offend any of you (notice the smilie). I'm trying to find out the best way to compile bitmaps into the project - I'm not really interested about the dependencies in our makefile, etc. Sure, I guess it would help me if I knew about it, but right now it can wait. Thats why I'm saying we're floating a bit off-topic.
#24068 - Lord Maz - Tue Jul 27, 2004 11:10 am
*To be a little more specific about my problem*
So, this is how I do it so far:
arm-agb-elf-objcopy -I binary -O elf32-littlearm test.bmp test.o
It doesn't work at all, all I get is random noise when I try to use the data ingame. Can someone help me get from this point to actually get the data compiling working?
#24090 - dagamer34 - Tue Jul 27, 2004 8:18 pm
| Lord Maz wrote: |
*To be a little more specific about my problem*
So, this is how I do it so far:
arm-agb-elf-objcopy -I binary -O elf32-littlearm test.bmp test.o
It doesn't work at all, all I get is random noise when I try to use the data ingame. Can someone help me get from this point to actually get the data compiling working? |
I don't think you can just add "test.bmp" to the linker options in order for it to work. Try searching for a program called bin2o on this website, then you can link it in that way. Make sure you make a header declaring your data as being externally linked, otherwise the compiler will complain at you.
Or you could just use .incbin in an assembly file.
_________________
Little kids and Playstation 2's don't mix. :(
#24129 - Lord Maz - Wed Jul 28, 2004 10:18 am
| dagamer34 wrote: |
I don't think you can just add "test.bmp" to the linker options in order for it to work. Try searching for a program called bin2o on this website, then you can link it in that way. Make sure you make a header declaring your data as being externally linked, otherwise the compiler will complain at you.
Or you could just use .incbin in an assembly file. |
Heh, whoops, didn't realize at first that objcopy copied the whole bitmap (including headers and stuff), so I modified my gfxconverter program to output raw binary data from the bitmap I used, objcopied that and it worked perfectly in the GBA.
Now I'm interested in what sajiimori said before. How exactly do I make a objfile with a filesystem? I can't even figure out how to include more than one binary in a objfile right now, arm-agb-objcopy doesn't seem to support it (or I just can't find the right switch ;).
#24149 - tepples - Wed Jul 28, 2004 3:41 pm
| Lord Maz wrote: |
| How exactly do I make a objfile with a filesystem? |
Try GBFS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#24157 - Lord Maz - Wed Jul 28, 2004 5:53 pm
| tepples wrote: |
| Lord Maz wrote: | | How exactly do I make a objfile with a filesystem? |
Try GBFS. |
Hmm, that looks nice, but it's not what I had in mind. Screw what I said about filesystems, I just want to know how to pack in several images into one objectfile. Is it even possible?
#24158 - torne - Wed Jul 28, 2004 6:18 pm
Concatenate them together before converting them with objcopy, if you know the sizes (you'll have to pick them back apart manually). Why do you want to do it that way anyway? If you're just going to have a few images appended together, rather than a real FS, I can't see why they need to be in the same object file. There's no problem with having lots of objects, it doesn't take up any more space in your ROM.
#24190 - Lord Maz - Thu Jul 29, 2004 11:23 am
| torne wrote: |
| Concatenate them together before converting them with objcopy, if you know the sizes (you'll have to pick them back apart manually). Why do you want to do it that way anyway? If you're just going to have a few images appended together, rather than a real FS, I can't see why they need to be in the same object file. There's no problem with having lots of objects, it doesn't take up any more space in your ROM. |
Good point. Though I'm a bit terrified of having about 200 or more objects popping up for every row in the compiler log.. One big file is much nicer.
Here's how I'm thinking of doing it: Concaternate em all, save them to a single objectfile, and save a header that contains the offset to each bitmap, and their sizes. Any comments on efficiency or anything about that?
#24193 - torne - Thu Jul 29, 2004 12:43 pm
I don't see where the problem with having 200+ lumps of data is. Add them to an ar archive, and have your makefile update the archive rather than recreate it; then, you will only ever see all 200 object names if you make clean. When you link the data to the rest of your program, it will just be the name of the archive.
Concatenating them together with an extra object containing their sizes and offsets is absolutely identical to not concatenating them together and using the linker's autogenerated symbols telling you the sizes and offsets, if you think about it, except you know for sure the linker won't make a mistake.
#24200 - Lord Maz - Thu Jul 29, 2004 4:47 pm
Seems like a nice solution, I'll try and see if i can figure out how ar works. Thanks for the info.
#24202 - Lord Maz - Thu Jul 29, 2004 5:07 pm
Okay, archiving files was easy but how do I use them when compiling?
#24206 - torne - Thu Jul 29, 2004 5:44 pm
Just include the archive as if it was an object file when you link, and the linker will include the contents of the archive.
#24241 - Lord Maz - Fri Jul 30, 2004 11:26 am
Strange thing is, I'm doing just that but it won't work.
First I compiled a object file, and using it worked fine. Then I archived it like this:
arm-thumb-elf-ar -r gfxarchive testraw1.o
I checked so some symbols were defined with nm -s gfxarchive, and got these results:
_binary_testraw1_c_start in testraw1.o
_binary_testraw1_c_end in testraw1.o
_binary_testraw1_c_size in testraw1.o
testraw1.o:
00000040 D _binary_testraw1_c_end
00000040 A _binary_testraw1_c_size
00000000 D _binary_testraw1_c_start
So i put in gfxarchive into my included objectfiles, and used this code:
extern unsigned char _binary_testraw1_c_start[];
It gives me an undefined referance. Any idea why?
#24243 - torne - Fri Jul 30, 2004 1:40 pm
Give the archive a .a extension so that gcc knows what to do with it. =)
#24291 - Lord Maz - Sat Jul 31, 2004 10:36 pm
Just renaming it didn't work. But I suspect it's still the same problem; are you sure it extracts the archive when it's listed among the objectfiles? When I include only the objectfile, it always gives a warning (something about the architecture) but it doesn't do that when it's archived.
#24292 - wintermute - Sat Jul 31, 2004 10:48 pm
list the archive *after* the object files which reference things in the archive.
#24317 - Lord Maz - Sun Aug 01, 2004 2:26 pm
Oh, I didn't realize the order mattered, haven't got any problems with it before. Now it works great!
A big thanks to everyone who's helped me with this; I give you all an extra + for your patience ^^