On Doomdark's Revenge

According to my records today marks 8 years to the day since I released my GBA remake of Doomdark's Revenge. A few people have asked me "are you going to release an Android port of your remake?" - to mark the anniversary the answer is yes! and here it is! :-)

"Is that Don Quijote?" asked my wife

In addition to an Android port, I've gone back and fixed several show-stopping bugs that were in the GBA remake. The updated GBA version is on my remakes site.

• Lords artificial intelligence is no longer completely broken
• Several crash bugs fixed
• The game is faster (and smaller) thanks to using the right compiler flags

In the Android version I've changed the controls slightly compared to the original LOM remake. In particular, Google has now deprecated the Android menu button. I don't think this means they'll send someone round with a screwdriver to pry it off your old HTC Desire or whatever, but that we developers should stop using it. Up until now I'd always used Menu like the GBA Start button, but seeing this trend I didn't use it here and I've gone back to my LOM remake and removed the use of Menu there too. I don't think anyone will really miss my poor use of the Menu button, it was always a bit of a mystery what it was going to do.

While working on this, I spotted a bug in The War of the Solstice that caused it to crash on versions of Android prior to 2.1. Both remakes share a lot of common Android Java code, so fixing this in one remake also fixed the other. The lazy loading technique described in this blog post makes supporting older versions much less hassle.

In the near future, I am going to update the source code downloads on my GBA remakes site so it reflects the latest versions of everything. One thing at a time.

Back to that AI bug... A keen gamer brought it to my attention back in 2009, but I was busy doing other stuff at the time. Here's what he had to say:

However the AI seems not to work correctly. Using the Spectrum version thelords would usually catch up with their liege or head for their foe or weapon. Using your version there is no Anvildrak, Imgorarg or Kahudrarg heading for Luxor and I have yet to see any pair or group of lords. Instead I've seen several single lords right next to the Frozen Wastes.

At the time I wrote back saying that the bug was probably in the code that decided which way a CPU-controlled lord moves, but I didn't investigate further. Now I fired up GDB and stepped through the AI code. At the same time I also stepped through a suspiciously similar looking bit of Z80 assembly in the original game using fuse's built-in debugger. After comparing notes I immediately saw what the problem was - instead of going towards their targets, my code was sending the lords away from them! What a mess-up, but the fix was simple.

Another "bug" in my remake was a kind of meta-bug. Instead of compiling the code with optimizations on, I had compiled with gcc's defaults. This meant the 2004 remake was much larger and slower than it should have been. The binary came in at over 100kb! This new version is 77kb big - still over twice as much as would have fit in the Speccy's RAM you'll notice - and noticeably faster.

How to recruit on LOM

I've had an email about how to recruit on my Android Lords of Midnight remake - "the War of the Solstice". That means other people are probably stuck too and haven't asked. Here are the basics.

From the start of the game, go Northwest, Northwest, Northeast and you'll stand on the same spot as the Lord of Shadows. Here I've done it as Morkin, but you can use any of the starting group.

Now touch the name part of the text (where it says "Morkin. He stands in the Forest of Shadows, looking Northeast."). This brings up the "Think" screen.

On this screen, touch the right hand part of the text. This brings up the "Seek" screen, where you can do the recruiting.

On here, touch the option to recruit the Lord of Shadows. That's it!

Silly Predictions For Android Versions In 2012

Image via WikipediaLast week Google released the latest numbers with the percentage of each Android version accessing the Android Market. What really jumped out at me is the rise and rise of Gingerbread (2.3.x), and the fall of Froyo (2.2). In the past I've been a bit skeptical of Google's commitment to older versions of Android. Looking at the way things advance, it makes no sense for them to dedicate resources to try and make life easier for developers on older devices. Every year the release 2 versions ago more or less disappears, or that's the way things have been tending to go for the last couple of years at least.

Here's a graph of how the relative percentage has changed over the last 18 months. I've occasionally jotted down the percentage numbers in a spreadsheet, and the rest I got from the Wayback Machine. I've lumped minor releases together, so 2.3.1 and 2.3.2 are in the 2.3 bucket.

Version 2.1 (Eclair) is slowly disappearing, despite being at 55% back in July 2010. 2.2 (Froyo) is at 30% now, though in mid 2011 it peaked at 65% of the Google-approved devices online. Right now 2.3 (Gingerbread) is on the rise. I think the poor showing of 3.0 (Honeycomb) confirms that the driving force behind these numbers is mobile phones, rather than tablets. For those not paying attention, Honeycomb is only available on tablets, you see.

Given all that, here's my predict-o-graph of how things will go in 2012. The yellow area marks my completely arbitrary prediction values of how the percentages will change. I've pulled the numbers out my /dev/backside.

If everything follows the same pattern as previous years, by early summer 2012 Gingerbread will have peaked at about 60% of the market. By the end of 2012, Froyo will be on fewer than 10% of devices, Gingerbread will be on the slide, and the newest Android release - Ice Cream Sandwich, version 4.0 - will be taking over. I don't think Honeycomb is going to grow much this year, and the relative percentage of devices with 3.x may even shrink. No new tablets should be released with Honeycomb this year anyway - if they are released, they won't sell very well or will be upgraded to ICS pretty quickly - and most new or new-ish phones will have or get ICS too.

As for me, and the games I've put out on Android... I'll continue to target 1.6+, since I don't really do anything that warrants a newer release and 2.2. is all I've got (curse you HTC and your locked bootloaders!) I think that by the end of this year I may have to look at upgrading, by then a 2nd hand Samsung may have come down to the kind of cheapskate price I'm willing to pay :-)

Non-ARM Android Apps

I've had 2 requests now for my Lords of Midnight remake on x86-based Android devices. A while ago I updated the scons-android build system I use to support multiple architectures, but I didn't actually upload an x86 version to the Market. I thought nobody actually owned one of these mythical devices. Turns out that times are changing.


Back in July, Google added multiple APK support to the Market. Sadly, the multiple APK idea is a bit limited in what you can do. The APKs have to be different in one of 3 key features only. These features are Open GL texture compression type, screen size and API level. Differences in other features - such as whether the device has a touch screen or not, has a hardware keyboard or not, the type of processor it has, and so on, are all ignored. If the only differences between the APKs are in these "minor" features then they are considered identical by the Market software and will not be allowed to coexist.

The explanation I've read as to why this is the case is that the Market client application on devices doesn't provide enough information to the Market server for it to make use of all the feature filters. This makes some sense, as there have only really been multiple ARM ABIs available since June 2010 with release 4b of the NDK. But the Market does already know how to hide non-compatible APKs from you, so I get the feeling this is more a case of "we can't be bothered to do this" rather than "we can't do this".

As it stands, in order to do an x86 version of an app that uses native code while still maintaining compatibility with the majority ARM devices, you need to provide a so-called "fat binary". This is an APK that contains a copy of the ARM version (versions) of your library and the x86 version too. I think it's a bit of a shame that users with one type of processor have to pay the download-tax due to the inclusion of its "evil twin" opposing processor library. Fortunately the Android installation tools are smart enough not to copy useless libraries onto the device for use at run-time, so it is only the increased download size that is a problem.

With this in mind, I've uploaded a new version of War of the Solstice and Chaos that support x86 too. Since I don't own anything that I can actually test these on it is a stab in the dark - it may work, but it will likely just crash, let me know with your 1 star reviews! ;-)

Screenshot of the strange Android Market upload warnings

One thing that worried me slightly is that when you upload an ARM/x86 dual APK to the Market it says "this apk requests 2 native platforms that will be used for filtering". That makes it sounds like you need a strange ARM and x86 device to make the game work. I hope that this is just a typo, and that the final APK works on just about everything.