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.

Related Posts:

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.

Related Posts:

Blackberry Playbook

I recently registered for Blackberry development through Marmalade. The reason was because RIM were offering a free device on loan to test your application. I figured I had nothing to lose, so why not. Anyway, the process was pretty quick and within 10 days I was accepted on the program, qualified for the device, and it turned up today.

I installed the Native SDK, which in turn allows Marmalade to target the device natively. I registered all the certificates etc that I needed. Built the app. Deployed to the device. And well…

There you go. The process was pretty painless. The Marmalade SDK did it’s thing and it just worked. The previous work I did on resolution independence paid off. I just have a few tweaks to make because of the widescreen. But other than that… fully functional.

Related Posts:

Slow development week

I got a new iPad on release day, and I have to say it *is* lovely. The screen is just amazing. Can’t wait to fire LOM up on it, and also I can’t wait to see LOM running with some proper higher res graphics on it. ( BTW: Mike and I have had some discussions with a collective of artists who currently develop on iOS, and it is possible that they will be picking up the reins on the project – more of that in the future )

Anyway, tried to add the new iPad to my develop setup only to be told that I needed a development version of iOS 5.1. So, I did the usual and updated XCode. XCode has been supplied from the Mac App store for a couple of updates now, and Apple took this opportunity to finally change the installation. It used to install to a set of folders inside /Developer but now it installs as a single app inside /Applications.

The knock on affect was that it removed my /Developer folder, which removed the Marmalade SDK. No problems really, I needed to install the latest SDK anyway.
Only, after I did, nothing worked anymore! So not only was I able to target my new iPad, but I was unable to compile and test anything!

I could of course uninstall everything and go back a few versions, but I figured that I would post a support issue on the forums and hope for a quick resolution. Turns out that there was a simple fix, telling the system where the XCode tools now reside using xcode-select. Only it took me until last night to get it actually working.

The knock on affect – no LOM development since last Friday! 🙁

Related Posts:

Lords of Midnight – Lord Select

Screencast of Lords select screen concept demo. Running in the simulator.

This shows grouping.

** Work in progress **
** Placeholder Graphics **

Related Posts: