#172661 - sverx - Tue Feb 23, 2010 2:25 pm
Hi
I'm sure this has been already asked but I'm sorry I really coudn't find it in here :|
The question is: how can I implement a savegame and/or hiscore save feature in a homebrew game without using any filesystem, if there's a chance? R4/AceKard/other(s) cards can emulate an EEPROM onboard on the cartridge, as far as I know, so actually it should be enough to write to EEPROM, right? If this is the case, does libnds has function for EEPROM read/write?
Thanks in advance for your answers :)
#172663 - Dwedit - Tue Feb 23, 2010 2:51 pm
Maybe just use EFS, so it will writeback to your NDS file?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#172664 - sverx - Tue Feb 23, 2010 3:11 pm
| Dwedit wrote: |
| Maybe just use EFS, so it will writeback to your NDS file? |
EFS is one of the options I'll consider using when I'll be sure there's no other option... it's not I'm against filesystems, it's that EFS doesn't work with some cards and I'd like to avoid using FAT because of the 'external' files that have to be copied to specific dirs, you know...
I believe commercial games have some EEPROM (or similar) chip inside them, can't we just pretend to have a similar chip too and leave to the R4/AceKard/WhateverCard the burden of saving the info to its SAV file?
Or any other idea?
#172665 - Sektor - Tue Feb 23, 2010 5:14 pm
The menus patch the EEPROM routines so they write to the flash but they won't patch homebrew since homebrew doesn't use Nintendo code and looks different to a commerical .nds file.
Any decent flash cart supports DLDI/libfat and since homebrew can write to the flash directly, there's no need for it to use EEPROM routines that get patched.
_________________
GTAMP.com/DS
#172666 - Lazy1 - Tue Feb 23, 2010 5:26 pm
| sverx wrote: |
| Dwedit wrote: | | Maybe just use EFS, so it will writeback to your NDS file? |
EFS is one of the options I'll consider using when I'll be sure there's no other option... it's not I'm against filesystems, it's that EFS doesn't work with some cards and I'd like to avoid using FAT because of the 'external' files that have to be copied to specific dirs, you know...
I believe commercial games have some EEPROM (or similar) chip inside them, can't we just pretend to have a similar chip too and leave to the R4/AceKard/WhateverCard the burden of saving the info to its SAV file?
Or any other idea? |
Don't more flashcart loaders support argv now?
If not, make it a requirement so when enough homebrew does require it the flashcart devs will be forced to support it.
#172668 - sverx - Tue Feb 23, 2010 5:33 pm
| Sektor wrote: |
| The menus patch the EEPROM routines so they write to the flash but they won't patch homebrew since homebrew doesn't use Nintendo code and looks different to a commerical .nds file. |
Oh, thanks, I never knew how they work! So it means I can't use those features in my program... mmm
| Sektor wrote: |
| Any decent flash cart supports DLDI/libfat and since homebrew can write to the flash directly, there's no need for it to use EEPROM routines that get patched. |
I'm not concerned about decent flash carts ;) ... BTW, in general, FAT is more likely to work than EFS on 'not 1st choice' carts? Which pros/cons would you suggest about using EFS versus FAT?
Thanks! :)
#172670 - wintermute - Wed Feb 24, 2010 12:19 am
EFS is basically a poor quality rip off of the nitrofs component of libfilesystem written by Eris. I really suggest avoiding it in favour of libraries which are actively worked on and supported. It's also better for end users and the community in general.
The best way to achieve what you want is to make an argv supporting card menu a requirement for your game. Currently that's hbmenu and akaio.
What I'm still undecided on with the nitrofs part of libfilesystem is whether to change working directory to the nitro filesystem or leave it up to the programmer which way to go. Basically we can leave the working directory as the path to the nds file, allowing you to simply save your high scores there, and access the nitrofs with a device specifier ( "nitrofs:/" ) - obviously the programmer can chdir to nitrofs:/ & access files that way. The other option is to automatically change the device on nitro init and leave the programmer to find the path from argv. libfat already switches to the path of the loaded nds file if argv is filled properly.
Obviously this leaves people using emulators with no way to save but I don't see that as any particularly big loss. Having said that there is talk of implementing a host file system protocol in desmume which may be the way forward.
Attempting to support any & all cards is just a horrendously bad idea - we'd be much better off recommending a particular card for homebrew and sticking with that. Essentially we say "if your card doesn't support dldi and argv then sorry, you need a better card". This also gives us the option of supporting homebrew oriented stores like Electrobee, run by our own Natrium42, rather than filling the pockets of random chinese pirates.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172674 - Sektor - Wed Feb 24, 2010 5:06 am
hbmenu didn't work on my DS-X last time I tried but I never considered that a decent card. I still love the USB, it's so much easier than microSD swapping.
_________________
GTAMP.com/DS
#172677 - sverx - Wed Feb 24, 2010 9:49 am
| wintermute wrote: |
| EFS is basically a poor quality rip off of the nitrofs component of libfilesystem written by Eris. |
Does this mean I can use NitroFS instead of EFS and it'll probably work better than EFS? It's not I'm attempting to support any and all cards, I just want to be quite sure that it'll work on most common ones...
| wintermute wrote: |
| The best way to achieve what you want is to make an argv supporting card menu a requirement for your game. Currently that's hbmenu and akaio. |
I understand this, but I believe most people just won't buy another cart to run my game. :| So what of course I could do, if I'll choose to use FAT, is favour those and force other to copy directory and files to a specific location... (I'm assuming that 'argv supporting card menu' means that I can get the NDS file location as a parameter of my main(), is this what that means?)
| wintermute wrote: |
| [...]This also gives us the option of supporting homebrew oriented stores like Electrobee, run by our own Natrium42, rather than filling the pockets of random chinese pirates. |
I know that and I agree, but I also believe some people discovered homebrew games and apps only after having already bought a random Chinese pirate cart, and it'd be a pity to disappoint a newcomer, I think.
#172679 - wintermute - Wed Feb 24, 2010 4:05 pm
| Quote: |
(I'm assuming that 'argv supporting card menu' means that I can get the NDS file location as a parameter of my main(), is this what that means?) |
Yes, hbmenu & akaio will pass the full path to the nds file as argv[0], this is how the nitrofs component of libfilesystem finds the file.
hbmenu is open source and will work on any card with a bit of tweaking so people who have already bought chinese pirate cards don't need to be disappointed. Obviously the simplest way to use hbmenu is to replace the menu on the card - with AK* & Ezflash that's as easy as dldi patching & copying the nds file. With the original R4 the nds file needs patched and encrypted but there are tools to do that in devkitPro svn.
With some cards the main issue seems to be that their dldi has been compiled with arm9 specific code which crashes when run on the arm7 in the hbmenu loader. DSTT & R4 appear to have this problem,not sure what other cards do. REing a dldi and recompiling is relatively straightforward though.
I have a DS-X in a box somewhere, I'll see if I can dig it out & have a look. It wasn't a horrendously bad card - would have been better with sd storage though. What would have been even better is if they had opened the firmware & fpga bits before vanishing into the night - the card is actually a rather neat piece of hardware and fully field reprogrammable.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172715 - sverx - Fri Feb 26, 2010 11:38 am
| wintermute wrote: |
| hbmenu is open source and will work on any card with a bit of tweaking so people who have already bought chinese pirate cards don't need to be disappointed. Obviously the simplest way to use hbmenu is to replace the menu on the card - with AK* & Ezflash that's as easy as dldi patching & copying the nds file. With the original R4 the nds file needs patched and encrypted but there are tools to do that in devkitPro svn. |
That's interesting. Can you point me to some 'how-to' on the Net? I couldn't find anything with Google :|
#172797 - wintermute - Wed Mar 03, 2010 10:10 pm
Sorry to take so long on this, been DSi hacking and coping with a teething baby.
I just uploaded prebuilt binaries for the current Homebrew Menu, including bootstrap code for original R4, ezflashV & acekard2(i)
http://sourceforge.net/projects/devkitpro/files/hbmenu/
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172806 - sverx - Thu Mar 04, 2010 11:55 am
| wintermute wrote: |
| I just uploaded prebuilt binaries for the current Homebrew Menu, including bootstrap code for original R4, ezflashV & acekard2(i) |
That's nice! I'll check them in the weekend :)
Thanks!
#172808 - the kid in the clock - Fri Mar 05, 2010 12:04 am
i've had the same problem, sverx. i ended up using libfat for saving games and efs for storing big additional files in the actual game. libfat is great - it's pervasive among homebrew. you can even use it with desmume if you turn on gba cart emulation (i use folder style - the desmume menus are a bit buggy) and patch your game with the mpcf.dldi. (which is just a matter of going: dlditool mpcf.dldi game.nds) i use that instead of the default dldi in my makefile.
the problem with efs (and nitrofs and libfilesystem - which i've not been able to get working) is that - since it uses libfat to find the nds file and people might rename that file - it goes hunting around for your nds file that has a specific 'id' inside. if you have a big card, that can mean a four/five second delay. you have to stick up a loading screen - i've noticed after the first time loading it gets quicker.
but if you do everything through libfat and then patch with mpcf.dldi - that's the quickest path. works on the emulator. works on the cards.
#172809 - wintermute - Fri Mar 05, 2010 12:54 am
Uh, did you bother to read the thread at all?
libfilesystem & The Homebrew Menu I just upped the binaries for don't have the problems you're talking about. It's been sat in devkitPro svn for rather a long time as a reference design for how menus *should* operate with homebrew.
EFS is something you really should stop using. In fact it's probably the main reason why most card menus have ignored the argv protocol and you're stuck with scanning the card.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172810 - the kid in the clock - Fri Mar 05, 2010 1:08 am
i guess i'm just reiterating things already said - and making a futile attempt to help - but nobody answered his question about how efs compares with libfat. that's all that i was answering.
so then help me out here. i understand how argv helps - it passes the filename to the binary. as dim and paltry as i am - i did comprehend that much of it. so they have to run hbmenu - then they run the game - is that the way it is?
first question - how does that help someone who just wants to do save files? it seems like you'd be great with libfat.
second question - why not just design the app to load using either argv-loading (or) the card scanning technique? then you just say "if you want things to load faster, get hbmenu." i don't know - maybe i am as stupid as you say - it's really depressing to find this out today. i also whacked off the mirror on my drivers side while backing out of my mom's garage.
#172812 - wintermute - Fri Mar 05, 2010 2:15 am
| the kid in the clock wrote: |
so then help me out here. i understand how argv helps - it passes the filename to the binary. as dim and paltry as i am - i did comprehend that much of it. so they have to run hbmenu - then they run the game - is that the way it is?
|
depending on the card you have, you can use hbmenu as a direct replacement for the menu provided by your card manufacturer.
| Quote: |
first question - how does that help someone who just wants to do save files? it seems like you'd be great with libfat.
|
Well, it's actually equally useful to libfat since an argv supporting loader sets the working directory to the folder where the launched nds file resides. This avoids all that nonsense with putting support files in the root of the card or some specific folder.
| Quote: |
second question - why not just design the app to load using either argv-loading (or) the card scanning technique? then you just say "if you want things to load faster, get hbmenu."
|
because
1. using the card scanning technique is slow and prone to error and
2. not using the card scanning technique gives the other card manufacturers a reason to provide an argv supporting loader.
| Quote: |
i don't know - maybe i am as stupid as you say - it's really depressing to find this out today. i also whacked off the mirror on my drivers side while backing out of my mom's garage. |
Pretty sure I didn't say you were stupid and, ouch, it's really annoying when stuff like that happens. Hope it's not too expensive.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172817 - sverx - Fri Mar 05, 2010 9:59 am
Thanks both for both your replies. Now I understand that 'argv stuff' and I'll also update my R4 card with hbmenu this weekend, so that I'll be able to try it, but I'm still one step away from the solution, so I'll ask your help once more.
* Say I would like to distribute my game as a single NDS file.
* Say I would like to save hi-scores (into the same NDS file, if possible)
* Say I still want the game to run on those carts that aren't passing my code the argv[0], even if they don't deserve it ;)
What would you suggest?
(I would say NitroFS, if I understood completely what's in this thread... but I still don't understand if I'll have the same compatibility problems that EFS has...)
Thanks! :)
#172821 - the kid in the clock - Fri Mar 05, 2010 4:03 pm
heretical as this sounds - i really think you'll need efs. nitrofs can't do writes. wudn't be too hard to hack write support into nitrofs. but you kind of just have to try it for yourself and see what works for you.
also, the only recent version of efs that's worked for me is this one posted by headspin: http://forum.gbadev.org/viewtopic.php?p=167652#167652
wintermute - okay i see. very good point about the working directory getting set automatically.
anyway i have a cyclods and it looks like argv is passed in more recent builds - this is cause for rejoice.
#172823 - wintermute - Fri Mar 05, 2010 9:25 pm
Right now we don't support writing to nitroFS and I'm really not at all sure that we should. Personally I'd tend towards saving in the same directory as the nds file, assisted by the magic of argv. There is certainly no guarantee that the nitro filesystem will always be writable. Something else to consider is that the user will lose their high scores when you update your game if you do it this way.
As for running on cards that don't support argv, just fail with an error message telling the user why - market forces will demand that all card menus support argv in a surprisingly short time period. Almost every card on the market now supports dldi and that happened within a few months of the move to libfat and removal of code to support every card we could. Short term pain *will* give us long term gain - can you imagine a card that doesn't have dldi autopatching now?
You can of course provide an hbmenu archive or a link to the devkitPro release.
We do plan on doing a lot more with the hbmenu in the near future
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172825 - headspin - Fri Mar 05, 2010 9:34 pm
I just don't think developers will want to limit their audience just so card manufacturers get their act together. Most people aim to run their apps on as many cards as they can. I know we did cartwheels to try and support as many as we could. Some cards had launchers that left very little RAM so we had to compress everything. Some cards didn't like EFS so we ended up releasing an EFS and FAT version (the latter writing to \Data\Game). I guess the best way would be to attempt to use argv first and if that fails write to \Data\Game.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#172829 - wintermute - Fri Mar 05, 2010 11:18 pm
You're not limiting your audience, stop looking at it that way. What you're actually doing by adding code to support poorly implemented launchers is allowing them to get away with launchers that really shouldn't work. Ultimately this is detrimental to the homebrew scene, both developers and users alike.
If devs had taken that attitude with dldi then we'd *still* be stuck with that insane detect the card code in the old gba_nds_fat.
Also: how on earth does a card manage to work with libfat but fail with EFS? Sounds like a major bug in EFS to me. That doesn't happen in the orginal code eris wrote which Noda ripped off.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172843 - sverx - Mon Mar 08, 2010 11:03 am
Ok, now I don't want to go OT in the thread I started myself ;) so where can we discuss about hbmenu? Another post in this forum? Another forum? Thanks :)
About the topic... well, maybe it's because I didn't experience that pre-dldi era (I started this journey in DS hb in July 2007) so actually I feel I should just try to release something that works on as many configuration as it is possibile. That means to me that I'll probably stick to FAT (since it seems there's no safe way to have an EFS/NitroFS r/w fs...) and support both argv[0] passing carts/firmwares (so those smart people using them will place their nds file wherever they want together with their external file) and also those which do not pass argv[0]... in this case the external files should be placed to a fixed location like /data/gamename. (actually what also headspin wrote)
Maybe one day I'll be able to write an homebrew that will make everybody upgrade their carts firmware just to be able to use my software... I'm sorry I believe it's still not that time.
#172845 - wintermute - Mon Mar 08, 2010 1:19 pm
Ever heard the phrase "If you're not part of the solution, you're part of the problem"?
Writing special case code in order to support as wide a variety of flashcards as possible is selfish and short sighted. All you're doing is hiding the problem and creating work for yourself and every other homebrew developer.
Make users aware that there's an alternative which is *easily* supported by the card manufacturers, market forces will do the rest. It worked with DLDI, it will work with this.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#172850 - sverx - Mon Mar 08, 2010 2:01 pm
I'll take into account what you say.
btw, where can we discuss hbmenu?
#172855 - ritz - Mon Mar 08, 2010 5:17 pm
#172867 - zeruda - Mon Mar 08, 2010 8:46 pm
| wintermute wrote: |
| Make users aware that there's an alternative which is *easily* supported by the card manufacturers, market forces will do the rest. It worked with DLDI, it will work with this. |
Does this require users of existing cards to purchase new hardware or can it be fixed by a firmware update?
#172869 - SteveH - Tue Mar 09, 2010 1:42 am
| zeruda wrote: |
| wintermute wrote: | | Make users aware that there's an alternative which is *easily* supported by the card manufacturers, market forces will do the rest. It worked with DLDI, it will work with this. |
Does this require users of existing cards to purchase new hardware or can it be fixed by a firmware update? |
It's a simple firmware update