#66679 - MaHe - Thu Jan 12, 2006 9:11 pm
I'll maintain a list:
- a data folder for essential files (game & app data, like savegames, skins, plug-ins...)
- a unified cfg file (I hate the fact about having a separate file for ScummVM, WiFi Transfer, BreakOut Mania, LumiDS and so on...), or they should atleast be INSIDE the data folder
- optional: an exit button is always nice to see (if app would detect GBAmp, it should run _BOOT_MP.nds, if it'd detect SC, it'd return to it's menu, in case of MultiNDS loader it'd go back to loader...)
I hope it's understandable & clear.
Add your own ideas (I will use these 'rules' in my own games).
#66688 - m2pt5 - Thu Jan 12, 2006 11:31 pm
The ability to run on both CF and SD based devices, not just one or the other.
_________________
Don't sign your posts, it's dumb.
#66692 - Sebbo - Thu Jan 12, 2006 11:41 pm
an exit button to go back to the loader would be a great idea, perhaps someone could write a function that does this so that ppl can just copy and paste it into their code
_________________
Here's some ideas I have for when I know enough to act on them, or for others to have a look at when they're bored: www.wayne.sebbens.com/ds_ideas.htm
#66714 - tuLL - Fri Jan 13, 2006 3:40 am
The ability to return to the loader was suggested by me here, and not widely accepted:D
http://forum.gbadev.org/viewtopic.php?t=7414
#66722 - Lynx - Fri Jan 13, 2006 5:34 am
First, CF vs SD isn't part of the developers deal, it's just because Chishm released a CF library.. So, untill someone creates an SD library, I don't think you will see SD specific support any time soon.
Exit code is already available. Someone should "lobby" for it to be added to libnds. Then it might be "accepted".
I agree that a /data/ type standard should be created, but I think people that have already released /data type games/apps should make this decision, as they have the experiance to know what would work best for them. Problem is, it's also a personal choice.. so may never happen. But, if people "see" it enough, they may follow along when deving their own /data type project.
#66740 - tepples - Fri Jan 13, 2006 6:53 am
| m2pt5 wrote: |
| The ability to run on both CF and SD based devices, not just one or the other. |
If you're willing to buy each developer the other devices...
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#66756 - tssf - Fri Jan 13, 2006 8:44 am
I like games having their own data folders, not just one central one. Wouldn't you have to "install" it if they all use one central directory? I think that's kinda dumb, personally.
I pretty much run my programs like this:
ROOT\Programs\<program name>
Should the game/app use a data directory, I see no reason why it can't just look for its data files in its own data sub-dir.
I can see the problem if people run the NDS file in their root folder...there's a simple solution for that: Don't.
_________________
Mathew Valente [TSSF]
------
Chrono Resurrection Musician
#66760 - chishm - Fri Jan 13, 2006 9:55 am
| tepples wrote: |
| m2pt5 wrote: | | The ability to run on both CF and SD based devices, not just one or the other. |
If you're willing to buy each developer the other devices... |
Or just get me a SuperCard SD... :P
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#66766 - Sebbo - Fri Jan 13, 2006 12:12 pm
well, i think i'll start lobbying for the "back to loader" code to become standard in libnds and all homebrew games then...reckon a poll is the best way, see how much of the community is behind the idea?
_________________
Here's some ideas I have for when I know enough to act on them, or for others to have a look at when they're bored: www.wayne.sebbens.com/ds_ideas.htm
#66773 - pepsiman - Fri Jan 13, 2006 1:08 pm
| Lynx wrote: |
Exit code is already available. Someone should "lobby" for it to be added to libnds. Then it might be "accepted".
|
libnds/include/nds/reload.h:
// reload.h -- Provides an ability to return to the main menu when used
// with darkains loader or compatible system.
There's already one return to menu system in libnds, don't know if it works with chishm's stuff.
#66774 - m2pt5 - Fri Jan 13, 2006 1:29 pm
| chishm wrote: |
| Or just get me a SuperCard SD... :P |
If I could spare the money, I totally would, for the good of homebrew. Mostly because I'm hearing everyone talking about "chishm's FAT drivers".
Or you could talk to cory1492. He's come up with a good set of, well, something for the SCSD, and he's hacked it into the last several versions of Moonshell. (I'm not a developer. I don't know how any of this actually works, just how to make already-written and compiled code work on my DS. :D )
_________________
Don't sign your posts, it's dumb.
#66792 - bafio - Fri Jan 13, 2006 4:03 pm
| pepsiman wrote: |
| Lynx wrote: | Exit code is already available. Someone should "lobby" for it to be added to libnds. Then it might be "accepted".
|
libnds/include/nds/reload.h:
// reload.h -- Provides an ability to return to the main menu when used
// with darkains loader or compatible system.
There's already one return to menu system in libnds, don't know if it works with chishm's stuff. |
I have tried it, it doesn't work to me on GBAMP. You can reload "boot_mp.nds" on gbamp, the lib method is for other loades I guess... (It's method "b" on the wifi transfer when you load a file)
Bafio
#66796 - Dudu.exe - Fri Jan 13, 2006 4:32 pm
Supercard SD code is out why not include it wright now?? are you waiting fos m3 SD code?
_________________
http://flickr.com/photos/stuffbox
#66800 - pepsiman - Fri Jan 13, 2006 5:07 pm
| Dudu.exe wrote: |
| Supercard SD code is out why not include it right now?? are you waiting fos m3 SD code? |
1) The Supercard SD "code" is asm, not C, so it's not as portable.
2) After rewriting in C it will need testing before release.
3) Hardware is needed to do testing.
#66816 - FireSlash - Fri Jan 13, 2006 6:28 pm
| tssf wrote: |
I like games having their own data folders, not just one central one. Wouldn't you have to "install" it if they all use one central directory? I think that's kinda dumb, personally.
I pretty much run my programs like this:
ROOT\Programs\<program name>
Should the game/app use a data directory, I see no reason why it can't just look for its data files in its own data sub-dir.
I can see the problem if people run the NDS file in their root folder...there's a simple solution for that: Don't. |
I think you misunderstand.
The idea here is to centralize all the data from different programs into one folder.
For instance, LumiDS uses
(root)/data/LumiDS/....
The idea is for other programs to follow this pattern, so, say, ScummVM's config file would be stored in...
(root)/data/ScummVM/...
etc.
This reduces the "mess" on the CF root of having tons of program data folders and config files.
The reason we need to look at a standardization like this is because unlike PC systems, the current directory is reset to '/' when a homebrew app loads. The data can be located anywhere, its just a matter of not knowing where './' is. It could be manually searched, but depending on the CF card size, that may not always be a good idea. Imagine iterating through a 1gb flash card full of source files and small documents. Yikes.
_________________
FireSlash.net
#66833 - brian33x51 - Fri Jan 13, 2006 7:50 pm
| FireSlash wrote: |
| tssf wrote: | I like games having their own data folders, not just one central one. Wouldn't you have to "install" it if they all use one central directory? I think that's kinda dumb, personally.
I pretty much run my programs like this:
ROOT\Programs\<program name>
Should the game/app use a data directory, I see no reason why it can't just look for its data files in its own data sub-dir.
I can see the problem if people run the NDS file in their root folder...there's a simple solution for that: Don't. |
I think you misunderstand.
The idea here is to centralize all the data from different programs into one folder.
For instance, LumiDS uses
(root)/data/LumiDS/....
The idea is for other programs to follow this pattern, so, say, ScummVM's config file would be stored in...
(root)/data/ScummVM/...
etc.
This reduces the "mess" on the CF root of having tons of program data folders and config files.
The reason we need to look at a standardization like this is because unlike PC systems, the current directory is reset to '/' when a homebrew app loads. The data can be located anywhere, its just a matter of not knowing where './' is. It could be manually searched, but depending on the CF card size, that may not always be a good idea. Imagine iterating through a 1gb flash card full of source files and small documents. Yikes. |
I think some effort should be made to fix this problem of the directory context being reset. Locality of data storage is good for sanity and won't result in someone accidentally blowing out their data folders for all the applications they have.
I guess it's probably most important to at least agree to a standard. I tend to value my sanity when it comes to coding.
#66839 - FireSlash - Fri Jan 13, 2006 8:20 pm
| brian33x51 wrote: |
| I think some effort should be made to fix this problem of the directory context being reset. |
It may be possible for a loader to pass the directory on to the .nds file.
However.
- Every .nds loader is going to have to support this. If only a few do, its a waste of time.
- You can't force homebrew devs to use it.
- It opens up a new area of things tha can go wrong.
- If someone launches the file without a loader, it won't work. Even worse, there most likely won't be a good way to determine if the data is there or not, as the ds's firmware might have had data in that memory address.
- Would break compatability with WMB
- While you could fix the WMB/noloader issues by specifying a "default" directory, this would be confusing, and in the end wouldn't solve the problem
_________________
FireSlash.net
#66850 - octopusfluff - Fri Jan 13, 2006 9:31 pm
| brian33x51 wrote: |
I think some effort should be made to fix this problem of the directory context being reset. Locality of data storage is good for sanity and won't result in someone accidentally blowing out their data folders for all the applications they have.
|
I don't think that's the best way to look at it. It's not so much that the directory context is being 'reset'.. It's that there is no shared context at all. We aren't dealing with applications running on an operating system, like with Windows, Linux, PalmOS, or whatever.
We're dealing with executables with complete and total control over the device, who have no luxury to assume any state of the machine prior to their taking control. On this platform, for sanity purposes it's necessary to assume nothing is how you want it, and put it that way.
What you want is only reasonable in an operating system / application context, such as the DS Linux port.
#66904 - tepples - Sat Jan 14, 2006 6:59 am
| FireSlash wrote: |
| Every .nds loader is going to have to support this. If only a few do, its a waste of time. |
If the .nds loader backend is moved into libnds's implementation of exec() then all the .nds loaders have to do is call exec().
| Quote: |
| You can't force homebrew devs to use it. |
If it's part of exec() then it should be really easy to get homebrew developers to use it, if only to minimize the amount of tech-support that the developer has to do.
| Quote: |
| If someone launches the file without a loader, it won't work. Even worse, there most likely won't be a good way to determine if the data is there or not, as the ds's firmware might have had data in that memory address. |
PogoShell for GBA solves this by putting relevant data in the last kilobyte of EWRAM and then putting a 4-byte signature immediately before this (that is, at 0x0203FBFC).
| Quote: |
| Would break compatability with WMB |
Programs that use assets are already incompatible with FlashMe+WMB until TCP is fixed, as only then will it become possible to fopen("http://192.168.0.1/data/titlescreen.gbfs", "r") in order to load the assets from the computer that sent the program. Programs that don't use a loader will just have to run in /, as they're likely to be the only program on the card (as in the case of _boot_mp.nds).
| octopusfluff wrote: |
| It's that there is no shared context at all. We aren't dealing with applications running on an operating system, like with Windows, Linux, PalmOS, or whatever [...] What you want is only reasonable in an operating system / application context, such as the DS Linux port. |
Well, there are operating systems, and then there are operating systems. Some of us just want an operating system kernel that does as much as MS-DOS, which pretty much includes running programs and accessing a file system.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#67108 - SeanMon - Sun Jan 15, 2006 4:09 pm
Support for both SRAM saving and CF card saving. *cough*HereticDS*cough*
_________________
null