flure wrote:Well, the real reason I'd like my homebrew to work on any linker menu is that I'm making NDS demos, and if I want them to be widely watched, I can't force people to change their menu. If they'd like to run cracked games, it's their problem...
By the way, I've thought about a way of making libfilesystem work on any menu without the need of argv, maybe it could work, but I'm really not sure if it's possible, so let me know what you think about it.
The algo is based on the scanning of the subdirectories to find the NDS file, so it may be long. Here it is :
1) on compile time put in the root of the nitrofs directory a simple text file with the compile date and other infos if needed. This text has just to be uniquely identifiable. Also put in the executable, at the same time, the same info using the -D flag.
2) on execution, supply the expected nds file name to nitroFSInit
How without argv support you don't know what the .nds file name is going to be, and I've got a feeling your next step will be a "Scan the SD card for the nds file".
flure wrote:
3) first try to find the nds file from this file name.
4) if the nds file is found, try to init the filesystem and open the text file.
5) Compare its contents with what is expected.
6) If they're equal, we're done ! If not, scan all the directories and try from 3) for each nds file found
FFS this is WHY we need to get ARGV support on ALL launchers, and it's starting to get on some of the more widely used, homebrew friendly ones. For the ones that are not HB friendly there's the HBMenu option. What you have described is not a good idea as it involved what every EFS user does right now - searching though the SD card for the nds file, I'm sorry but this is not what you should be doing. If you start doing this then the cart makers will not support the ARGV protocols, then you'll have people complaining that their latest HB does not work on cart XYZ, who's dev turn around and say well it's not our fault, it's the HB coders fault, speak to them.
The argv protocol (which also adds the option to exit from your apps to the boot launcher for your card BTW) is the only way we should be using libFilesystem, if someone is trying to view your demo's on a non-argv cart point them at the hbmenu page on devkitPro.org and tell them to point the cart maker there as well. The EU can get a temp fix to run HB until the cart maker pulls it's socks up and gets on board the argv protocol train.
flure wrote:
What do you think about it ? I believe it should work, though it could make loading times grow with the number of nds files in the card...
I'm not sure I'm skilled enough to make it, but I will try it if nobody does it.
Please don't bother it's this kind of attitude that we need to get out of the HB scene as it's counter productive for you health.
What happens if the date time is corrupt? This is why HBMenu exists, this is why we need to pressurise the cart makers to include argv support - hell it's been in the toolchain for well over a year now and it's only JUST getting implemented in a couple of cards now, more pressure faster uptake...
A little history:
EFS was created from a fork of libFilesystem and it added the ability to write data back to the NDS file, great in principle, but what happens when you upgrade your nds file? you loose your save data. EFS works like you sugested, but as you pointed out at the end, it increases the loading time of your app expotentially as you have, in the worst case, to scan every .nds file twice in your SD card to find your game's nds file. HBMenu on the other hand just puts the location into memory and the start code just sets a couple of pointers and libFilesystem works fine. Also what happens in the future if there's a change to the way that the files are stored in the NDS file? or if the date time stamp your looking for is corrupt?
