2014 totals

So, The Little Crane That Could is still chugging along, but undeniably it has peaked. I hope there is life left in the brave little crane, but it may be running out of steam. Here are the 2014 results (Number of free Downloads.)

	2014	2013	2012	2011
iOS	1300K	3199K	3454K	1550K
Android	825K	1579K	1656K	-
Mac	30K	53K	81K	-
OUYA	4K	15K	-	-
Kindle	46K	95K	-	-
Rasp Pi	?	6K	-	-

I have been unable to check the Raspberry Pi downloads. The statistics report on the raspberry store is broken. It looks like the pi store was part of indiecity, which is part of Blitz Games, which seems to have gone under. I'm not sure if the download is still available on the store.

This brings the grand total of Little Crane downloads to 13.9 Million. Hooray for Little Crane! One last note: Little Crane is also available for GNU/Linux and Windows, but those releases saw downloads in homeopatic doses.

More Photon Mapping

In yesterday's post, I introduced my new hobby project Photon Mapping Voxels. Today, I made some more progress, and managed to properly interpolate the shading. The voxel faces in a plane now share vertices. But there is still a matter of ambiguity when shading a quad, which causes the triangle seam to show in the middle of the quad. To alleviate this issue, I added a center vertex in the middle of the quad, and render it as 4 triangles, instead of just 2. The results are below. The animated gif cycles through four renderings: quads, triangles, triangles in wireframe, quads in wireframe. As you can see, there are less discontinuities in the triangle version, at the cost of more vertices, and double the triangles.

Again, this is direct light only. I am getting excited about seeing it with indirect light (bounces) and also colour. Currently, all photons and all voxels are white. Also on the todo list: make it really fast by doing SIMD intersection tests: a ray versus 8 voxels in a single go. This requires AVX though, probably AVX2 even.

Photon Mapping

With my latest game, The Little Plane That Could launched, it gave me a good opportunity to start some experimental coding. I would like to crack the challenge of real time indirect lighting. My idea is to use voxel-geometry only, and run a photon mapper on this geometry. Because the geometry is simple, the intersection tests (AABB vs ray) may be fast enough for real time use.

Below is an early result, where I shoot photons for direct light only, no bounces yet. It shows the raw photon hits, and a low-pass smoothed version of it. The light source is not visible, but is not too far above the pillar.

I also tried flat shading the voxel faces based on the number of photons that hit it. The discontinuity between faces is too distracting though. So the next step is smooth shading the quads. A first attempt with Gouraud shaded quads looked pretty horrible, so I need to rethink that.

The Little Plane That Could

This is just a heads-up that my new game The Little Plane That Could has been released for iOS, Android and GNU/Linux(64bit).

It was made available for Oculus Rift (Win64) earlier and a Mac OSX version is still in the pipeline.

Its highlights are the great physics, the convincing AI pilots and the immersive 3D Audio via OpenAL. To run the GNU/Linux variant (free to try, pay-what-you-want) you need to install its requirements using:

$ ./apt-get install libopenal1
$ ./apt-get install libalut0
$ ./apt-get install libsdl2

I've tested it with Ubuntu 14.04 LTS. And it requires a gamepad to run. If your gamepad is not supported by SDL2, you may have luck with adding it to the gamecontrollerdb.txt file.

Using the OpenAL library in Xcode for iOS.

The last two days I have been porting The Little Plane That Could to iOS. It was already running on OculusRift(Windows), Linux, Android and Mac OSX. When porting it, I struggled with the poor OpenAL implementation that comes with the iOS SDK.

I knew that there was a very low limit of 32 sound sources for iOS. I figured that this limit only applied to sound sources that were in 'AL_PLAYING' state. And sure enough: you can create much more than 32 sources, without getting errors back from the OpenAL implementation.

In my game, I have 48 planes flying around, each with engine sounds. If we forget about gun sounds and explosion sounds for a while, these 48 engine sounds already exceed what the iOS implementation of OpenAL can handle. So this is why I adopted a method of only playing the four closest engine sounds. If an engine sound was further away, I would pause the playing of this sound. This worked well on all platforms, except iOS.

The problem I experienced was the following: alGetError() would start returning a non-sensical value of -1. And the sounds would no longer get started. The return value of -1 for alGetError() violates the OpenAL specification standard though. If you study the header files of the SDK, you see that the only acceptable return values are 0 (AL_NO_ERROR) or:

/** 
 * Invalid Name paramater passed to AL call.
 */
#define AL_INVALID_NAME                           0xA001
/** 
 * Invalid parameter passed to AL call.
 */
#define AL_INVALID_ENUM                           0xA002
/** 
 * Invalid enum parameter value.
 */
#define AL_INVALID_VALUE                          0xA003
/** 
 * Illegal call.
 */
#define AL_INVALID_OPERATION                      0xA004
/**
 * No mojo.
 */
#define AL_OUT_OF_MEMORY                          0xA005

After struggling to find the cause of the problem for half a day, I finally solved this issue. It turns out that the 32 source limit applies to BOTH playing and paused sources. Only sources that have not started playing yet (AL_INITIAL) or have been stopped (AL_STOPPED) do not count against the limit. So the fix was relatively easy: sources that are not nearby should not be paused. They should be stopped instead. This does not take away the fact that the alGetError return value is not according to spec. Apple should fix this.

What has Bram been up to?

So, it's been quiet for too long on this blog. It is about time to report on what I have been up to. Why not start with a small snippet of video?

Since July 2013 I have been mulling over the next step for my crane sim game. And as the holy grail, I have put forward an ambitious development target: deformable terrain. Frankly, I have not yet seen a single game getting this right. I most likely will not achieve completely realistic, sandbox-style, unlimited deformable terrain either. But I will surely try. The video above show a bulldozer at work in my terrain simulator.

Currently I have achieved the following:

• Proper 3D terrain, not those crummy height-fields. So you can have overhangs.
• Universally deformable terrain: you can dig anywhere and not just at designated spots.
• Tunnelling! Yes - you can dig your own tunnel.
• Soil mixing. You can dig up grey coloured dirt in the west, and deposit it on a brown coloured sediment in the east.
• Near infinite size. I bound the height and depth (Z) of the plane. But in the long/lat (X/Y) directions, you can drive near infinitely far. And deform the terrain at any place. Distances are only limited by MAX_INT and the size of your disk, because any modifications you do to the terrain are stored to disk.
• Procedural definition of the virgin grounds. I only store disturbances of the virgin ground. So you can dig a hole, then drive 8 hrs going in any direction, and drive 8 hrs back to the original location. Your hole in the ground will still be there! (This is a big thing!)
• Tracing back your steps, BTW, is easy. Because while driving, depressions are made in the soil which are permanent. They will still be there, even after 100s of hrs of play. Everything persists.

I think this technology is pretty unique and not found in any other game. The basic tech is all implemented, and nearly good enough. What is not there at all, is game-play. Wonderful game technology is one thing. Making a interesting, fun to play game is another. There are some routes I could take w.r.t. the game-play:

• Make it into an arcade style game with a lot of KATCHING! noises, and bright graphics every time you dig up a gem from the earth.
• Do it like the original Little Crane game: break up the gameplay in a number of puzzle-like levels with simple goals. Digging for treasure, unearthing a temple, burying an item, digging a tunnel, building a dam and such, could all be simple objectives in such a game.
• Make a full blown gold-mining simulator. Process earth by moving it into a trommel.
• Make a full blown gold-mining simulator plus economic sim: borrow money from bank, buy claims, buy diesel, etc.
• Make a full blown gold-mining simulator MMO. Buy and sell claims online. Bid for scarce resources (land) against other players.

The smaller the scope, the higher chance of succeeding of course, so I should avoid the latter ones.

Things I am doing at this moment include added more vehicles, like dump truck and excavator to the simulation. I also have to trace a bug where soil simulation goes hay wire at negative world coordinates. As my world is procedurally defined, I could cheat and spawn all action at large positive coordinates, but that feels wrong.

Developing for Oculus Rift DK2

I've purchased an Oculus Rift Development Kit 2. In a sense it feels like going back to my thirties. Much of my professional career was in Virtual Reality. I can't remember for how long exactly, but I think it was for 8 years or so, that I developed software and ran VR projects for SARA's CAVE. See below for a picture or me, mining genomics data that we visualized for Johnson&Johnson.

Since 2007, my career has been in Video Games. Even though I had been making games since 1982, it took me 25 years of hobby game development before I decided to do this for a living. And since 2010 I do this independently as a private enterprise. Back to 2014: my two careers have crossed, and I find myself actually developing Games for Virtual Reality. A younger me would have labeled this as heaven, but the years at SARA have made me cautious about the adoption rate of VR. This current VR revival could be another one that is destined to go out like a candle.

This web page will function as a development log. I intend to document peculiarities, problems and solutions that are bound to pop up during DK2 development. If you just want to play my VR game, download The Little Plane That Could.

Windows Driver issues

• When using the 'Direct' Rift Display Mode, I get extreme chromatic shifts. The different channels R/G/B are rendered all over the place, not converging what so ever. 'Extended Desktop' display mode works better.
• The SDK precompiled example runs badly, the jitter is horrible and is only alleviated a bit if I toggle multi sampling. It's hard to say which mode (ON or OFF) reduces jitter, because both look exactly the same, with the same level of aliasing.

Development under Windows

• After installing windows runtime and sdk, the latest firmware can be flashed to the device.
• The SDK example 'Oculus Room Tiny' is intended as the minimalistic code to base your first VR app on. It comes with a Visual Studio 2013 solution. Unfortunately this does not build out of the box. But what is worse: it is a D3D app, and not an OpenGL based app. The SDK seems to support both, but unfortunately the sample is in D3D only. Bummer!
• Building Oculus Room Tiny yields a: Cannot open include file: 'AtlBase.h'
• Linking the sample also fails: fatal error LNK1104: cannot open file 'atls.lib'
• To fix these compiler and linker errors, you need to install a Windows Driver Kit, as described on Stack Overflow.
• If you want to link your own app against libOVR, you need to add these to the linker input: libovr.lib (libovrd.lib for Debug), ws2_32.lib and winmm.lib.
• The Rift display mode (Extended Desktop vs Direct) seems to mess with OpenGL context creation. When 'Extended Desktop' is enabled, SDL_GL_CreateContext() can create a 3.2 Core profile context. If I ask for a 3.2 Core profile when the mode is set to 'Direct', then SDL_GL_CreateContext() crashes with an access violation at address 0.

Development under GNU/Linux

• Let's start with some good news: Oculus intends to release DK2 SDKs for Windows, OSX and Linux. The bad news: so far no Linux SDK for the DK2 has appeared. It was labeled as 'soon' but has been delayed quite a bit now.

General Development issues

• You can create the projection matrix for each eye with a call to ovrMatrix4f_Projection() but you need to transpose the result before using.
• You can build the view matrix for each eye using the eyePose from ovrHmd_GetEyePose(). Strangely enough you still need to shift the position of the eye with the intra occular distance. Like the project matrix, the view matrix need transposing as well.