#147982 - tepples - Mon Dec 31, 2007 1:47 pm
| In this post, Bloodypriest wrote: |
You should get into the habit of not linking .bin files directly into your project. It is wasting good ram with a permanent copy of data whose true place lies elsewhere.
Instead, you can malloc the memory when needed, read the files from disk using libfat |
I disagree for several reasons: - What if the player has ejected the microSD adapter to give to another player in a local multiplayer setup?
- Even in single-player, where you can reasonably expect the adapter to stay put for the entire session, you're taking up more room for addresses because you have to specify a whole filename instead of just a base address.
- Unless you replace malloc() and free() with a version that supports multiple heaps and can completely deallocate an entire heap at once, using malloc() and free() several times each frame will likely cause external fragmentation of the heap.
- Disk is slow. Especially on the Games n' Music, you can't be sure that a big read will finish before the end of the frame.
- Especially in the case of programs written by beginners, a lot of homebrew programs are simple, and they don't come close to filling RAM. Let the beginners learn how to get things working before making them hyper-efficient.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#147984 - Quirky - Mon Dec 31, 2007 1:55 pm
Another reason for preferring monolithic .nds files: Ease of installation for the end user.
Providing a single .nds file instead a nds file and a folder of data is preferable from a games player's pov. It is far easier to copy the new version of mygame.nds to the card than correctly copy mygame.nds and update the /data/mygame folder correctly.
#147991 - Peter - Mon Dec 31, 2007 2:41 pm
If you create a game whose assets in total are bigger than (about) 3MB, you don't come around to load from card.
_________________
Kind Regards,
Peter
#147997 - Bloodypriest - Mon Dec 31, 2007 4:19 pm
@tepples & quirky
Yes I see your points. However, I'll try to address as much of them as possible.
| Quote: |
| What if the player has ejected the microSD adapter to give to another player in a local multiplayer setup? |
I never thought about that kind of multiplayer setup. For me, possible multiplayer setups are the same as with the official cart: one cart - multiple machines through WMB, multiple carts - multiple machines.
Has a homebrew WMB loader been written yet? (maybe extracting it from a FlashMe dump?)
| Quote: |
| Even in single-player, where you can reasonably expect the adapter to stay put for the entire session, you're taking up more room for addresses because you have to specify a whole filename instead of just a base address. |
| Quote: |
| Disk is slow. Especially on the Games n' Music, you can't be sure that a big read will finish before the end of the frame. |
These can't be helped I guess.
| Quote: |
| Unless you replace malloc() and free() with a version that supports multiple heaps and can completely deallocate an entire heap at once, using malloc() and free() several times each frame will likely cause external fragmentation of the heap. |
Actually, since I come from the PC world, I found writing a custom memory allocator easier than understanding all the intricacies of sprites on the DS (in the end, I resorted to GBATek). That is, because I won't start coding before I understand a subject fully.
| Quote: |
| Especially in the case of programs written by beginners, a lot of homebrew programs are simple, and they don't come close to filling RAM. Let the beginners learn how to get things working before making them hyper-efficient. |
Again, it's my background speaking I guess. I have the habit of fixing bugs and optimizing as I go and also thinking about future expandability of the code base.
| Quote: |
| Another reason for preferring monolithic .nds files: Ease of installation for the end user. |
Actually, I use EFS which is a nice layer over libfat that allows me to keep my data inside the NitroFS portion of the .nds. But I didn't want to promote EFS over the more generic libfat in my previous post.
Well, I hope this explains where I came from with my previous post. Sorry for the long post.
#148000 - simonjhall - Mon Dec 31, 2007 4:48 pm
There are definate advantages to compiling data into a program, especially for someone learning to program - you know the data's going to be there and you haven't got to mess around with loading it.
However as soon as the thing being worked on stops being a toy project and something more serious, I think you should use files and memory allocation properly. By planning earlier how multiple levels and objects will be handled the easier it will be to deal with when you run out of memory. But also it just makes the code cleaner in general by doing it this way, in particular when it comes to enumerating this built-in data.
<cuts out huge and poorly-explained example>
Also, maybe I'm just crap, but whever I try to include data into a program I always mess it up and spend longer trying to get it to work than I would have done if I'd done it properly :-)
Finally, when you learn how to program in C from a book or getting taught it at school you're never taught how to use (or make) built-in data. Instead you're taught how to use files to do what you want. I guess this has rubbed off onto me... Has anyone had any experience of the opposite?
(Plus I got taught Java at uni at this was the first programming for most people and we neve encountered built-in data like this! Can it be done?)
To counter all this, I was once reading on some support forum and one (proper) game team wanted to map a whole disk into memory so they could access their data without using file commands. Sounds like they started with the "well we're always going to be able to fit our data into memory" thing, but then their artists went a bit nuts :-D
_________________
Big thanks to everyone who donated for Quake2
#148003 - Bloodypriest - Mon Dec 31, 2007 5:05 pm
Simonj, your QuakeDS port was exactly the example I was thinking about when I meant lots of data.
#148005 - simonjhall - Mon Dec 31, 2007 5:13 pm
Actually, the other guy who did the first port of the game (that's DSQuake) built all of his data into the executable and stuck it in the GBA ROM space. Although he got definate advantages from doing this (which I then had to spend ages coding around, since I used libfat) his was limited to the demo pak files only since the main game is too large to link in and the game only played on slot-2 cards.
_________________
Big thanks to everyone who donated for Quake2
#148007 - melw - Mon Dec 31, 2007 5:26 pm
There's also one good reason for including binary data into projects: It'll work emulators just like that. But yeah, different projects have different needs. Personally I try to avoid using external files unless the assets grow too big to be held in the memory all the time. I for one tend to like single .nds files and no messy directories if just possible. :)
Simon, one possibility is to code own functions for reading data and add option to read either from disk or from the memory. For smaller games and applications 4Mb is actually quite a lot (e.g. Dicewars DS .nds is ~1Mb, consuming something like 1.5Mb of main ram) - that doesn't necessarily mean they're "toy projects".
#148008 - simonjhall - Mon Dec 31, 2007 5:36 pm
Yeah those are some pretty good points. Being able to run in emulators without any effort is a real plus, as is the no clutter in directories thing. Easier for you to distribute the files, easier to people to set up and no stupid DLDI support emails!
Ok, on a bit of a tangent then - would people rather do save games through files(as in fopen/fwrite etc) or save games through SRAM?
_________________
Big thanks to everyone who donated for Quake2
#148013 - GoopyMonkey - Mon Dec 31, 2007 6:31 pm
| simonjhall wrote: |
| Ok, on a bit of a tangent then - would people rather do save games through files(as in fopen/fwrite etc) or save games through SRAM? |
Wouldn't disk access be the best choice for saving games? That would help those usng devices without support for SRAM, like me because I use a GBAMP.
_________________
My favourite DS apps:
GBAMP Multiboot
Colors!
jEnesis
#148021 - Bloodypriest - Mon Dec 31, 2007 8:23 pm
I agree. I thought at first about using the DS-X virtual EEPROM but I don't think it would work on the majority of flashcards.
#148026 - tepples - Tue Jan 01, 2008 12:09 am
| Bloodypriest wrote: |
| Quote: | | What if the player has ejected the microSD adapter to give to another player in a local multiplayer setup? |
I never thought about that kind of multiplayer setup. For me, possible multiplayer setups are the same as with the official cart: one cart - multiple machines through WMB |
I was envisioning the model of loading the game on machines 2-4 and ejecting the card while the machine is still on, then starting the game on machine 1. This creates a running environment similar to that of DS Download Play, and until we crack Nintendo's private RSA key or until someone comes up with a sleek carrying case for a paperclip + eyeglass screwdriver to install FlashMe Stealth, we have to fake WMB in this way. Besides, even under the official devkit, the slaves can't read the NitroFS unless libnitro has some way for them to mount the card from the master as a network share.
| Bloodypriest wrote: |
| Quote: | | Let the beginners learn how to get things working before making them hyper-efficient. |
Again, it's my background speaking I guess. I have the habit of fixing bugs and optimizing as I go and also thinking about future expandability of the code base. |
Another faction prefers to do the simplest thing that could possibly work, because it's likely that you aren't gonna need it. Wasn't it Donald Knuth who called optimization "the root of all evil" when done too early?
| Bloodypriest wrote: |
| Well, I hope this explains where I came from with my previous post. |
I understood, for the most part.
| simonjhall wrote: |
| I was once reading on some support forum and one (proper) game team wanted to map a whole disk into memory so they could access their data without using file commands. |
That's called mmap(). Given adequate support in the underlying operating system, it's a valid way to load assets.
| GoopyMonkey wrote: |
| Wouldn't disk access be the best choice for saving games? |
This may be true on the DS, where SLOT-1 microSD adapters and SLOT-2 SD adapters are the norm. But on the Game Boy Advance, the expected execution environment is 32 MiB of ROM and 64 KiB of SRAM. One would need to use FCSR in order to add a writable file system to this, and DLDIWiki doesn't yet appear to explain FCSR well.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148028 - Bloodypriest - Tue Jan 01, 2008 1:05 am
| Quote: |
| I was envisioning the model of loading the game on machines 2-4 and ejecting the card while the machine is still on, then starting the game on machine 1. This creates a running environment similar to that of DS Download Play, and until we crack Nintendo's private RSA key or until someone comes up with a sleek carrying case for a paperclip + eyeglass screwdriver to install FlashMe Stealth, we have to fake WMB in this way. Besides, even under the official devkit, the slaves can't read the NitroFS unless libnitro has some way for them to mount the card from the master as a network share. |
Wouldn't it be easier to just unpack FlashMe Stealth (no GBA autorun) into a .nds and run that from a flashcart?
#148034 - tepples - Tue Jan 01, 2008 3:21 am
| Bloodypriest wrote: |
| Quote: | | until someone comes up with a sleek carrying case for a paperclip + eyeglass screwdriver to install FlashMe Stealth |
Wouldn't it be easier to just unpack FlashMe Stealth (no GBA autorun) into a .nds and run that from a flashcart? |
I was talking about SL1. DS Download Play won't load homebrew unless FlashMe is installed, and FlashMe won't install unless SL1 is shorted. If you're talking about running the modified firmware itself as a .nds, you'd still have to eject the card while each DS is turned on.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148035 - Bloodypriest - Tue Jan 01, 2008 3:33 am
Yes that's what I was talking about.
However it would be more advantageous for people to have it on their own flashcarts. Card switching kinda neglect the benefit of having the unpacked firmware as an .nds, unless it's for Nintendo style minigames that cannot be sent any other way than through WMB.
#148042 - dantheman - Tue Jan 01, 2008 7:42 am
| tepples wrote: |
| One would need to use FCSR in order to add a writable file system to this, and DLDIWiki doesn't yet appear to explain FCSR well. |
Isn't FCSR still read-only? It would work for Pogoshell-esque file compilations (I've tested Chishm's cart_save), but you'd still need to use the SRAM to save data.
#148054 - tepples - Tue Jan 01, 2008 3:18 pm
| Bloodypriest wrote: |
| However it would be more advantageous for people to have it on their own flashcarts. |
Flashcarts, plural? I was imagining the case of a half-dozen people bringing their DS systems to a family party where only one player owns a flashcart. Or is it expected for someone to carry three spare Games n' Music cards with him?
| dantheman wrote: |
| Isn't FCSR still read-only? It would work for Pogoshell-esque file compilations (I've tested Chishm's cart_save), but you'd still need to use the SRAM to save data. |
As I understand it, the "SR" stands for some sort of SRAM overlay feature.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148057 - Bloodypriest - Tue Jan 01, 2008 4:53 pm
Well, they make great gift since they're not expensive, especially if you put some great homebrew on them first.
#148099 - Nintendo Maniac 64 - Wed Jan 02, 2008 7:15 am
One thing I must say about the multiplayer...
I did the "eject flashcard and put into second DS" method several times for TetattDS. We may not have games with local DS-to-DS Wifi support, but it still works with using traditional online play.
#148933 - myersn024 - Sat Jan 12, 2008 6:10 am
I, being the one that started the thread that spawned this thread, totally agree that the most practical option (in most cases) is to load files as needed. I learned C/C++ while attending college, and building in our data was never even presented as an option. I've been working on the program that I was writing at the time I started the other tread, and thus far all my tiles are still statically linked into the executable. I've only got a handful of tiles and all are being used, so it actually becomes more efficient to build them into the data instead of having to load them....that is until I decide to make my graphics look better.
#148942 - melw - Sat Jan 12, 2008 10:52 am
| myersn024 wrote: |
| I've only got a handful of tiles and all are being used, so it actually becomes more efficient to build them into the data instead of having to load them....that is until I decide to make my graphics look better. |
Rule of thumb: If your graphics are awesome, include them as separate files for ripping made easy! ;)