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....

Better memory copy/set

Once again, Cearn is my hero. The fast assembly routines he sent for doing memory copies and sets are wonderful -- they just worked, and are nice and fast. I don't have to deal with the oddities that come with DMA, and it's a whole lot faster than the simple memory copies implemented in C. This means that transitions in general are a lot smoother -- between splash screens, between game rooms, etc. Good stuff.

Getting stuff done

I finally got inspired to buckle down and get more done tonight. Partially because Chris (The amazing guy who did the graphics for Anguna) asked me today how it was going, which always reminds me to get to work. It sounds like he's interested in possibly doing some new fancier splash/cut scenes and enemy artwork for the DS port, which would be cool.

Sound effects are now completely working. The last little thing I had to do was deal with the fact that my effects needed to be played at different frequencies...on the GBA, my audio player handled that for me somehow, but here I needed to tell it what frequency to play at.

I unfortunately spent an hour or so fighting with MikMod about how it loads song data into memory. I really need to dig into the source of that library and see what it is doing, because it appears that I can overwrite my song data by loading background tiles into vram. That certainly shouldn't be right, but through trial and error, I've determined that if I load tiles at a certain point in my code, the song is corrupted and won't play. If I don't load the tiles, the song is fine. I've got a workaround in place now, but it doesn't make me happy. And I left my microSD writer at work, so I can't test my workaround on the DS until tomorrow.

The other bummer is that MikMod refuses to play the song that I previously used as intro music. (Hurtless by Magic Fred) I'm not sure how much time to spend fiddling with the song file to see if I can get it to play, or ditch the song and just use the 2 other pieces, or if I should try to find a different song to use for opening music. I'll have to think about that.

I also fixed my minimap bug, which turned out to be not one, but two different bugs. One was that I wasn't loading enough graphical data for the overworld minimap. The other was that somewhere along the line of refactoring things, I had a function that infinitely recursively called itself (when it was supposed to be calling something else). Silly me.

I finished up the evening by fiddling with the opening splash screens....putting my "Bite the chili" logo on the top screen while Chris's SpriteAttack logo is on the bottom screen, and getting everything cleaned up to work happily on the DS.

The other fun news is that Cearn sent me some assembly routines for doing fast fill/copies. I mentioned before that I needed to switch to assembly, as DMA was driving me crazy, so this should do the trick. I'll see if I can get those working and integrated next....

Sound (mostly) working

Well, I ditched the bin2o rules that came with the devkitPro toolchain, and used a separate bin2o program, and now I can properly access my binary audio data. I'm sure that I was doing something slightly wrong (data alignment? wrong section? wrong arm/thumb compilation?) as it works for other people, and for the examples that I've looked at.

But what I have now works, and that's good enough for me. Sound is almost finished.

Sound and multiple processors

I've been quiet on here...partially because I haven't had a lot of time for Anguna the past week, and partially because I've started on sound, which meant I had to do a bit of reading before proceeding.

Turns out, there's all sorts of funky stuff you learn when you get into sound on the DS. For example, the DS has two processors: an ARM7 and and ARM9. The GBA had an ARM7, so the ARM7 is used when playing GBA games on the DS. And the ARM9 is the "main" processor used by the DS for DS games. But the fun part is that you can use both processors from your DS code. But unlike fancy desktop computer programming, it's not as simple as forking or creating a new thread from your code. You actually have to write it as two separate programs. One runs on the ARM9, and one runs on the ARM7. The DS has facilities for them to communicate with each other, so your two processes can talk to each other. The other oddness is that certain hardware features can or can't be accessed from the different processors. The full range of audio hardware can (as far as I can tell, which may be wrong) only be accessed from the ARM7. The video stuff can only be accessed from the ARM9. Weird.

So far, I've been writing everything on the ARM9, because you can do most "normal" simple stuff from it. But now that I'm diving into the audio stuff, I've had to use the ARM7 as well.

The good news is that I've found an audio library (mikmod for ds) that will do a lot of the audio work for me. So although I'm running on both processors now, I don't have to touch and learn a lot of the nitty-gritty of audio programming and inter-processor communication.

So far, my music (which come from .xm files, which are a type of mod file (which is a file format for sequencing music out of audio samples)) is working quite well. Sound effects are a slightly different story. The code for playing them seems to be fine, but I've been running into problems when I compile and link them in: somehow the start and ending points for them got messed up, so when you try to play one effect, you might get another, or you might hear all 10 of them played back to back. So I'll need to figure out what's going on there. Hopefully the wonderful community at the gbadev.org forums can help out.