Skip to main content


Showing posts from 2008

Version 1.02

I made a few bug fixes, and released version 1.02.

Changes include:
The save filename was changed from anguna.sav (which conflicts with the R4's autosave feature) to anguna.datRearranged where graphics data was stored, to see if it makes a difference in the nasty unreproducible bug where occasionally the main character sprite becomes a giant solid-colored square.Fixed a few sections of the overworld map where edges between rooms didn't transition nicely, allowing the player to get stuck.Thanks to everyone that submitted bugs about these things!

If you update versions, your old save file will still work, but your character's location will be reset to the first overworld room, outside the prison dungeon.

Version 1.01

Sverx reported a couple bugs, so I've posted an updated version (AngunaDS version 1.01).

There was an effect in the main theme xm file that LibXM7 didn't support, so I changed that. Also, there'd been a bug for awhile where occasionally the main character could get covered by a big solid-colored square after you continued from dying. It had been reported before, but I haven't been able to find out how to reproduce it. I finally got enough details from Sverx that, although I still can't reproduce it, I have a pretty good theory about what was causing it, and, if that's the case, I can prevented it from occuring again. Let's see if that holds true...if anyone happens to see that behavior in this 1.01 release, please let me know!

AngunaDS v 1.0

Ok, I'm proud to announce AngunaDS version 1.01. (edit: because I updated to a 1.01 version, I'm changing this link for now to point to the updated version)

Thanks go out to:

Chris Hildenbrand (Daydream)

Jessie Tracer (Electric Keet),
Fred Scalliet (Magic Fred /TFL-TDV)

Audio Engine:
LibXM7 by Sverx (version 0.59 beta)

DS Hardware for testing donated by:
Tim Dudek

Also thanks to:

Refmap project
Additional art

Jasper Vijn (Cearn)
Usenti, Tonc,
Code samples, and general awesomeness

And all you testers:
12th&Saturn,Chris Lomaka, Mukunda Johnson, Sverx, Tim Dudek
Jong Lee, Dennis Tseng, Irashtar,
Eric Chiz, Max Neweklowsky, Stevan Baird, Eric Wells,
Alphanoob, another world, Jeremy Gunkel, John Seabaugh, Spiridow

Unfortunately, there were a few features/fixes that I ended up cutting at the end:
You can't use the touchscreen to navigate subscreen menusSleep mode when closing the lid only partially turns t…

Everything seems to be working

Ok, back to the content that I originally started to post before I realized that my audio wasn't working on hardware. Which is: I think I'm pretty much done! (again...didn't I say that before?)

Turns out (for those of you interested in the details) that something somewhere was sending some dummy messages over the IPC FIFO (the mechanism by which the arm9 and arm7 processor communicate). Because the only messages that I send over it were instructions to play songs, I assumed any messages received were instructions to play songs, and it was trying to play a nonexistent song. Better sanity checking on the commands coming through IPC fixed that.

So now I've made a test build. I'll sanity check it over the next day or two, then send it out to anyone interested in helping test. Then call this thing done!

Still working on audio

Well, I finally gave up (for now, at least) waiting on eKid's audio library, and instead used a new library (LIBXM7) that sverx from the gbadev forums recently released. And it works perfectly -- well, on the emulator. I thought it worked right on hardware, but turns out I was using the wrong build. So there's more work to do -- either waiting on eKid, or getting this LIBXM7 to work right on hardware....

Title screen graphics

I promised a screenshot of the amazing new title screen that Chris made. Of course, the screenshot doesn't capture the alpha-blend fade or anything, but it still looks cool:

Hurry up and Wait

I was on such a roll for awhile, but now everything has slowed down, unfortunately. I added the power-saving features that I mentioned last time, and debugged a whole bunch of minor issues that testers had found for me.

Chris (the artist) sent me an amazing new title screen, which I just finished adding, completely with a cool alpha-blend fade-in of the title. (Which I'd show a picture of, except I forgot to check in one of the source files into subversion, so I can't build it from this computer right now).

Now, I'm just left with replacing the audio engine. One of the people testing for me (ekid) told me he's finishing up a new audio engine that's supposed to be pretty good. Based on one of his test builds, it actually properly plays all 3 of my songs from Anguna (where my current solution completely fails on one of them, and butchers a few notes from one of the others). Hopefully he'll finish that soon, and I can pull it in easily.

So I'm still advanci…

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

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 warningsfixing the enemy database text entriescleaning up game over screens and some transitional screensfurther 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…

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 som…

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 i…

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…

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 mixin…

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…

#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 …

#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…

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 assem…

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 worthl…

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 in…

Typo and my bool

Notice a problem with this?
if (abs(bullet.xSpeed > 0)) {

It took me a good 10 minutes to find that problem. Alas, I must have added that typo when I was moving some of my utility functions (min, max, abs) to a more logical home. Ah well.

I also got into trouble last night with bools. Fore some reason, most of the controls for the game worked, but L and R would not. Turns out it has to do with switching from my own typedef'd bool, which was just typedef'd from an integer, to using libnds's bool, which is enum'd as true and false (for those of you used to fancy-schmancy modern languages, C doesn't have a built-in bool, (well, sortof. C99 does, but we won't go there)). I was trying to return a bool value of 512, which using my old method, would evaluate as true. Using libnds's method, it's probably undefined behavior (I'm not sure what the C spec says about doing this), but definitely didn't work. But the fact that it worked for a bunch of…

On a roll

Wow, I'm getting a lot done this week. Last night, the kids went to bed quickly and easily, and Sara decided to watch the Olympics, giving me a little more than an hour to get stuff done!

I managed to:
Fix the priorities, so sprites appear behind the foreground tiles. This was fairly simple -- I just had the priority numbers wrong. Which makes me wonder how it ever worked in the GBA version, but I didn't get around to comparing the codebases to find out why.Add black foreground borders around small dungeon rooms. Before that, it looked weird when you walked off a could see your character out in the limbo beyond the room as you exited. So now the black space around the outside of rooms is in the foreground. It was a pretty easy fix, as I took a random room tile, and just gave it an all-black palette, to avoid having to add a new tile.Fix a few other minor scrolling glitchesGet the overworld tiles to load correctly. Like the priorities, I was doing this dead w…

Correction and signed/unsigned ints

Well, turns out a few people do read this blog after all! Cearn left a comment on my last post correcting my incorrect understanding of bit-shifts, which if you are interested, you can read for full detail, but the gist is that bit shifting WILL preserve the sign bit if it's declared as a signed integer and not an unsigned integer. So I stand corrected. Thanks Cearn!

Which means, looking back through my code, that the problem resulted less from my willy-nilly bit-shifting, and more from using an unsigned integer in one particular function. (which at the time was reasonable, because my engine never used negative screen positions until now).

I managed to scrape together 30 or 40 minutes this weekend to finish changing all of my screen setup and scrolling functions to be happy with signed numbers, and finished added some special cases to deal with rooms that are smaller than the screen size. And now all the backgrounds seem to be drawing and scrolling correctly! The first major …

More screen size and premature optimization

Donald Knuth was right. Optimizations I had done for the gba are killing me. And it all has to do with screen size.

See, my engine wasn't designed to properly handle rooms that were smaller than the screen. The camera's position in the room is stored by a number that I assumed was always positive, because, being equal to or smaller than the room itself, I never had to go negative, or outside the bounds of the room. But now with the bigger screen, the camera is often outside of the bounds of the room. So I need to handle all these special cases where the rooms are smaller than the screen. Two things need to happen: first, it needs to just work right. Second, smaller rooms should be centered horizontally on the screen, (unlike the picture in my last post, which looks goofy being shoved up to the left), and bottom-aligned with the screen, so there is less overlap between the HUD and the game. So I've got that to do, which I've started on, but is messy.

A big chun…

Screen size

Well, I'm getting closer! As you can see on the right, things look almost normal!

The biggest problem I ran into so far was the difference in size between the DS screen and the GBA screen. I still need to make better use of the full screen real estate (at least to center small rooms like this one), but the bigger problem was in how the graphics engine deals with the screen size.

See, most scrolling tile games on nintendo's handheld use a small tiled background which wraps around as you move. This background is just big enough to have one row and one column of tiles off the screen at a time. So as the screen scrolls, you redraw the off-screen row or off-screen column (or both), and then scroll it onto the screen. A little tricky, but no problem, really.

The problem comes in that the DS screen width is the same size as the default small wrapping background that I had been using. So I suddenly don't have an offscreen column to draw on. The answer, of course, is to make th…

Sprites, DMA, and caching

In the 2nd picture in my last post, you might have noticed the big brown square in the top-right. Strangely enough, that's a sprite that was appearing and disappearing at weird times. What you don't see in a static picture is how weird clones of the main character and enemy sprites would start appearing at semi-random intervals. Yuck.

Well, as usual, it's DS weirdness that I wasn't counting on that caused it. And this is where I launch into technical ramblings that make the eyes of the general public glaze over and start dreaming of Krispy Kremes.

See, the GBA and the DS both have this cool feature called DMA, which basically means they have a piece of hardware that copies memory from one place to another place, quickly (as opposed to the normal methods of loading a chunk of memory into the cpu, then writing it to another place in memory). Well, what I have been doing is setting up all my sprite information for a frame in regular memory, then, between screen update…

Title screen and vram banks

Well, I've got the title screen working:

But it wasn't without a fair amount of pain. The first step was pretty easy: when I copy the tile data from regular memory to video memory (vram), I needed to make sure I was copying enough -- since I'm using different memory copy routines than I did on the gba.

I did that, ran it in my emulator, and it looked great. Till I ran it on the actual DS, and it was just a blank screen. Bleh. I loaded it up in the No$GBA emulator, which is the most accurate emulator out there, (but you have to pay to get access to most normal debugging features, and unfortunately, the author has disappeared, meaning it's impossible to purchase, so I'm out of luck getting a useful debug version!), and it black screened also. Bother.

So I spent a few hours fiddling around with some DS demos and copying code back and forth, trying to figure out where I went wrong. Turns out it's with DS's funky vram banks.

See, on the gba, your vram is vra…

Getting Started

After enough pestering from random folk, and donations of hardware from the wonderful people at Electrobee, I've decided to go ahead and port my Gameboy Advance game Anguna to the Nintendo DS. It should be a fairly straightforward port, as the DS's 2d hardware is remarkably similar to the GBA, but the fact that my wife and I have 5 month old twins really slows things down. So, since the development will be slightly slow, I figured it'd be interesting to keep a record of where I'm at, and what progress I am (or am not) making on it.

For starters, I decided my first tasks should be:
Get the GBA code to build on Linux. I did the GBA version working entirely in Windows, but I've recently switched over to mostly using Linux, so the build framework needed to work in Linux.Clean up the messy/ugly bits. There were plenty of those, and plenty of places where I built in dependencies on gameboy hardware at too high a level. This, I thought, would be the perfect time to fix…