Nathan's Development Blog

More blank GBA Carts

2011-05-26T20:04:00.002-05:00

Hey, just a quick heads-up, I finally found another source for blank GBA carts, which means that for those of you that I had to turn down at some point, I can start selling them again. Drop me a line if you want one.

And yes, I'm still alive, but haven't done much development recently. I got bored with porting Anguna to iphone, and my apple developer license expired, so that's on hiatus. I have some other ideas I'm exploring, I'll tell more if/when they ever develop.

More Progress

2010-07-22T16:49:00.000-05:00

I've been quiet, but I've been SLOWLY making progress. The downtime before and after phase 2 of the Starcraft 2 beta really helped me get a little done.

Recent accomplishments include:

I got the first overworld area and the rocky overworld area completely working (the outdoor parts)
I've successfully broken up resource loading into the separate areas, so it waits to load graphics resources for the various dungeons until they are needed.
HUD stuff including enemy portraits is in place.
The subscreen is mostly finished. I've finished the inventory screen, finished the map screen (and thanks to the nice resolution of the iDevices, the subscreen map is just a tiny image of the actual screenshots for each area, which looks slick, in my opinion), added the enemy database, and still need to do the "options" screen.
The base code for saving and loading is in place, but I haven't yet put any UI in for it. I'm leaning towards auto-saving each time you change rooms, so if you have to quickly turn the game off, you don't lose any progress.

This is really all to easy at this point -- not interesting and challenging enough to really suck me in, which is I guess why it's going slow (plus this being the 3rd platform for the game, it's not as new to me anymore) There haven't really been any technical hurdles in awhile. Saving and loading, which I thought might be somewhat tricky, were as simple as writing to a file. The scrolling for the enemy database took a little bit of thought to implement, but nothing noteworthy.

So, I guess, just enjoy some new screenshots:

Subscreen

2010-06-16T22:33:00.000-05:00

Well, now that the Starcraft 2 beta is closed (at least for a few weeks) it's time to get some more done. I haven't done much since the last post. Mostly it's been reworking UI bits. I'm not a huge fan of the lack of buttons on the iphone/touch, but I guess everyone has to deal with that. I've been working on getting some on-screen UI for health/control buttons/etc.

Tonight I finally also got the main inventory subscreen somewhat laid out, mostly similar to the gba version, but slightly different, since the font resolution is much higher. I'll also need to add options to toggle to the map or enemy database, but that can come later.

The other thing I need to work on is the control scheme. It will use a simple on-screen control pad, but in playing other iphone games to get ideas, I've noticed that some of them with control pads work well, and some of them are completely miserable to use. A lot of it will be fine-tuning the hot spots, dimensions of the control areas, etc. My friend Rob also made a suggestion that I think will really help -- if you hit the attack button, and there's nothing in front of your character, but there is something that could be hit if you had turned before attacking, it will auto-turn your character. The part of me that likes crazy difficult games wants to fight against the idea, but I do think it would really help make up for the fact that it's REALLY hard to accurately control a character with a touch-screen control pad. So good suggestion, Rob. That's something I'll need to add in, maybe once I get the subscreens and menus working.

Progress

2010-05-11T22:46:00.000-05:00

Well, progress is going a little slower than anticipated, mainly due to the fact that I finally got into the Starcraft 2 beta, so my spare time is being split between Anguna and Starcraft. But that aside, things are going fairly well.

The framerate issue from before is trivial to fix, so that's been addressed.

Performance was more interesting. If I render the entire background every frame like I planned on doing, things USUALLY worked fine, but would occasionally get sluggish if the device was doing stuff in the background (checking mail, getting push notifications, doing whatever else that crazy thing does). So I decided as a workaround to prerender each background to an offscreen surface, then just blit that to the main display every frame. Which worked fine, except that there was some sort of odd behavior in the graphics system where it wouldn't actually destroy/release memory from offscreen surfaces when I was done with them (or at least do so in a timely fashion), so after about 10 room transitions, I'd run out of memory and crash. Of course, since it was only on the device, it took quite a while to figure out exactly what was happening. Turns out Apple has a nifty tool called the Iphone Configuration Utility which, believe it or not, actually runs on windows! It lets you view the device console logs in real time, which was amazingly helpful in tracking down the issue. Fixing it was then just a matter of reusing the same offscreen surface for every room, drawing over the last one, instead of destroying and recreating them with each room transition.

I'm also running into long load times -- I'm not sure how I managed to see only 5 seconds before, but it's often taking 7-10 seconds to load the resources for the game, and that is with them being marginally broken up. That's a bit higher than I'd like. I think that I might be able to reduce the perceived load time by doing part of it while showing a splash screen, doing some more at the game start, etc, but I'd still like to get that a lot lower.

Overall, though, things are running well. The first dungeon is completely working (although a lot of the UI to make it really play right is missing, such as life bar, subscreen, button for activating secondary item, etc), and the first little chunk of the overworld is mostly functional. (the graphics for the bridge to the desert area are messed up right now).

I really need to start messing with the UI now. Which should be a lot easier than it was on the GBA or DS, but still a good amount of work, as it's going to be completely different than the GBA UI, meaning a lot of it will have to be completely rewritten from scratch. So that's my next task....(well, after I play some more Starcraft 2).....

Running on Hardware

2010-05-03T13:11:00.000-05:00

I just got into the developer program, so I can finally run things on hardware!

Unfortunately, I had the same experience as last time I did the switch from purely testing on simulators/emulators to testing on hardware. Things were working great in the simulator, I loaded it on hardware, and it just crashed and died. It took it about 5 seconds sitting at the loading screen, then crashed back to the menu (or whatever it's called on the iphone/touch).

A couple hours of debugging turned up the same issue as last time -- I was initializing some things incorrectly, which led to some bad pointers, which somehow, out of pure luck (would that be good luck or bad luck? I'm not sure) worked just fine in a simulator, but caused seg faults/null pointers on the real thing.

Luckily, it wasn't as hard to track down as it COULD have been, so as of today, it's running on hardware!

A couple thoughts/surprises:
1. My framerate is too high. The framework I'm using locked things to 30fps on the simulator, so I assumed it would do the same on the hardware. Nope. So I need to manage that myself.

2. It'll also be nice to really see how the performance works. In the simulator I was running into performance issues blitting the tiles for large backgrounds. I found a workaround, but it'll be nice to do some experiments to see what I can get away with and what I can't.

2. I can actually now observe how much time it spends loading. My biggest gripe with a lot of the iphone games is the long load times -- for small portable gaming, you should be able to get into the action very quickly. I'm at about 5 seconds right now. That doesn't include music or sound effects, but does include loading ALL the graphics up front. I can probably lower it a bit by breaking up the art assets and loading them as I need them. We'll see.

If I had a camera handy, I'd take some video or at least a photo of it on hardware, cause pictures are fun. But I don't, so you'll just have to use your imagination.

Back at it

2010-04-23T16:22:00.002-05:00

Well, I'm back at it. Without an artist, that means one of 3 things:

1. Make a video game with ugly graphics (either a plain ugly game, or some game where I can cheat and use the theme in some way to my advantage to get away with some sort of ugly)

2. Have my next programming project be a non-game (that doesn't require an artist)

3. Port Anguna to something else!

So, here I go on step 3.

I recently found a cool product called the Airplay SDK, which is a whole toolkit for doing handheld game development in C++. Using it, depending on licensing and whatnot, you can build games for all sorts of things: iPhone, Android, Windows Mobile, etc. The important part to notice was that I could make iphone games without going out and buying a Mac! (I had an old mac mini at one point, but it was too pathetic to do development on...and the iphone develepor tools required an intel mac, which this wasn't).

So I bought an iPod touch and started porting. Unfortunately, a week or two into my efforts, Apple changed their terms of service, which, as far as I can tell, make it really unclear whether Airplay apps will be approved for the app store. That was a bit discouraging, but I'm hoping they will be, so I'm moving forward with the effort anyway.

So, after a few evenings and lunches of work, here's what I've got (this is a screenshot in Airplay's simulator):

At Chris (the artist)'s advice, we decided to scale all the images double, which means it will look a bit more pixelated than most games, but it exactly matches the full screen resolution of the iphone, and if we push it as a "retro" feel, may go over ok.

The porting so far is coming along fairly easily -- it's amazing how much easier it is to get graphics on the screen with a more powerful device and thus more powerful sdk. No more messing with vram and OAM attributes. The biggest hurdles I ran into so far are based on the differences between C and C++.

C has designated initializers (which I used all over the place, thanks to a tip from Kashiwa), but C++ doesn't...so I had to go back and manually change a lot of code from using designated initializers to just initializing an array in order.

I also ran into a difference in how referencing external constant structs works. In C, I did a lot of:

const struct EnemyType enemy_bat_def = {....};

and in a different file:

extern const struct EnemyType enemy_bat_def;

and then referring to it in that file.

Well, for some reason something is different in C++, and this doesn't work. I'm guessing it has to do with the differences in C++ about how const is handled, or more likely, how structs are actually just classes without functions, but my knowledge of the gritty details of C++ is embarassingly lacking. So I just changed how I did it. (now in the 2nd file, I'm referring to a pointer to the struct instead of the struct itself).

Other than that, it's been incredibly straightforward -- the bulk of the codebase just worked. I'm still having to muck with how palettes are handled a little bit (my animation definitions indicated which base image to use for an animation, so a set of palette-swapped enemies just all used the same animation definitions. I can still do this, but the SDK handles palettes a bit differently, so it's a few changes).

I haven't yet applied for my iphone developer's license, so I've been running everything in a simulator so far, so the next step is going to be to get that and actually run this on the hardware, and see what breaks. (or what the performance is like).

Then, it will be time to work on the UI -- the UI, menus, and controls will need a complete overhaul, so that will likely be the biggest portion of the work involved in this port.

So there you have it. Let's see how quickly I can get this thing done.

Lack of graphics....

2009-11-02T15:27:00.000-06:00

Well, after that exciting start that I blogged about, I've stalled rather quickly. That's a bit discouraging. I haven't done much work on the "next game" for a few weeks. Why?

Two reasons, really. First, I've just been busy. I haven't had as much spare time in the evenings.

But the bigger reason is that I haven't gotten confirmation from an artist for the game. Chris (that did Anguna's art) had expressed an interest, which was enough to get me excited and started, but he's been pretty busy and had some other stuff going on in life, so I'm not sure he'll be able to contribute. A couple of other leads have come up, but nothing solid.

Without graphics, there's not really a game, so I'm waiting and dragging my feet on the development side of things for now. I guess I could use some free-to-use resources from the web or something to get started, but it's just not very motivating. So that's where I'm at now. Maybe I'll hear from Chris or someone soon, and get geared up again later.

Review: Strider for nes

2009-10-14T15:33:00.000-05:00

Well, after I got excited and started work, I haven't actually done much recently. I've been reworking the level loading code from Anguna, but there's still a good bit to do. I'd really like to get some sample graphics into the engine so I can visualize things better, but that will still be awhile before any graphics are ready.

So until then, I'm still playing old nes games. The most recent was Strider. Strider is an interesting game: it has a great concept, cool story and mechanics, a fun almost detective-style "find the next file of information to see where you can go next" thing. Unfortunately, the game is riddled with problems. The play control is glitchy and awful -- if you jump near a wall, often your jump immediately ends and you fall to the ground. The hit detection is completely wacky. In most cases, it doesn't really pay off to fight carefully, because you never know when the game will think you've made contact with the enemy, or if it's made contact with you and damaged you. So you basically run around swinging your little sword thing (the game calls it a "cipher") and hoping you don't die. This REALLY puts a damper on the fun factor.....it's neat exploring new areas and figuring out where to go next, but it's no fun when you actually get there.

Overall, I enjoyed the game somewhat, but it was also moderately painful, fighting bosses that I had no idea if I was hitting, not being able to make jumps that should be easily jumped, etc. The game was also a little bit too short for my liking, but that's ok.

So, things I've learned:

The whole "multiple completely separate areas with a hub screen to determine where you go" concept can be pretty fun. (Assuming the game doesn't hold your hand TOO much, which Strider balances quite well)
The actual action gameplay has to be fun, or the game isn't fun. Any single killer mistake (too high difficulty (see super pitfall), bad play control, bad hit detection)...any of these can ruin the game.
It's good to limit how many times a player has to run through a particular area over and over again. In Strider, most of the areas are visited once or twice, but you keep returning to Kazakh. And each time, you have to play through a pretty boring couple of hallways to get where you are going. I like the general idea of returning to areas once you've got something new, but I got really sick of Kazakh.

More on the asset pipeline

2009-09-11T23:13:00.000-05:00

So I'm still trying to figure out what my asset pipeline is going to be like. What makes it particularly interesting is this: the GBA doesn't support files (there are hacks out there to simulate it, but I'd prefer not to use them). Everything gets packed as data into the single game rom, and run. The DS, on the other hand (at least for homebrew) has a usable filesystem. Now you can ignore the filesystem and pack things into the rom like I did for the DS release of Anguna, but working with files can sometimes be a lot nicer -- it sure makes the edit/build/test cycle a lot easier, as you don't have to go through a separate compile step.

The tricky part is thinking about how I might implement both of these. The core of my existing engine assumes everything exists as structs in C, and references to other data is just via pointers. (Which is easy when the compiler does all the work for you). But if I use files, I'll basically need to write a file parser, which will then populate those structs, and create all the pointers between the new structs based on text symbols in the files. Definitely doable, but a bit more work. Is it worth it to go to files for the DS but not for GBA?

The other side of the coin is the argument that, realistically, when editing assets, I'll already have to jump through some hoops to save/export it properly using whatever tool I use. Why not just make sure my tool also recompiles everything during that step, and let the C compiler do all the work of parsing, populating structs, and creating the pointers?

Review: Super Pitfall

2009-09-11T10:40:00.001-05:00

Super Pitfall for the nes is TERRIBLE. Completely awful. Interestingly enough, it's given me quite a bit of thought about game design for my next project.

I've spent the past 22 years trying really hard to like this game. I mean, this game had the potential to be awesome. It was a huge world that you could explore freely. Dungeons and spikes and non-linearity and ladders and treasure. What could go wrong? Well, everything. No matter how much I tried, I always came to the same conclusion: this game was no fun.

So, to be productive, I'll try to think about why it wasn't fun, and what could be done about it.

First, the challenge level was way off. There are numerous frustrating cheap kills near the beginning of the game. And there's a ridiculously long time you have to wait between dying and when you get to play again...it's something like 10 seconds of waiting. Considering your first life may only last about 4 or 5 seconds, it's really annoying to have to wait 10 more before you can play.

Also very frustrating is the fact that, although it's a big open world to explore, you find very little compelling or interesting things. You wander around collecting gold bars that do nothing. Scattered around are special items (playing card suits?) that are invisible until you jump in a certain correct spot. But even when you grab them, there's very little sense of accomplishment. Why did I grab that? What's it for? And do I really have to jump at every single inch of the huge world to see if there's an item hidden nearby? Overall, I get this feeling of a big huge empty world, filled with nothing but ladders and traps. I've heard that if you are patient enough to map out the world, it all comes together and the game gets interesting. But I was never patient enough.

So, theoretically, this game could have been fun if:

- There were fewer cheap kills, and the challenge curve had been a little more appropriate

- Your goals were a little more obvious, so you felt you were making progress or discovering something interesting

- There was a minimap (I love minimaps) to help you keep track of where you've been and where you are.

So the things I should learn from Super Pitfall:

- A huge world to explore is just frustrating if there's no obvious reward for exploring. This is the trouble I ran into with the overworld in Anguna.

- A huge world is confusing if there's nothing to help organize your brain. Forcing players to hand-draw a map is a bad plan -- provide a minimap. This one is relatively obvious these days, as almost all adventure games do this. (and it was forgivable back then to not have one)

- Have someone else playtest a little to make sure the difficulty curve isn't insane.

- Make sure that secrets aren't hidden in obtuse and stupid ways that just require tons of tedium in trying every single square/block.

Overhauling the Anguna engine

2009-09-10T22:12:00.001-05:00

The nice thing about doing another GBA/DS game is that I already have a working game engine. There's plenty that I want to change, and a lot that I'd like to clean up (see the previous postmordem posts), but it's nice to have working code that takes care of a lot of the grunt work.

So the past few weeks I've been giving some needed love to the code that drove Anguna. The first goal was to merge the gba and ds codebases into a single source tree, and just have different make files for the different platforms. Not for Anguna's sake, but to reuse for the next game. Of course, some of the stuff (hud, menus, all the code for the DS's second screen) will have to be a bit different for the two platforms, but the majority will be the same.

The next task has been pulling out stuff bit by bit and reorganizing it, reducing coupling when needed, and generally making things less "icky". Unfortunately, this also means breaking things, so I'm back to that crazy point where I cheer every time I get a sprite to appear correctly on the screen. It's a bit tedious (especially because I've done this all before), but it's nice to know that as I get this all cleaned up, I'll have a ton of the work done towards my next game (even though I'm still not sure about all the details of said game). So tonight I managed to get a "black triangle" onto the screen. It's ugly, but it made me happy:

This, my friends, is my black triangle: That nasty green background is an ugly "level" that properly got loaded by my level loader and screen drawing code. (Despite the fact that I didn't bother to find good looking tiles to test with). The green toady guy from Anguna is a stand-in to make sure my character/sprite code still works. Which it does. The fun part is that I hadn't even tested the DS version, but just now, while typing this, I compiled the DS build, and ran it, and it showed the exact same thing!

On a completely different note, I've been playing through a lot of the old-school 2d side-scrolling adventure games (mostly for NES, but some others), trying to get ideas for what works well and what doesn't, for what I like and don't like. So I might have a few posts here basically just reviewing some of the old games, which will help me organize my thoughts.

Next Project

2009-08-31T13:38:00.000-05:00

Ok, on to what my next project might be. I'm not content unless I've got a project I'm working on, so there's not really an option of "no project". While working on Anguna, I had lots of ideas of things that I might want to work on next.

I've considered doing some sort of 3d OpenGL-based game on the PC to learn what I'm doing with 3d game programming. I've messed around with 3d before, but nothing more than little demos. Other things I've considered include some sort of NES homebrew, dreamcast homebrew, Atari 2600 homebrew, making an iphone game, doing a flash game, and finishing a digital scrapbooking tool for my wife. I also bought an Arduino and decided to try to make a simple robot with it. So that's been occupying a good bit of my hobby time. (Maybe I'll post some pictures/thoughts about the robot building at some point).

Really, though, the answer to "what's next" seems to be coming down to a few things:

1. Whatever I make, I want people to actually play or use it. I made an RPG engine for the PC once a long time ago that didn't really have a target market. It was a fun project, but not very satisfying in the end, when there was nobody using it.

2. There's already a HUGE pool of existing games out there on the PC (freeware games, or flash games, or whatnot). If I made another one, the chance of getting my game played is pretty small.

3. Although iphone game development would be fun, I don't feel like investing the money to buy a quality mac as well as an iphone or touch. That's somewhere around $1000 to $1500 to drop. I'm too cheap to pay that kind of money unless I'm REALLY sure that's what I want to do.

All of those seem to point to doing another console homebrew game. It's a small enough niche to get noticed, and it's fun to see games running on the actual console. As far as what system to develop for? Dreamcast has a lot of overhead (emulators are poor, so I'd have to be tied down to testing on the physical console, which needs a TV). Atari development is nasty hard (your code has to prepare and render EACH SCANLINE separately), and I'd have to brush up on my 6502 assembler. I'd like to do a NES game -- I think I have a good enough grasp of how to program for it that I could learn it fairly quickly. But it'd probably need to be in assembler also, which would limit my progress.

So I'm leaning right now towards another GBA/DS game. When I started on Anguna, I had debated between a Zelda clone, or a Metroidvania-style game. (sorry for the cheesy label, but that describes it well). I eventually settled on the Zelda clone, but I've still got some ideas for a side-scrolling adventure that I'd like to eventually work on. So that's likely to be the next project.

More specifically, I'm thinking about doing something based loosely on Blaster Master. I'm still debating exactly what that would mean and what it would look like, but that's the direction I'm looking. I've been reading some reviews of older 2d side-scrolling adventure games, and playing through a few of them (Super Metroid, Symphony of the Night, etc) trying to boil down what I like and don't like about each of them. Like Anguna, my goal will be to make the game that I want to play. We'll see where it goes. Especially considering I tend to start lots of hobby projects, and only finish the really interesting ones....

Looking back and looking forward

2009-08-25T11:04:00.002-05:00

I guess now that I haven't posted anything in quite awhile, and Anguna's been all finished for what seems like forever (it's only been a few months?), it's time to do a post-mortem and then figure out what's next.

I've got a lot of rambling thoughts, so I may spread this into a few posts.

First, looking back at Anguna.

Overall, I'd call it a success. For the most part, I made the game I set out to make. The addition of Chris's graphical magic transformed it into something that was actually capable of attracting attention, and feeling like a "real game" as opposed to a toy project. The game wasn't quite as long as I'd like it to be, but it was good enough. A few thousand people downloaded the game (from my site, no clue about the total numbers), people played through it, and seemed to like it. It's currently ranked as the 19th most popular gba game on gbadev.org. I couldn't ask for better.

The biggest complaints or criticisms that I saw were:

1. It needed towns, or more people to talk to
2. It needed more story, or the story was lame.

These made me chuckle a little, as this was purely by design. I really enjoy action-adventure games, but I always get bored when I have to spend a lot of time in a town talking to people, or watching cut scenes. So I purposely made a game with no towns, very few people, and a cheesy plot. I guess there's not too many of us that want that sort of thing.

3. Once you get out of the first dungeon, you don't know where to go, and wander aimlessly.

This is true. It was partially by design, but I didn't implement it well. Again, I wanted to go back to that "big world to explore, and who knows what I might find?" feeling that some of the older adventures games had. Newer games that hold your hand, tell you where to go, or force you to uncover the world one piece at a time don't have that feeling for me.

That being said, when I was playtesting, I found that it was a little too easy to wander around and find nothing. The world was a little too empty or something. I added the purchasable maps to help combat this, and I think it helped a little, but not enough.

4. It was too short.

I agree. But I've learned two things from this: First, that level design (even for a simple game like this) is tedious, time consuming, and difficult. Second, that the quality of level design tools makes a HUGE difference. If/when I do my next game, I'll invest more coding time making (or google time finding) better tools.

5. Bugs or other hardware-related issues (not sleeping properly on the DS, glitches, places you could get stuck, etc)

There were a lot of bugs. That's pretty par for the course on this sort of project. I'm not sure I'd handle it much differently had I to do it over again.

So that's it for the things other people mentioned. Now for my own observations:

1. Crufty, ugly code.

Looking back at the code, there's quite a few places that's it's ugly. It's not decoupled properly in many places. This is all a mixture of a laziness during development, inexperience, and my iterative design process. It's rare to finish a large project and NOT find spots that are ugly (I tend to find that any large body of code that I wrote more than 18 months ago is ugly), but it still bothers me.

Specifically, I tied my sprite management system too closely to the sprite hardware. The same with background graphics. Small bits of platform-specific code were scattered through various places instead of all wrapped up nicely.

2. Separate GBA and DS codebases

I'm not going to go as far as to call this a mistake (because the cleanup required to integrate them might not have been worth it), but it was really annoying. The code is 90 or 95% the same between the two versions. I really should have made it one codebase with two different builds. This will be the plan for the future.

3. Cumbersome Graphics Asset Pipeline

This was really annoying. I didn't have a standardized and easy way of getting graphics assets into the game. Level graphics had to be hand-massaged in a tedious and error-prone way to get them in. Enemy graphics had to be dumped out a certain way. Splash screens a different way. All by hand. I learned my lesson halfway through, so enemy portraits were automated as part of the build process. In any future games, I need to automate away as much of the asset preparation pipeline as possible.

4. Martin Korth is still missing

And I'm still annoyed about it. He's the guy that made the best debugging tool for the DS. But he didn't set up any reasonable way of purchasing it without interacting with him directly. And he's disappeared. So there's no good debugging tools available for DS. That really stinks.

That's all I can think of at the moment. There will likely be more later.

The other thing that I learned from Anguna was just how helpful people are. I was amazed at how many people provided help, code snippets, hardware, testing, etc. It was fun working with everyone who was happy to help.

Ok, that's enough typing for now. Next will be another rambling post about what might come next after Anguna.

Open sourcing Anguna?

2009-02-26T14:58:00.003-06:00

So I've been thinking for awhile about open sourcing Anguna. I had forgotten about it then until other day when my brother mentioned OSS and Anguna in his blog.

So, anybody out there have thoughts about the idea? I'm debating mostly between:
1. Doing nothing because I'm lazy and don't want to clean up the source and put it somewhere.
2. Pulling the core engine code out and open-sourcing that.
3. Open-sourcing the whole shebang, code, assets (graphics, level maps, etc) and all.

Opening the engine wouldn't practically be all that useful -- realistically, is anybody going to use my mediocre engine instead of some better engine, or instead of doing the fun work of making a new one?

Opening the assets means I need to check with everyone that made assets. Daydream made most of the graphics, so his will be easy to check on. But the music and some of the other graphics already have their own licenses attached, so I might not be able to include everything. Is it worth including some but not all? Is it worth the effort of sorting it all out?

I guess a lot of it depends on conversations with Daydream. Which I should have with him instead of here. Anyway, those are my rambling thoughts. Please chime in if you have advice or opinions.

Version 1.02

2008-12-09T21:54:00.002-06:00

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

2008-12-02T22:15:00.002-06:00

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

2008-12-01T22:25:00.004-06:00

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:

Artwork:
Chris Hildenbrand (Daydream)

Music:
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:
Electrobee
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 menus
Sleep mode when closing the lid only partially turns things off, and thus still drains the battery faster than it should
The main theme song (Hurtless by Magic Fred) is using a few XM effects that LibXM7 doesn't yet support.
I didn't add a cool stairs animation like I would have liked

Anyway, as there are most likely still some bugs floating through it, please email me (nathantolbert at google's mail service) if you find any problems.

Enjoy, and thanks for following along!

Everything seems to be working

2008-11-20T21:49:00.003-06:00

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

2008-11-20T16:00:00.005-06:00

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

2008-11-13T21:31:00.002-06:00

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

2008-11-13T14:19:00.002-06:00

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 advancing, slowly. But doing a bit of waiting at this point.

Still here

2008-10-22T20:38:00.003-05:00

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?

2008-10-07T22:47:00.002-05:00

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

2008-10-06T22:24:00.003-05:00

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

2008-09-30T22:38:00.002-05:00

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

2008-09-29T22:53:00.004-05:00

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

2008-09-23T22:06:00.005-05:00

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

2008-09-22T22:52:00.004-05:00

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

2008-09-14T22:51:00.004-05:00

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

2008-09-10T22:21:00.002-05:00

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)

2008-09-08T22:24:00.000-05:00

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

2008-09-07T21:00:00.000-05:00

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

2008-09-06T21:54:00.000-05:00

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

2008-09-05T19:05:00.000-05:00

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

2008-09-03T22:49:00.000-05:00

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.

Typo and my bool

2008-08-28T13:15:00.000-05:00

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 other values that I threw at it somewhat incorrectly (32, etc), made it harder to track down.

But I did get a lot more stuff finished off last night. There was a renegade sprite that kept showing up at semi-random times, with semi-random contents. I think I fixed it: it hasn't come back since I changed what I think was causing it (I was using a few partially-uninitialized sprites, in my bullet management code). But, like many intermittant problems, it's hard to know for sure. I also got the currently-selected-item sprite to appear up in the upper-right where it's supposed to.

Next up, moving all the menu/map/etc to the bottom DS screen. I got a start on it last night, but there's plenty more to do.

On a roll

2008-08-26T15:49:00.000-05:00

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 screen...you 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 glitches
Get the overworld tiles to load correctly. Like the priorities, I was doing this dead wrong, so it was an easy fix -- I was loading a fixed amount of tiles for each map, and that fixed amount was completely wrong.

Let's see if I can keep going at this rate.....

Correction and signed/unsigned ints

2008-08-25T09:15:00.000-05:00

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 task of porting is complete!

There's still plenty of issues to work though, even with backgrounds -- the priority of the foreground tiles isn't right...sprites still appear in front of them. And the overworld tiles aren't loading completely -- I'm probably just not copying enough tile data in that case. But I'm getting there!

More screen size and premature optimization

2008-08-20T11:13:00.000-05:00

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 chunk of the problem was because of stupid optimizations that I (needlessly) did. See, the gba and ds don't have floating point units. And can't do divides with any reasonable speed. But in unsigned binary, bit shifting right by 3 is the same as dividing by 8. And because the tiles are all 8 pixels, I'm dividing by 8 all over the place. So instead of telling it to divide, I bit shifted, to make sure it was fast. Now this was stupid, because a good compiler (which gcc most certainly is) will do this optimization for me. But I figured it wouldn't hurt to make it obvious that it was happening, and thus prevent the compiler from randomly deciding NOT to bit shift and do a slow division. BUT that doesn't work if your number is signed, which mine now is. This is because negative numbers are represented in two's complement. You can still do fast divides with clever bit-shifting, but not as simply as just shifting right 3 bits. So now I need to go change all those places where I was trying to be clever back to actually using a normal divide, and let the compiler do the optimization.

Lesson of the day: my compiler is smarter than me. Let it do the clever stuff.

Screen size

2008-08-14T13:34:00.000-05:00

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 the background bigger. Which is what I did, but there are some tricks with that. For a 32x32 background, the tile indices are layed out linearly, so for any given tile, the index you want to write to is x + y * 32. But for wider backgrounds, it's different..instead of a big wide background, it's two small background stuck together. Which changes us to the slightly trickier system of:
index = x + y *32;
if (x > 31) index = index + 1024;

Not a big deal directly, but a whole lot harder to use pointer math (which I had been doing) to deal with. So I had to go through and change things to not use any optimized pointer math, and instead, compute it the hard way. (Which is probably best -- as Donald Knuth says, "premature optimization is the root of all evil"). Once that was done, things are pretty close to working!

Of course, there were some other gotchas along the way. For example, I had a horribly hackish way of keeping the foreground and background layers synced, which didn't really work the way I wanted it to for the DS, so I had to do it right this time.

Anyway, the game is actually almost playable now. There are lots of little things to do (enemies don't fade when they get hit, your selected item doesn't show up, the foreground tiles appear behind your character, the outdoor graphics are messed up, scrolling southward is glitchy, etc) and I still need to change things so that the 2nd screen is used for subscreen, minimap, enemy stats, etc. (I also just got around in this build to adding text to the 2nd screen...thus the "hi" at the bottom of the screenshot) But it's moving along faster than I expected! (at this rate, maybe I'll be able to start an iPhone port before the thing is obsolete)

Sprites, DMA, and caching

2008-08-07T14:26:00.001-05:00

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 updates, using DMA to copy all the sprite information from main memory into that magic vram that I talked about last time. (vram being the place where you tell the DS what your sprites and all other graphics should look like). But the more I debugged stuff, the more it looked like my DMA memory copy just wasn't working in this case. It worked other places on the DS, but not here. My conclusion: My DS hates me. But alas, I knew that chances were small that that was really the problem.

So after much digging (and much hatred directed at Nintendo), I found the issue: the DS has a memory cache, which, in the case of how I'm developing, is used more-or-less automatically. So, thinking I was writing to main memory, I was just writing to the cache, which hadn't been flushed back to main memory yet (the cache and memory were out of sync). The DMA doesn't trigger the cache to write back to main memory, so I was copying out-of-date information into vram. Bah. Easy fix, but like everything else in the land of debugging, took ages to figure out.

Next step: why my background is all wonky.

Title screen and vram banks

2008-08-05T14:06:00.000-05:00

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 vram. In the DS, there's a few banks of memory that are meant to be used for vram, but aren't assigned to specific memory addresses by default. You have to assign them yourself, depending on what you want to do with your video. If you are doing fancy 3d stuff, you assign them to the 3d texture memory addresses. If you're doing 2d tile graphics, you assign them somewhere else, and so forth. The trick is that there are certain configurations that are valid, and others that are not. And somehow I had been using an incorrect configuration. So changing that all around fixed things. So now it's working. Although I'm still not sure I have my head wrapped around how these vram banks are supposed to work, and why It's working now, but I don't completely understand it....and that's a dangerous place to be (If you want a taste of what the vile documentation looks like, check this out) . Oh well, for the sake of time, I'll move on, and come back to these things if they bite me again.

Next step: get this looking a little more normal:

Getting Started

2008-08-02T13:28:00.000-05:00

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 those.
Change just enough stuff to get it to compile and run, in some fashion, on the DS.

I've managed to get 2 out of the 3 taken care of. Getting it to build on Linux wasn't too hard. The toolchain was all based on gcc and MinGW stuff, so it was perfect for moving to linux. The hardest parts were some stupid places where I had been abusing windows' case insensitivity, some issues with the line break differences between *nix and windows, and a few of the graphics/level conversion tools that had been compiled as windows command line programs. Some of those tools I recompiled in linux, and one (which I could never find the right linux libraries for) I just run under wine.

The cleaning up of messy bits then got started. And after a few hours of starting to move stuff around, my eyes started glazing over, and I realized I could spend forever just on this task. Once you start trying to get something perfect, you could spend years on it. And with the twins, years of development time is something I don't really have at the moment. So after awhile, being the pragmatist that I am, I decided to leave the ugly code alone, and just go on with things.

That left converting it over to run on the DS. This was annoying, but not too bad. After an hour or two with twiddling with my makefile, and a few more hours of doing mass amounts of vim regular expressions to replace the GBA constants, memory locations, and functions with their DS counterparts, the thing compiled and ran. Most of the graphics are completely messed up, and there's no sound, but it runs! Next step: getting the graphics fixed.