#17769 - cpu1333mhz - Sun Mar 14, 2004 4:58 pm
I am (trying) to make a clone of "chip's challenge" and I want to use the existing level data "CHIPS.DAT"
I already know the structure of the file but my problem is i want to include it into my c++ project. If i just drag it i get the hexidecimal view of the file. How can I include this file and access it by address (similar to the array [])? Can i just #include it?
Thank you for your help everyone.
#17774 - Lupin - Sun Mar 14, 2004 5:39 pm
i would search for the "bin2h" tool and then include the output
#17777 - cpu1333mhz - Sun Mar 14, 2004 6:22 pm
Thank you! the tool works great!
#17807 - tepples - Mon Mar 15, 2004 4:03 am
Don't use bin2h; compilation of the .c files it generates is painfully slow. Instead, use bin2s to generate assembly language output that compiles much more quickly.
Or you could try an appended-data architecture such as GBFS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#17811 - torne - Mon Mar 15, 2004 4:49 am
objcopy works well, too; use it to convert binaries directly into ELF objects (storing the bytes as a data segment). This is the fastest way of doing it which doesn't require you to have clever appended-file handling code.
#17812 - cpu1333mhz - Mon Mar 15, 2004 5:10 am
Torne:
Trying to do what you suggested just to check out the differences between OBJCOPY and BIN2H. I can't figure out the flags I need to put in the command line to get what you're talking about. Can you please tell me what flags I should use? Thanks :)
(file src= "chips.dat" dest= "chips.h")
#17818 - torne - Mon Mar 15, 2004 12:30 pm
objcopy doesn't give you a header file, it gives you an object file; this is why it's faster. If you want the data to go into ROM, you do:
| Code: |
| objcopy -I binary -O elf32-arm -B arm --rename-section .data=.rodata,alloc,load,readonly,data,contents inputfile outputfile.o |
(if you want it in RAM, leave off the --rename-section .data=blahblah part).
The resulting object file can then be linked directly into your program. It will generate symbols _binary_inputfilename_start, _binary_inputfilename_end, and _binary_inputfilename_size whose values are, well, what they say. =)
#17839 - Miked0801 - Mon Mar 15, 2004 6:32 pm
What version of objcopy are you using? Just curious as the flags changed quite a bit from version to version.
#17842 - Quirky - Mon Mar 15, 2004 8:42 pm
(if you want it in RAM, leave off the --rename-section .data=blahblah part).
That's IWRAM, I guess. Doesn't seem to be a straight forward way to get bin files in EWRAM, which is a bit of a swizz.
#17845 - torne - Mon Mar 15, 2004 9:36 pm
| Miked0801 wrote: |
| What version of objcopy are you using? Just curious as the flags changed quite a bit from version to version. |
Whichever is current in Cygwin.
#17846 - tepples - Mon Mar 15, 2004 9:36 pm
Usually, if you want assets in EWRAM, one of the following will apply:- You're making a multiboot program. Use objcopy with the --rename-section incantation, and the linker script portions triggered by 'int __gba_multiboot' should handle it properly, rerouting everything that would otherwise go in ROM to go in EWRAM instead.
- You're caching assets that have been decompressed from ROM. Use objcopy with the --rename-section incantation to put the compressed assets in ROM and then have the program decompress them to EWRAM when the player starts a game.
Quirky, what are you doing, specifically, with assets in EWRAM?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#17849 - Miked0801 - Mon Mar 15, 2004 10:41 pm
Can you run a --version on it and post the number, please?
#17850 - torne - Mon Mar 15, 2004 10:56 pm
| Miked0801 wrote: |
| Can you run a --version on it and post the number, please? |
2.14.90
#17851 - Miked0801 - Mon Mar 15, 2004 11:21 pm
Dang, I'm running an old verison. Thanks.
#17865 - cpu1333mhz - Tue Mar 16, 2004 5:11 am
Ahh i see but more questions arise :P
Does including it as a .h file put it in the rom? i have teh data type as "const unsigned char" doesn't the const force it into the rom?
Since the file is small (107 KB) the extra compile time is only about 1 second. But I will gladly check the other tools too ^_^.
By your refrences to the speed of OBJCOPY do you mean the files created with OBJCOPY will read faster on the GBA? or do you mean it just compiles faster? I got a bit confused :/
Thank you for all of your help everyone ^_^
A side question: How badly does Object Oriented Programming affect the speed of execution? For example, I know that every function call has overhead. Should I avoid object oriented programming when I am tweaking something for speed? (I really love OOP :) makes my code nice and clean)
#17875 - torne - Tue Mar 16, 2004 12:29 pm
| cpu1333mhz wrote: |
| Does including it as a .h file put it in the rom? i have teh data type as "const unsigned char" doesn't the const force it into the rom? |
Anything that's const will go into ROM.
| Quote: |
| By your refrences to the speed of OBJCOPY do you mean the files created with OBJCOPY will read faster on the GBA? or do you mean it just compiles faster? I got a bit confused :/ |
With objcopy there is *no* compile step. objcopy writes an ELF header to the destination file, then just copies all the raw data over unchanged. This takes only fractionally more time that 'cp' would take to copy the file. The comparision is between the time it takes GCC to compile the file which includs the header file (using bin2h) and the time it takes objcopy to dump the data into an ELF object. objcopy will win every time by a lot (though with the sizes of file you are likely to be using, it doesn't make a massive difference; but you really notice when you need to include a 256MB ramdisk image into an executable!). Once the data is in an object file, the rest of the process (linking, converting to .gba, and running it) will be identical.
| Quote: |
| A side question: How badly does Object Oriented Programming affect the speed of execution? For example, I know that every function call has overhead. Should I avoid object oriented programming when I am tweaking something for speed? (I really love OOP :) makes my code nice and clean) |
Only virtual function calls have overhead. If you don't use any virtual functions at all, there is no fundamental reason why OO code would be any slower whatsoever. When virtual functions are used, a couple of cycles are added to virtual calls, and objects will be four bytes larger as they have to contain a vtable pointer. Other C++ features you might want to be cautious about include templates (they can make your code very large if you instantiate them many times) and the STL (the algorithms in there are very very safe which generally makes them slower than custom implementations).
If you like OO-style code and you are comfortable with C++, then you should use it. Try to avoid virtual, but if you find you do need it, use it anyway. Premature optimisation is bad; write your code and make it work first, and don't worry about speed until it's working, but working too slow. =)
#17878 - OptiRoc - Tue Mar 16, 2004 2:15 pm
Indeed there's a certain overhead in C++ features like virtual function calls, exceptions, etc. Use them with care. However, when there's a good reason to use virtual objects, getting the same functionality without them usually results in the same degree of speed penalty, at best.
#17906 - cpu1333mhz - Wed Mar 17, 2004 12:07 am
Thank you everyone for all of the information you have provided me. It has helped alot ^_^
Thanks again!
#17923 - shadow_gg - Wed Mar 17, 2004 4:31 pm
oups didn't c other ones answered ;)
#18116 - cpu1333mhz - Sat Mar 20, 2004 10:18 pm
From experimentation i've learned that function calls do indeed have overhead! (As well as calls to object member functions in object-oriented programming) :/
Every variable passed adds to this overhead as well.
Guess i'll be eliminating functions if my game gets too slow :P (slow to me = 1 missed frame at any given moment HAHA :P)
#18118 - OptiRoc - Sat Mar 20, 2004 10:21 pm
"inline" is your friend.
#18119 - Miked0801 - Sat Mar 20, 2004 10:48 pm
When the compiler listens to your inline request...
But yes, inline is the way to go for low, low level things. Don't go cut-and-pasting code as it will hurt you later when maintaining
#18265 - cpu1333mhz - Tue Mar 23, 2004 6:17 am
Yhea you're right. I was going with the no functions thing until I needed to change something :P
Hmm, i'll consider inline functions.
I was thinking about functions [not inline] and classes and now that i think about it, classes are better [and faster] than functions because I can make my class hold pointers to variables in my main code and I wouldn't need to pass them to the class every time I call a member.
With functions, I would need to pass the pointers every single time I call the function. This can be a big slowdown if i'm looping and passing, say, 10 pointers.
So I guess i'll be going with Objects (which is actually preferable because that's how I started coding it to begin with and most my current work is already done with objects as it stands)
#18266 - tepples - Tue Mar 23, 2004 6:22 am
Passing ten pointers? In theory, the only thing C++ classes/structs (with methods) buy you over C structs (without methods) is one argument ('this', passed by pointer implicitly to any non-static method), not ten. Could you please give an example of how OO saves passing ten pointers? If you're calling a non-static method, you're probably just passing a pointer to a class/struct containing those ten pointers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18271 - Miked0801 - Tue Mar 23, 2004 7:50 am
10 pointer, hehe. Put them in a struct and pass the address of that. If you can't, redesign as you've gone terribly wrong :)