Skip to main content

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.

Comments

Jake T said…
I'm sure I understood no more than 30% of this post. whew.

Popular posts from this blog

Retrospex 32 Review

RetrospexInternational recently sent me a couple units of their new handheld device, the Retrospex 32, a new dedicated GameboyAdvance emulator handheld.  To make the unit playable out of the box, they pre-loaded a handful of homebrew games, including Anguna, which is why they were kind enough to send me 2 of the units to play with.  I was pretty excited to get my hands on the device and try it (I loved my old GBA micro with a good flash cart!), and see Anguna running on it. So here's my thoughts after playing with it.



Their website lists the Retrospex 32 for £59.99, which is around $100 USD. It seems like it's marketed toward people into retro-gaming (which makes sense for a dedicated GBA emulator device). At that price, with that target market, and such a limited set of functionality (why not make it a multi-machine emulator, and emulate all the old consoles?), it would hopefully do a really good job of it.

The short version of my review: it doesn't. It has one job (emula…

Making the game fun

The real trick for Spacey McRacey (as I'm calling it now) is going to be making it fun.  And that's what I'm rather unsure about at this point.

I have a game design that basically works. The technical issues are mostly sorted out, I just need to get a few more implemented before I can seriously play test it.

But fun? It's hard to know if it's actually going to be any fun to play.  With a 4-player party-style game, it's seems like it might be hard to hit that fine line where everyone is close and competing, where everything feels exciting and tense, as opposed to tedious and boring.  And despite envisioning my game as fun, it might just be boring to play.

Some of that comes down to tweaking it. Tweaking the speeds, difficulties, etc, will make a difference. (If it's too easy to shoot people from behind, then it will be nearly impossible to hold a lead for very long, which could ruin it and make it no fun. If it's too hard to kill the guy in front, it wil…

Killer Queen

So at PRGE, I played an arcade game that just left me amazed.  Killer Queen.

It's a 10-player game. You have 2 cabinets linked together, and 5 players huddled on each one. Each one is a team of 5 people, working together to play a simple one-screen 2d platformer.  But what made it work was the high quality game design.

First, the game is relatively simple, yet there is a lot going on at once.  One player plays the queen, the most important and powerful character on the team. The others start as workers, but can become warriors who can fly around and attack in a very joust-like flappy contest of height.  The real trick is that there are three completely different ways to win: either collect a bunch of berries and bring them back to your base, or ride a REALLY SLOW snail across the screen (while other people try to kill you, and you hope your team protects you), or kill the enemy queen 3 times.  There's some other things going on as well (using berries to upgrade, capturing upgr…