Still here

I've been quiet for the past couple weeks. I'm still here, I promise, and still working on Anguna.

I found a few volunteers, who have been incredible in finding lots of little (and some not so little) bugs for me to fix. I've gotten through most of them, but there's still a couple more to go before I call the thing "done." They also brought it to my attention that to play nicely, I should support going to low power mode when the DS lid is closed. I guess that's a pretty standard thing to do (I don't know, about the only thing I use my DS for is developing Anguna, and playing occasional homebrew games for 5 minutes at a time (you can probably guess what else I'm doing during those 5 minutes)), but it doesn't automatically happen...you have to program it in: detect the lid closing, turn off the video, put the ARM9 processor in lower power mode, do the same for the ARM7, set up interrupts so the processors come back on when the lid opens, etc. Bleh.

Also, during testing, I've found that mikmod just isn't reliable enough....I've been getting all sorts of glitches in sound. So I need to replace that with something else. So the hunt is on to find a better XM player.

Ok, that's all. Just wanted to keep the world (both of you) posted, and aware that I'm still working on this!

Main development finished?

Wow, I've gotten here faster than I thought.

Today I managed to knock out a bunch of little stuff:

• cleaning up warnings
• fixing the enemy database text entries
• cleaning up game over screens and some transitional screens
• further testing/cleanup of saving and loading

Which really means that I'm pretty much done!

Although I must tell the story of when I was at this point on the GBA version of Anguna, I told my wife Sara that I was "done with the development" after 3 years of working on it. But when I spent the next month testing, fixing random bugs, and then fixing bugs that other people in internet land found, she started laughing at my concept of "done." So, with that being said, stuff that's left:

1. Update the credits. I'm not using Kusma's awesome Pimpmobile audio player anymore (since there's no DS version), but switched to LibMikMod (which, despite the fact that I'm incredibly happy that it exists, I'm not as impressed with). I also want to mention Electrobee and Tim Dudek in there, for donating hardware stuff to make this thing happen. And I ended up pulling out 1 one my 3 songs that I used, as it didn't work with LibMikMod, so I guess I need to un-credit Magic Fred who composed it. (Sorry Fred! (For those of you who might think I'm blowing off Fred's work, he didn't compose the song for Anguna, but made it freely available for people like me to use)) So if anyone wants to compose a cool intro song for Anguna, feel free!

1.5 Decide if I want to try to actively search for a replacement intro song, or a composer for it. Probably not, but I'll think about it.

2. Updating documentation/readme files, etc. LibMikMod is LGPL, which is a pain, as I have to include all their licensing documentation, make object files available, etc.

3. Chris (the guy who did the graphics) has said that he might want to create some cool new eye-candy splash screen/cut scene type stuff. If he does, I'll need to figure out how and where to add that in.

4. Test. And test. And bug fix. And test some more. And get other people to test for me. At some point soon I'm going to try to recruit some people to playtest for me before I publicly release the thing, so if anyone is interested, please let me know.

5. Test some more.

6. Test.

7. Release AngunaDS, and bask in the glory of being done!

Saving game data

So I recently ventured into the world of saving progress on the DS. And, like sound, it opened up a whole can of worms. (To be fair, I knew this can of worms was coming, but I kept putting it off).

So, the background, for all you people that don't do DS development:

In the olden days, cartridge-based games used battery-backed ram to save data. Which was still the case in certain GBA games. But in some GBA games, and as far as I know, all commercial DS games, save data is stored using EEPROM. The homebrew DS cards, though, from everything I've read, don't properly support EEPROM (at least accessing it via homebrew methods), but instead, we have a file system to work with, for reading and writing data. But it's not quite as simple as that.

All the homebrew cards are slightly different, but most of them adapt between a micro SD card and the DS. BUT the underlying way to read/write the filesystem on the SD card differs between the different homebrew cards. Enter some smart guy called Chishm and his awesome libfat/DLDI. This guy wrote a file access library (libfat) and a fancy system of patching compiled games with drivers for the different cards. So you write your game using libfat, and if somebody wants to play it on card XYZ, they run the patcher with the XYZ driver.

There's all sorts of other crazy and cool ways of dealing with it all, like people have written other utilities that stuff a whole file system into data appended in your executable file, so the whole DS game and save data and whatnot can be shoved into one file.

OK, enough of the 10-second crash course on libfat and DLDI. So I read up on this stuff, got libfat set up, and it all seems to be working. I toyed with using EFS, which does an appended file system like I mentioned above, but eventually decided against it, as I want it to be easy for people to update the main game file (like when I release bug fixes) without losing their save data. The other annoyance is that using basic libfat stuff, it crashes my emulator. It works fine on the actual hardware, so it's not a huge deal, and the emulators always have the ability to save state, so they don't really need a save file, but I need to go in and make sure it at least doesn't crash.

Other than that, and a couple minor bugs (I'm not rebuilding the initial level screen correctly after loading a saved game), saving and loading is working (at least on the M3 that I'm testing on...Electrobee also gave me an Edge card, so I need to make sure the saving/loading works correctly on it as well).

Once I get this done, the only things left are small cosmetic changes: getting the end-of-game splash screens and credits looking all nice, making sure all the transitions between splash screens, game over screens, menus, etc are all good, finding better intro music, fixing the flavor text on enemy portraits, and testing testing testing. Oh, and I've noticed I have a bunch of warnings in my code about improper pointer conversions. I need to go through and fix all those...I'm one of those people that doesn't want to see a single warning in my code when I compile....