The building of a new citadel upon the ashes of the old had already begun.

I thought I’d take the opportunity to briefly discuss the Lords of Midnight rebuild particularly for those people who have found their way to the blog more recently. I have spoken a number of times over the last few years about the loss of the Marmalade system that I was using as the underlying cross platform support for LoM and DDR, and that I would need to rebuild the project under a new system in order to at least keep supporting it, and better add some new functionality. The rebuild has almost been a full UI recode with very little backend game changes other than to get code compiling on various platforms. During the UI rebuild I have taken the opportunity to change the way a few screens might work, but nothing too drastic. In many cases the rebuild has simplified the code in certain areas.

I know this process has taken a frustratingly long time, but happily that process is now almost complete. Both The Lords of Midnight and Doomdark’s Revenge are up and running, and they now both completely share the same code base. I have placed the skeleton versions of the Desktop in test so that I can see if there are any glaring issues with the new build, and will now focus on getting them released for Mobile before coming back to Desktop and tidying up the few features I chose to drop in order to get me to a Minimum Viable Product.

Availability

The first thing to point out is that none of the following versions will be released as a new purchase, so if you already have the game, you should be able to pick up the updates for free as long as your device is supported. And in theory over the last six years most people will have updated to new devices anyway.

iOS

The reason for the iOS focus is that The Lords of Midnight currently does not work at all on the iPhoneX range of phones and essentially it is the version most endanger of being pulled from the store. I’ve had a few reports of the games not working on Android, and none at all for OSX and Windows.

This week I will be testing the game across all the current resolutions for iOS devices to make sure they all work as expected. I will then take stock and the end of the week to see if I can release both iPhone and iPad versions together or not. Either both or one of those versions will go into public beta through Apple, and then I will look and OSX.

OSX

The reason for OSX focus is due to 64 bit support. The next version of OSX – Catalina, due in September, will remove support for 32bit apps. I can honestly say that I have no idea if the versions on the App Store were built 64 bit or not, but I suspect not. Under the current development system, all I need to do is build and submit – in theory!

Android

Android needs a little bit more work. Firstly just getting the new code base building. I have not focused on this at all just because I’m Mac based, using iOS, and needing a Windows version for Drew. However, I have not been concerned at all that it will not build, it will just take a short time going through the motions. The I need to test against a number of screen resolutions. This is the area that will probably cause me more work if it hasn’t already as part of the iOS process. It is likely that the rewritten landscaping technique does not hold up across a number of different aspect ratios. And of course, 64bit will soon raise its ugly head across the Google platform.

Windows

Windows version is already building and the only real work required is Fullscreen and Resolution support. There will also be a little bit of Desktopification required as I look back at all the features and make sure I am not too Mobile centric.

There is currently no real urgency on the Windows version other than wanting and needing it to generally be released as soon as I can. The only real consideration I am having with Windows is whether to consider Steam or Epic Games store as a new mechanism of distribution.

Feature Parity

During the process of getting all the versions released and then immediately after I will take time to make sure that all the features that I have removed in order to hit a release, are put back. Most of these are small things like a few touch gestures and shortcuts.

Gameplay

There are technically no gameplay changes. However, there are a few bugs that have been fixed over the last few years that some or all of the versions have not been updated with.

The Future…

New things can now start to happen… 🙂

Reference:
  1. This time you’ve got me to help you
  2. The Moon Ring lends us the power to change our plans
  3. The way was obscure but he moved onwards
  4. We cannot spare more than a few for such a perilous task
  5. Above the towering clouds simply melted away and the bright stars gleamed in the sky once more
  6. Only Luxor remained with a thousand riders of his houseguard waiting for news

Shading the night sky…

One thing that got carried over from the original Midnight Engine was the shading of the landscape depending on the time of day. The original Lords of Midnight, has a different colour for night which is basically that all the white becomes black, but the blue remains the same.

In TME and therefore the remake, I have a tint colour for each time of the day, and the images are tinted toward that colour. That colour is generally a shade of grey and it is used to darken the dawn, brighten up to normal colours around midday, and then dark off fully to night. In reality, this is one area of the remake that I left in that I don’t like. Only because, it doesn’t really look like the original. The night view has a very distinctive look, and as you can see though, the remake doesn’t look the same. It’s fine as things goes, but I would have much rather made it look more like the original.

Doomdark’s Revenge however has a completely different approach. There is a dawn visual, and day visual, and a night visual.

I knew therefore that when I got around to releasing Doomdark’s Revenge, I was going to have to deal with this issue. The tinting method just didn’t cut it. Because I could tint to red, or tint to yellow, but not combine them.

To give you a little background. The colour changing was relatively easy on the ZX Spectrum. Partly because the images were very simple and were constructed, but also because of the way that the spectrum only had two colours in a 8×8 grid – known as the paper and ink. So all the effects were done by just changing the paper and the ink. These colours were not stored with the bitmap either, it was a different memory area. So in fact, what Lords of Midnight does is, clear the screen with paper and ink both white, draw all the pixels to the screen, which you can’t see, and then fills in the paper and ink colours which makes the screen appear.

Now, the choice I made when porting the game was to use full 24bit alpha’d bitmap images. I can discuss the merits, and the whys, and possibly the mistakes, of this decision. But, it’s not been one I can change easily.

The upshot is: changing colours on the fly isn’t easy. It’s much easier with 8bit palletised images. But believe it or not, despite the fact that the terrain images only use two colours, they actually use at least 255 colours in order to get smooth edges, as well as being alpha’d. Changing to palletised images just made it look awful.

Once solution that I knew could work would be to write a custom shader. Shaders are dark voodoo magic that happen on the graphics card. And I’ve never written one in my life. Had Mike been around, he would have knocked one out very quickly. But obviously he wasn’t, and as I was heading toward the original release of The Lords of Midnight, I didn’t have time to look into them.

Now however, I couldn’t ignore it any longer. With the latest update of The Lords of Midnight sat awaiting approval from the platform holders, I turned my attention back to Doomdark’s Revenge, and the next thing to address, was making the dawn landscape look proper. I was going to have to learn to write shaders. And that’s what I spent yesterday doing.

The end result is that I now create all my terrain images as being black and white. These two colours will be replaced by the shader as the image is being drawn to screen. However, I can’t just replace the two colours, I need to make sure that I where the two colours meet they get blended.

mountain_fragmentIf you click on the Mountain fragment you will see a blow up of the image, and see how this would work. Affectively the image can be considered thus; all black, all white, mixed. The mixed part always being where the two meet. So if we consider that we will replace all black (0,0,0) with new colour_a and replace all white (255,255,255) with new colour_b, the other colours will be a shade of grey from (1,1,1) to (254,254,254). What we actually do is  use the value of one of the colour components to work out the mix of our two new colours. so 0 is 100% colour_a and 255 is 100% colour_b. A value of 153 for example would be 40% colour_a and 60% colour_b.

Now, it’s not rocket surgery, there’s nothing particularly clever going on here, but for me I had to turn this into a shader, and that was new territory.  However, working within the Marmalade SDK and using the OpenGL ES shader reference manual, and a little bit of google… the process turned out a little easier than I expected.

Here is the landscape without the shader active.

Screen Shot 2013-10-27 at 02.07.47

 

But with the shader active, and the two colours adjusted depending on the time of day, we  get the following.

And, if we now revisit The Lords of Midnight, we get the resulting night landscape that I always wanted.

Screen Shot 2013-10-27 at 01.10.33

 

Not sure when this will make it back into the current release, probably after Doomdark’s Revenge is released and I’ve been able to fully test the shader across multiple platforms. But it will make it back.

Dawn approached stealthily

With the Solstice nearly upon us, I thought I’d post an update on the status of the Android version.

Firstly, to be clear, I’m not going to have a final release ready for Friday. I apologise for any disappointment that generates, but I think it’s for the better.

Over the last two weeks, in between getting everything ready for the release of the game, Website, Documentation, Press Release, and other final flurries, I’ve been trying to get the Android version working. The good news is that it does. I have it completely playable on my Nexus 7. The problem is with a) the sheer number of resolutions that need to be supported, and b) not actually knowing what those resolutions are. I noticed for the first time when I ran the app on my Nexus 7, that the expected 1280×800 became 1280×736-ish because of the Nav Bar. This means that although I have a list of a large number of resolutions to support, I don’t actually know what they really are. Making the resolutions support having to be even more robust than I expected.

This on the whole, it is. However I have been having issues with the landscaping, which I have struggled a little to resolve. This is partly because I don’t fully understand the process not being a 3d programmer, and the landscaping being 3d maths. Landscaping was originally written for 4:3 aspect resolution and I’ve had to tweak it for others. Sadly, Mike would have dealt with this in two shakes of a Skulkrin’s sleep frost.

I’ve nearly resolved the issues, it’s working on most of the test resolutions I’m trying, just a little tweaking to do. But even if I have it finished by tomorrow, there is no way I can release it into the wild without more major testing.

Hopefully what I can do, is make a version available by Friday that can be side loaded onto Android devices for a quick test against as many real devices as possible, with a view to releasing on Google Play the following week if all goes well.