#58794 - blaisef01 - Wed Oct 26, 2005 2:35 am
I'm currently using GBFS to compile my textures, sounds and other crap into my code but I seem to be running into a few problems.
I have 4 files in my data directory:
dummy.txt 26 bytes
explode1.tex 32780 bytes
hudctr.tex 8204 bytes
plyrship.tex 1036 bytes
total size: 42046 bytes
If I try and compile and run my code (on hardware, don't use emulators) all I get is a black screen for my trouble. But if I remove the hudctr.tex file the code runs fine. The hudctr.tex file isn't being used anywhere in the code or being loaded in to texture memory. It's just there in the data directory and GBFS for some reason doesn't like it.
I'm rambling and probably haven't made this too clear as it's 2 in the morning and am tearing my hair out. But yet in my last project i had 332KB worth data in my data directory and GBFS was fine with that?
I dunno what's going on, anyone have any clue...
Cheers
#58796 - tepples - Wed Oct 26, 2005 3:05 am
How are you loading the GBFS file? Appending it works only on ds.gba programs. On other media you have to use bin2s (or a bin2o macro that wraps bin2s) or use chishm's CF driver to load the GBFS file.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58797 - blaisef01 - Wed Oct 26, 2005 3:18 am
I'm flashing a ds.gba file to my EFA256 flash card, the code works though if i don't include the hudctr.tex file despite the fact that that file isn't being called in the code at all at present.
#58798 - tepples - Wed Oct 26, 2005 4:00 am
Chat log:
(21:22:02) blaisef01: sorry to bother u with my ds code nonsense, but this is really doing my head in
(21:22:19) tepples: it's about hudctr.tex right?
(21:22:25) blaisef01: yep
(21:22:46) tepples: Are you making sure to check all return values from GBFS to make sure you aren't getting null pointers?
(21:24:20) blaisef01: unfortunately i can't even do that as i have no way to write any data to screen if hudctr.tex is included in the data directory, the screen goes black
(21:26:14) tepples: You can set the screen to a constant color depending on what happens in the GBFS setup.
(21:27:10) blaisef01: trying that now 1 sec
(21:29:36) blaisef01: damn a null pointer
(21:30:01) tepples: Is it in find_first_gbfs_file() or in gbfs_get_obj() ?
(21:30:17) tepples: One to red and the other to yellow might help.
(21:30:37) blaisef01: i'm just using gbfs_get_obj for all occurances,
(21:30:56) tepples: So how are you finding the base address of the GBFS file?
(21:32:27) blaisef01: i was using the same method described in the examples\filesystem\embedded_gbfs
(21:32:43) tepples: Is it doing find_first_gbfs_file() ?
(21:32:46) blaisef01: nope
(21:33:02) blaisef01: that was the way i was doing stuff before and all seemed to be fine
(21:34:05) blaisef01: just gonna test using 1 red and 1 blue null check
(21:34:33) tepples: it's using what appears to be the bin2s method
(21:34:56) blaisef01: which should be fine as i'm using a ds.gba file right?
(21:35:21) tepples: If you use ds.gba then it's best to use the appended method
(21:35:31) tepples: I'm examining the makefile right now.
(21:35:39) blaisef01: cheers
(21:36:27) tepples: Do you have the lsgbfs command in your installation?
(21:36:57) tepples: If you don't have lsgbfs and ungbfs, you can get them at
http://www.pineight.com/gba/#gbfs
(21:37:00) blaisef01: yeah it's in devkitpro\blahblah\bin
(21:37:14) tepples: try doing
lsgbfs data.gbfs
(21:37:37) blaisef01: just a command or should that be in the makefile somewhere
(21:37:42) tepples: just a command
(21:37:54) tepples: It's to be used as a diagnostic tool.
(21:39:20) blaisef01: no such file apparently... let me check my make file
(21:39:30) tepples: Probably a path issue.
(21:39:51) blaisef01: it found the command just could find a data.gbfs file
(21:40:03) tepples: it might be in a different folder
(21:41:24) blaisef01: just done a search no data.gbfs file, there's a data.gbfs.o file though
(21:41:51) tepples: Try deleting data.gbfs.o and rebuilding and seeing what breaks.
(21:43:31) blaisef01: it gives a null on the first file but not the second
(21:44:11) tepples: If there is no data.gbfs file then your build process is screwed up.
(21:45:13) blaisef01: great - just looked at the build log some where in one of the make files there's a rm data.gbfs command. I just grabbed on of the template makefiles and used that worked fine for ages until now :(
(21:45:39) tepples: Delete that rm command from the makefile. It should be in make clean if anywhere.
(21:48:23) blaisef01: either i'm blind or stupid but i cannot seem to find a rm data.gbfs
(21:51:17) blaisef01: this is strange it should be in the arm9 makefile but i can't see it for squat
(21:51:34) tepples: Unless it's in the standard "rules"
(21:52:11) blaisef01: where the hell are those, i've never really worked with makefiles, i'm used to vc++ doing all this shit for me
(21:52:39) tepples: They're standardized rules for some targets that are to be built
(21:53:39) blaisef01: i take it that would be all the bin2o stuff
(21:54:45) tepples: I see the problem: it puts the gbfs file in the data folder, but it uses the contents of the data folder to find what files to put into the gbfs file.
(21:55:39) blaisef01: so how would we solve this?
(21:55:45) tepples: For that you'll have to modify the makefile. I can't help you with that until I learn how to program the DS myself.
(21:56:06) tepples: I already ditched the example makefiles.
(21:56:15) tepples: Have you programmed the GBA before?
(21:56:41) blaisef01: nope went from pc to psx to ps2 to getting fired and now ds
(21:57:32) tepples: Try GBA first. It's an easier environment to learn in, although you'll have to start in 2D.
(21:58:05) blaisef01: it's not the ds which is the problem, i have got 3d models and skinned stuff running on the ds, it's just this gbfs thingy
(21:58:29) tepples: In order to learn anything but the 3D environment (which is a GL clone), you'll need to have a bit of GBA experience under your belt.
(21:59:17) tepples: You can do 3D only on one screen; if you want anything but blackness on the other screen, you'll need to know how to program the DS's 2D core, and the GBA is a stepping stone to that.
(21:59:44) tepples: Point: I can't help you with the makefile until I myself gain some experience on the DS, and there are things that have to happen in my life before that can happen.
(22:00:10) tepples: It would involve me making my own DS makefile template the way I completely rewrote the GBA makefile template.
(22:00:44) blaisef01: i understand that, we all have proper lives to lead but is there a direction you could point me in.
(22:01:05) blaisef01: from there i should be able to blunder my way to my objective
(22:01:10) tepples: The direction is waiting for other people to reply on the forum once I've posted this chat log.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58805 - cybereality - Wed Oct 26, 2005 5:25 am
I had some issues with getting the GBFS to work correctly, with the same black screen you said. I'm not sure what your exact issue is, but I managed to fix mine. Heres a few things to try:
Make sure you are using padbin on the compiled file before you append the GBFS file. You can search the forums for the syntax.
Make sure the total of your files is under 16MB and any single file is not larger than 4MB.
You might have to hardcode the memory address for the GBFS file. I tried to load it dynamically (with the find_first_file(find_first_file)) method) and it didn't work for me. If I gave it incorrect memory address it would black screen like you said. I just keep trying different address (educated guesses) until there was no black screen.
Other than that i would just try a little trial and error. For instance, change the name of the file to _hudctr.tex or xHudctr.tex. I know it sounds dumb, but sometimes things like this will fix it. Also, try to verify that the hudctr.tex is a valid file. So try just loading that file into a simple test app. Do the same with each of the 4 files. Then try loading different combos of files until you can load all 4, then transfer that code back into the game code. Maybe try loading in some dummy files that are bigger than 26 bytes. Hope that helps.
_________________
// cybereality
#58808 - wintermute - Wed Oct 26, 2005 6:51 am
| tepples wrote: |
(21:32:43) tepples: Is it doing find_first_gbfs_file() ?
|
The current example doesn't require find_first since the data file is embedded directly and a name provided to reference it with.
| Quote: |
(21:41:24) blaisef01: just done a search no data.gbfs file, there's a data.gbfs.o file though
(21:41:51) tepples: Try deleting data.gbfs.o and rebuilding and seeing what breaks.
(21:43:31) blaisef01: it gives a null on the first file but not the second
(21:44:11) tepples: If there is no data.gbfs file then your build process is screwed up.
(21:45:13) blaisef01: great - just looked at the build log some where in one of the make files there's a rm data.gbfs command. I just grabbed on of the template makefiles and used that worked fine for ages until now :(
(21:45:39) tepples: Delete that rm command from the makefile. It should be in make clean if anywhere.
(21:48:23) blaisef01: either i'm blind or stupid but i cannot seem to find a rm data.gbfs
|
In the current example the gbfs file is never referenced directly in the Makefile so make treats it as an intermediate file and deletes it once the build is complete. The rm is an automatic thing.
| Quote: |
21:54:45) tepples: I see the problem: it puts the gbfs file in the data folder, but it uses the contents of the data folder to find what files to put into the gbfs file.
|
no it doesn't, it puts the gbfs file in the build folder.
In general using the template Makefiles and projects is the best way to ensure that your code will build on other people's systems, rewriting them probably isn't the best way forward if you plan on providing code for other people to learn from.
The example Makefiles and base_rules have been carefully crafted over the last few years to make it as simple as possible for novices to make use of the toolchain without getting into make syntax. There are a number of features that many people leave out of their build systems and, for the most part, they work well even in fairly advanced projects.
#58828 - blaisef01 - Wed Oct 26, 2005 3:29 pm
Current state of play is this. After swapping my makefile for the templated combined makefile, removing the not using a data directory and using the appended method which both tepples and cybereality suggested.
Now I'm able to load in crap loads of files without getting black screens or freezes. Next thing to do is to check my texture importer / exporter to ensure that isn't somehow causing weirdness (doubtful but i'll check anyway)
Cheers lads,
But there is one thing as far as the find_first_file command goes i'm currently supplying it with the address 0x08000000 and it works dandy, is there any reason that could change?
#58887 - tepples - Wed Oct 26, 2005 11:36 pm
| blaisef01 wrote: |
| But there is one thing as far as the find_first_file command goes i'm currently supplying it with the address 0x08000000 and it works dandy, is there any reason that could change? |
What you're doing, find_first_gbfs_file(ROM), should always work in the common case of ds.gba programs.
But about the makefile template: I guess the problem is that I can't figure out how to express multiple levels of dependencies and use VPATH and those .P/.d files.
(Discussion continues here.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#59328 - cory1492 - Mon Oct 31, 2005 5:11 pm
bit of a bump, I had this problem when moving from R13 to R14 - the data that was getting appended to the arm 9 pre-ndstool (not using gbfs though, just a header, data and header again) even when padbin was used was not findable, resulting in a black screen.
Im pretty certain the only way I got it to work was to reduce the size of the appended file, which says to me that something changed limiting the size of the appended to arm9 file to tiny between R13 and R14.
Adjusting my method after days and days and days of looking at the code for the problem, by attaching the same header and file and header to the prebuilt ds.gba worked fine, but broke the ability to load it in some emus and over wifi (and slowed down the initial time it takes to find the beginning and ending headers).
Im glad I figured out how to get it to work, but I doubt I'll ever understand why the build busted between those 2 version.
#59353 - tepples - Mon Oct 31, 2005 7:50 pm
Appended GBFS inside a .nds file broke because .bss (zero-filled memory) was moved to just after the ARM9 binary.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.