Moving from sourceforge

And along with this, I decided to move the DS version of Anguna (which was open-sourced awhile back, and sitting on sourceforge) away from sourceforge. Because if you haven't paid any attention to the news, Sourceforge has gone nasty.

So the source is up on bitbucket now. I still have some cleaning up I really need to do, but there it is.

DS build (probably?) working again!

So again thanks to Sverx, I think I have the DS build of Anguna working again.

In response to one of my previous posts lamenting that I couldn't find a 2008 release of the devkitPro/libnds tools, he mentioned that he had a copy!  He sent me what he had, which turned out to be the windows version.

Although GBA anguna was developed on windows, I developed the DS version on linux. So everything I had was set up for linux, and I'm currently using (and running my builds on) linux.

My first attempt to get it working was to just use my current version of my gcc arm cross-compiler with the 2008 version of libnds, which as I suspected didn't work.  It compiled, but the linker complained about all sorts of things.

I didn't want to go all the way and set up everything in windows yet, so the next try was stupid: use all the windows toolchain compilers via wine. Has anyone EVER run windows versions of gcc on linux using wine before? A terrible idea.  But it seemed to work when I compiled it. (despite taking quite a while to compile!)  But when I ran the finished rom, it had all sorts of weird issues once you got into the game, past the splash screens.

But this seemed familiar, similar to the problems I had trying to compile the gba version on linux recently. So I went through and made sure to convert all the files' line endings to unix (not sure why that would be an issue, since they were originally done in linux), but then everything worked!

So despite the terrible idea of running all compilers in wine, I know have DS builds working again. (I think? I haven't tested it yet past the first couple of rooms)

Maybe that means the new dungeon will eventually get ported to the DS!

Corrected....

In my previous post about the volatile keyword, Sverx left an insightful comment, noting that because nothing is changing the SRAM data outside of my code, it shouldn't really need to be marked as volatile.  Which is true -- nothing really changes it at run-time.

So what was the actual problem and why did marking it as volatile correct it?

For one thing, as sverx mentions in the comment, SRAM can only be written 8 bits at a time. Which I'm doing (casting my data into 8-bit chars and looping through writing them one at a time). But now I'm wondering if the newer versions of gcc saw that, decided I was stupid, and optimized it into 16- or 32-bit writes. Which would make sense why adding debugging messages in the inner loop would change it.  Marking as volatile might also have been enough to scare the compiler off from over-optimization, and fixed it as well, although not quite as correctly.

Thanks sverx!

Updates

So here's where everything's at right now:

GBA Anguna: new content is finished, the rom is being playtested by folks at Piko Interactive (which they've already found (and I've fixed) one bug), hopefully soon will be sent off for production!

Robo-Ninja: The game is pretty close to finished. This week I've been working on the ending sequences and more google play services integration. I might skip the cloud saved games (it looks like a bit of a pain to convert my save game format to work with it, but we'll see).  The biggest change is that Chris (the guy that did the graphics for Anguna and the new awesome Robo-Ninja character graphic) has some great looking designs for improvements to other graphics in the game, including all the UI bits, so I'm planning to wait to see what he comes up with, and probably do a bit of reworking all the UI to use his designs.  (although there's still a little bit of work to do until then: tweaking some level designs, testing, and improved keyboard controls for non-touch screens (I plan to provide both a java desktop download, as well as a Google Chrome app)).

Atari Anguna: This poor guy has been getting neglected thanks to the work on GBA Anguna and trying to do a mad dash to finish Robo-Ninja. The core engine is in pretty good shape, and I need to build out a test dungeon to do some more in-depth testing. The next steps will be getting the header/hud thing working right, and then secondary items (bow & arrow, dynamite, etc).

Robo-Ninja Boss Fight

My office-mate Tim has been so kind as to play through Robo-Ninja, giving me great feedback along the way. A week or so ago, he finally got to the end -- at least so far. He got to the room right before the main boss. And has been patiently waiting for me to give him a boss to fight.

Well Tim, we're almost there.  I think the boss is done. Although once you kill him, I don't have any sort of victory sequence or anything. He dies and you're just stuck in his room. But hey, progress.

I ended up NOT giving him multiple forms after all. Partially because I'm ready to finish this thing, and partially because while testing it, he seems hard enough already. 

So now there's just a few things left to do:

• A few map tweaks based on Tim's feedback
• Fix a couple of bugs in my game engine (again, based on Tim's feedback) 
• Add graphical icons on the teleporter UI (I've had blank placeholders sitting there for months now)
• Finish the options and license/credits screen (I've used a ton of Creative-Commons licensed art and sounds, so I have a lot of credit that needs to be mentioned)
• Finish the leaderboard and cloud save integrations
• Add an ending sequence
• Test, Test, and test again
• Release the game, get rich, and retire

No DS re-release for now....

So today I download the source to the Nintendo DS version of the Anguna to see if I could easily get it to build, to push the new level to it as well.

Didn't turn out so well so far.

The development kit for GBA and NDS development (devkitPro) has both the compiler toolchains/build tools/etc for development, as well as some libraries for interacting with the various platforms. The libraries are mostly thin wrappers around the basic functionality (nice names for the various registers, utility functions to deal with them, etc), but there's a few other bigger bits, such as sound libraries, etc.

On the GBA, I didn't use any of the devkitPro libraries directly, and instead just managed my own, using just the simple register definitions.

On the NDS, I ended up using a lot more library calls from devkitPro. Which turned out to be the problem here. The NDS libraries on devkitPro have changes significantly in newer releases. And I'm having trouble coming up with a version of the library from 2008 that works properly.  Unless I can magically come up with a working version of libnds circa 2008, the only other solution is to rewrite quite a bit of code to work with the newer version of libnds. No thanks.

Volatile

I spent about 2 hours last night pounding my head in a wall trying to figure out the solution to a new bug that I ran into: Anguna's save game function was no longer working.

In the GBA, the most common save method is to just write to a magical area of ram that happens to be battery-backed, so it retains its values. So when I save, I write the game state to that area, including a checksum.  On loading, I read the checksum to see if there's a valid game state in ram (as opposed to un-initialized garbage), and if it's valid, load it.

So last night, I was writing the data, but then when I read it back out, the checksums didn't match!

So I started debugging. I logged the first few bytes writing to save, and logged them again as I read them...everything looked right. So the first few bytes were working. I tried again with the last few bytes -- they matched also. Weird.

So I dumped ALL the data to a log upon saving and loading. And Lo And Behold, they matched, and it worked correctly.  Uh oh.

I removed the debugging, and it broke again.

This is normally an unhappy position to be, although this time it quickly led me to the solution. There were no actual side effects of my logging code (other than the logging itself), so clearly the compiler was optimizing something differently.

Then I checked to make sure that the save ram was marked as volatile. Nope. Oops.


In C, you can mark variables/memory/etc as volatile, which means that its value can be read or written outside of your current program. This lets the compiler know NOT to optimize away read/writes to it.

For example, in the gba, to get the state of the controller inputs, you read a particular memory location. If you don't mark it as volatile, the compiler will notice that you are reading it every frame, but never writing to it, and might optimize away your other reads. Which is not what you want.

In this case, I'm not sure exactly WHAT the compiler was thinking in optimizing away my reads/writes to the save data, but marking it as volatile did the trick. And I guess the compiler's optimization strategies have changed since I last worked on Anguna, as I never had it marked volatile before. Oh well.