#55566 - christosterone - Thu Sep 29, 2005 2:05 pm
I am used to having room files and then parsing that into a level in the game at runtime.
ex the room file would look like this:
width:5
height:7
torch:4,5
Can I have the gba open and read separate files? If not, what would you suggest to load many, separate rooms at runtime? If i create header files with the data that might work, but loading room files is a lot cleaner and simpler.
Any suggestions?
Chris G
#55585 - tepples - Thu Sep 29, 2005 6:09 pm
| christosterone wrote: |
I am used to having room files and then parsing that into a level in the game at runtime.
ex the room file would look like this:
width:5
height:7
torch:4,5
Can I have the gba open and read separate files? |
Have you tried GBFS yet?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#55586 - poslundc - Thu Sep 29, 2005 6:12 pm
The GBA does not have a native file system. ROM data is mapped to memory locations 0x08000000 and above. So you can access any data you want just by grabbing the correct pointer to the memory (usually through a named, const variable so you don't need to worry about the actual location).
You can impose a wrapper file system like tepples' GBFS if you desire, which has its own distinct advantages, but isn't necessary for GBA programming. If you use it, then I expect you can have as many "open files" as you desire.
Dan.
Edit: tepples posted first...
#55665 - sgeos - Fri Sep 30, 2005 10:49 am
Getting resources onto the GBA is one of the obstacles you face when programming for it. I'd preprocess your files and spit out functions to build your rooms. Then I'd make a table of function pointers, but that is just me.
-Brendan
#55671 - Touchstone - Fri Sep 30, 2005 11:57 am
I agree with sgeos. With the gba you have a great opportunity to avoid anything even remotely resembling files. You can do pretty much anything data related as const data structures, especially if you create C or assembler-files that is compiled and linked into the game, that way you can use code symbols instead of fixed adresses.
_________________
You can't beat our meat
#55680 - tepples - Fri Sep 30, 2005 4:05 pm
[fanboy="GBFS"]
But if you make everything as const data structures, then your artists will have to have a copy of devkitARM installed on their machines in order to test their work in an emulator, and it'll take longer to build the program as the compiler and linker have to process everything, not just the code.
[/fanboy]
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#55726 - Touchstone - Sat Oct 01, 2005 12:25 am
Yes, one of the problems data in const arrays is artists having to compile the game each time they want to test their new stuff. Another problem is of course if your current room data is referring to other data that doesn't exist yet you cannot properly link a game binary. This is probably a lot bigger problem as it's likely that your artist still have to have some sort of tool to convert their Photoshop images to a format that's readable in your game and I assume that the game binary still have to be modified by some sort of tool to include data files with your GBFS.
It will probably take longer to build your game to but obviously the data is only compiled once when it's changed so you don't recompile all your data files when you recompile your game. Unless you really want to.
Considering that const arrays doesn't have to be parsed by the gba I think makes it a lot easier to write safe checking code. You have tons of more ram and cpu on a PC obviously, and probably better debugging possibilities. Uhm.. So, yes.. That's what I'm thinking right now.. :-)
_________________
You can't beat our meat
#55728 - tepples - Sat Oct 01, 2005 4:10 am
| Touchstone wrote: |
| This is probably a lot bigger problem as it's likely that your artist still have to have some sort of tool to convert their Photoshop images to a format that's readable in your game |
Then put 'make', 'gbfs', and 'gfx2gba' on each artist's machine. That's a lot smaller than the GCC and Binutils packages.
| Quote: |
| and I assume that the game binary still have to be modified by some sort of tool to include data files with your GBFS. |
True, but this "some sort of tool" simply involves padding the ROM to a multiple of 256 bytes, and the programmer can do this before shipping a nightly build out to artists.
| Quote: |
| It will probably take longer to build your game to but obviously the data is only compiled once when it's changed so you don't recompile all your data files when you recompile your game. |
I forgot to mention linking. Or does GCC 4 have incremental linking now?
| Quote: |
| Considering that const arrays doesn't have to be parsed by the gba I think makes it a lot easier to write safe checking code. |
You can generate binary files of level data matching a struct layout, stuff those into a GBFS file, and then have the GBA read those. I used this technique in TOD, and I'm using it now in Luminesweeper.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
Last edited by tepples on Sun Oct 02, 2005 1:35 pm; edited 1 time in total
#55786 - sgeos - Sun Oct 02, 2005 6:44 am
You probably want to created all your linked rooms on the PC before you export to some sort of custom GBA storage format. (Test now and then, of course.)
-Brendan
#55822 - Touchstone - Sun Oct 02, 2005 8:01 pm
| tepples wrote: |
| Then put 'make', 'gbfs', and 'gfx2gba' on each artist's machine. That's a lot smaller than the GCC and Binutils packages. |
I doubt that harddrive size is what matters the most though. It's more likely to be how easy the tool is to use and I image both ways could be made just as simple to use.
| tepples wrote: |
| I forgot to mention linking. Or does GCC 4 have incremental linking now? |
I haven't tried GCC4 so I can't say. It will probably be slower to link with all data as const data rather than just linking your game code. I can't tell if linking all data as const is slower than linking and then running the tool that appends the data as files at the end of the binary though. I figure that that have to take some amount of time aswell, although it's probably faster. On the other hand you would have to dynamically access your game data through a file system instead of just reading the value of a ROM address. If that includes hashing through a string table an then parsing the file data then I'd probably go with longer linking times anyhow.
| tepples wrote: |
| You can generate binary files of level data matching a struct layout, stuff those into a GBFS file, and then have the GBA read those. I used this technique in TOD, and I'm using it now in Luminesweeper. |
Yeah, this can be done altough you'd probably be introducing a whole slew of unecessary bugs. Ugh, I can just see all the structure data alignment bugs from piling up. :-) "What the heck, the structure contain one byte, one int and one byte and that's exactly how I've stored it in my binary, what gives". Sure, you'll most likely learn to avoid this if you've been burnt once and if you are planning on having any of these structures in ram you would probably have to arrange the data in an as optimised way as possible anyways.
One cool thing about having your data in const structures is that the data and the c symbols are in ROM. You don't have to have variables in RAM to point to your data to access any part of it. If you at any time would need to know how many animation sequences your hero have you could just type heroAnim.SequenceCount and there it is. RAM usage is obviously nice to keep to a minimum aswell and this helps with that.
_________________
You can't beat our meat