Saturday, September 6, 2008

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.

1 comment:

Jake T said...

I'm sure I understood no more than 30% of this post. whew.

Optimization and C

Starting this next game in C, I've known there will be places where C isn't fast enough, and I'd have to drop to assembly to ...