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.

Shopkeer and healer

I managed to get the shopkeeper and healer UIs done tonight. Those should have been really easy, as nothing much has changed from before, BUT I just tonight remembered that they shared a lot of basic UI code with all the subscreen framework....and I changed the subscreen framework to use the bottom screen (forgetting that this stuff would still be on the top screen).

So basically, now, parts of the framework had to work on both screens. So I ended up refactoring things to work with both screens. It was a quick-and-dirty job, so not quite as elegant or clean as I'd really like, but it works. Really, I keep running into the question of whether to proliferate a top-or-bottom-screen parameter through half of my functions, or whether to make two differently named functions that do the same thing, only for each screen. The problem is that there are places where it seems to make sense to do it the first way, and other places where it makes sense the second way. And now I'm mixing and matching, which I'm not really happy about.

On another note, I found a nasty bug with my minimap where some rooms won't draw correctly, and the game will lock up if you try to pause view the minimap details for those rooms. Nice.

Darkness and cave backgrounds done

Last night I used my downtime to play video games instead of working on Anguna. But tonight was back to work. I tackled some of the easier items this time.

Darkness/lanterns was easy: like blending, I just had to update register names from my GBA version. I also was using macros to do all the bitwise operations to write the registers, so I changed them into first class functions, which makes me feel less dirty. It worked the first try.

The black space in the backgrounds in caves had decided to be a rather ugly teal color, so that was the other thing that needed fixed. Another easy one...I had two different functions for applying the correct palette to backgrounds: one for dungeons, one for overworlds and caves. And I had only updated the dungeon one. Just needed to make a tiny update to the overworld one, and it was all good.

If only all changes could be this simple. (Actually, it's late and I'm tired, so I haven't tested these on hardware, but after that last mess I got into trusting my emulators, I won't guarantee that this was simple until I know it works on the hardware).

#5 Fixed (or Hot Squash Burn)

I finally, after much anger, figured out the problem. The anger only resulted slightly from the actual problem. It (the anger) started when I got home, and suddenly my laptop (after locking up and being rebooted at least once) would no longer mount my card reader. So I took it to the other windows laptop, which would no longer read it either. So figured the card got corrupted, and tried to reformat it. But that failed also. Then my DS suddenly decided not to turn on anymore. About that time, Sara asked me to come blend the hot boiled squash she was cooking for baby food. Somehow I managed to not have the lid on right, and splattered boiling squash all over everything, including me. So let me just say Nathan wasn't the happiest man around.

Well, I finally dug out another card reader, which is working for now (I assume the other one just gave up the ghost?). Sara "fixed" my DS by waving her hands over it and saying "avada kedavra", so it works again (I still don't know what was up with that). And we even got the hot boiling squash off of everything, including me. And I only suffered mild first degree burns from the whole ordeal.

And now for the actual Anguna-related talk: In retrospect, I'm amazed at how much abuse in the form of wrong code you can throw at the GBA. The problem was a small section of code where I assume that each "map object" (the name I give to scenery sprites) has an array of two pointers to sprite info, and I write changes to both of them. Well, sometimes (like in the case of the small bushes) there's only 1 sprite, not two! Since C doesn't really protect you from your own stupidity, I was reading off the end of the array to some garbage pointer, and writing to a random location in memory. And the game boy was happy with that! (So were all the DS emulators I used). It makes me shudder to think that these few really nasty bugs made it into "production" code of the GBA Anguna, and I never noticed them because it somehow just worked.

Well, now, other than a small glitch in the background tile initialization for a room, (which is probably caused by another stupid instance of memory/pointer abuse), the actual on-hardware version works just like the emulated version. Which means I can go back to getting stuff done off the todo list. But first I'm going to bed.

#4 and the joy of two screens

Well, I found issue #4: Initialization problems again. This time with bullets, instead of enemies. Adding smarter initialization and better checking for null pointers fixed that. Unfortunately, I found out that there's an issue #5 causing half the problems that I had attributed to issue #4. So there's more to be done.

But I will say, I LOVE having two screens. When doing this type of debugging on the gba, it was ridiculously difficult, as I couldn't print debug messages to the screen a lot of the time, as the failure was somewhere in initialization routines that were clearing the screen or changing a lot of the video settings. But now with two screens, I can write all my debug statements to the 2nd screen while the first one is hard at work, or vice versa. It's wonderful. Being able to do that, I think I'll be able to track down bug #5 quickly.

But I want to say what I HATE: my laptop. It locks up randomly every so often. Mostly when I pick it up and move it (explain that?) I came to my other computer to type this post when it locked up a few minutes ago. I posted, sat back down with the laptop, got ready to work again, and it locked up again right away. So I'm back adding this paragraph while it reboots again. Grr-bah.

Update on bugs

So I spent a couple hours trying to diagnose what was going on. Turns out that the build/test cycle wasn't QUITE as bad as I feared (but still relatively painful). I still have to pull the card out of the ds, pull the micro SD card out of the DS card, put the micro SD card in the usb card reader, put the usb card reader into the PC, wait for it to mount, copy the file to the card, unmount the device, pull the usb reader back out, pull the micro SD out of the reader, put the micro SD into the DS card, put the card into the DS, power on the DS, navigate through 2 levels of menus, and start the game. But at least I don't have to move the file to my windows machine first, like I thought I may have to.

Well, after some diagnosis, it turns out that almost all of the bugs have to do with the enemies and my sprite management code. Specifically a few things:

1. The DMA and caching issue that I had before. I really need to just write or steal a good fast memory copy written in assembly for the DS (using the ARM's ldmia/stmia instructions), so I can ditch the DMA. There's examples out there for the GBA, which should be really similar, but my assembly is poor enough that it might take me more time than I'd like just to make the minor tweaks to get them working on the DS.

2. Bad initial values. I had a few spots where I was reading an uninitialized value. Somehow on the emulators, and on the same code on the GBA, this worked fine. But blew up on the DS. So I just needed to go through and initialize them.

3. Dereferencing a null pointer. We all know that that's a big no-no. But it looks like somehow it worked before on the GBA. I don't get it. I was dereferencing a null pointer to a sprite object, and copying that to sprite OAM. That seems like a BAD idea. But it's fixed now.

4. Unfortunately, I haven't figured out what #4 is yet. Something in the sprite management for enemies and bullets is making the game freeze up. Not the 30 second freezing up that I saw before, but locking up entirely freezing up. Luckily it's completely reproducible, but I still haven't managed to track it down. I really thought that fixing #2 and #3 would solving the freezing up, but no...they fixed other issues, but not this one. So now I just need to hunt for mysterious #4.

I also managed to solve the sprite fading/blending issues I had that made me decide to retest on hardware in the first place. Turns out the version of the No$gba emulator I'm using doesn't handle blending properly (or at least doesn't when run under wine)....I actually got the blending code right on the first try (which is only not impressive because I lifted it almost directly from the GBA version, with the only exception being the #define'd name of the registers that control it), but I spent forever fighting with the blending because No$gba would render OTHER blends (background with background, etc) correctly, but not sprites with backgrounds.

Testing on hardware

Alas, I knew I shouldn't have waited as long as I did since I last tested on the real DS hardware. I guess I had more faith in No$Gba than I should have. Today I ran Anguna on hardware, which I haven't done in a good while, and had all sorts of bugs that didn't show up in either of the emulators I use.

The worst was that when you move from room to room, it occasionally takes a long time to load the next room. Like 30 seconds long time. Something is SERIOUSLY wrong in that case. It only happens some of the time. But in the world of programming, "some of the time" is worse than "all of the time" because it's a whole lot harder to find the problem and know if you've fixed it.

I've also got issues with rogue sprites appearing. Stuff appearing that never should have appeared, and not disappearing when it was supposed to.

The annoying things about fixing this:
1. There's no debugging tools available. My debugging tools were pretty worthless anyway, since the only emulator I have that has any debug facilities at all is horribly inaccurate. But this'll be worse.
2. The change/build/test cycle takes a whole lot longer, since you have to add the steps of insert the memory card in the PC, copy the file, transfer the memory card to the DS, boot the DS and start the right game, and THEN test.
3. I do all my development on linux. My card writers don't work on linux. Blah. (Edit: turns out one of them works on my laptop, but wouldn't work on my desktop. But I do the majority of the work on the laptop, so it won't be quite as bad as I thought)

Even if they end up being pretty trivial and easy bugs, this will take quite a bit of time.

Subscreen on the subscreen

Here and there over the past few days, I've gotten all the subscreen stuff moved to the DS's bottom screen (often confusingly called the "subscreen"). So the map, enemy database, and inventory screens can show down there while you play. You can pause the game and toggle through them like you used to, or just let them sit there and automatically update themselves. I also added the enemy life indicator that my coworker Jong begged for :)

It was all a lot of housekeeping-type work, very little was interesting enough to share the details of technically. The registers that control the bottom screen are almost exactly like the ones on the top screen (at least for this 2d tile-based stuff...I have no idea about the other modes), so I just had to make new functions to operate on the bottom screen, and make some of my old functions be smart enough to know which screen to operate on.

The only tricky parts were that I now needed to update my subscreens during the main loop instead of only when the game is paused and a key is pressed. Knowing how much of the subscreens to update led to some tighter coupling between different major parts of my code (one of these days I want to eventually do a big rant/essay about when is the right time to engineer fancy solutions to reduce coupling, and when instead those fancy solutions have more overhead than they are worth), but nothing too horrible.

The other annoying part is that I'm now saving room at the top of the bottom screen for status messages that used to appear at the bottom of the main screen. Stuff like "Got meat, health restored" and that sort of nonsense. Which means I'm laying out my subscreens slightly differently. Which for most of the cases, is no big deal, since everything is positioned relatively. The annoying part, though, is the text in the enemy database. Because the enemy portraits vary so much in size and shape, I manually positioned the flavor text for each one to make it look decent. But now in many cases, it looks wrong, or bleeds over the portrait (in the picture shown here, you can see a blank space overlapping the portrait). I either need to cheat, and just use another separate layer (which might make the text hard to see if the colors are similar), or do it right, and manually reposition all the text. Which will be annoying. I'll probably end up doing both, but we'll see ;-)

If I get really inspired, I'll use the touch-sensitive feature of the bottom screen to allow you to toggle between subscreens or inventory items by touching it. But I can't imagine people actually using this very often, so that might fall off the feature list near the end when I start getting impatient.

Well, to finish this up, my friend Rob asked the other day how much left there was to do. My remaining todo list, as best I can estimate:

-dark rooms/lantern
-faded sprites (when you or an enemy gets hit)
-fix enemy db entries
-title screen menu needs a little work
-splash screens/etc
-game over stuff
-sound
-borders on caves are messed up
-save menu
-actually saving game
-shop/healer screens

Sound and the game saving are the only intimidating ones, as those differ pretty significantly from the GBA. The rest are basically busy-work.