Steaming Ahead - WEEK 02

The Second week of work after the Steam Green-lighting has come and gone. So as promised, here is a weekly update on the progress towards the Steam release of The Little Crane That Could.

I'm not going to lie: this was a week of frustration. Source of the frustration was a wild goose chase to fix a shadow mapping bug. As a detour, I thought a windows port could help me solve this bug, with some OpenGL debugger tools from AMD, e.g.

So the sub-goal for the week was a windows port. So far I have been developing under GNU/Linux, and occasionally using the Mac OSX port. There are a lot of things missing in the windows world. One of them is pthreads. Fortunately, SDL includes support for platform independent threading, so I rewrote my pthread code to SDL_Thread code, which has a similar API. I am seeing really bad performance on windows though, and I am not sure what the cause of this is. It could be that SDL threads are slower than pthreads. This needs more investigation.

Other missing functionality in windows world is opendir(3), which I worked around with a temporary hack.

So did anything gameplay-related happen this week? Well, at least I can now read in modular level designs, that were created with my Little Crane World Editor. So at the very least I can build things like parking lots, or spawning-platforms, so that not everything in the world is muddy hills.

Steaming Ahead - WEEK 01

The first week of work after the Steam Green-lighting has come and gone. So as promised, here is a weekly update on the progress towards the Steam release of The Little Crane That Could.

I've spent this week on actually building a crane vehicle. The code base so far only contained a bulldozer/loader and an excavator. And now, there is an actual crane as well. The crane turret and cabin are from a model purchased at TurboSquid. The truck underneath, I modelled myself in Wings3D.

However, most of the time was spent on doing the physics sim for the truck and the crane. I'm pleased with the truck, that now has 4 axles instead of 2, and all driven. The wheel suspension is softer than the old crane I used in the mobile version of the game, and they look great. It took quite some time to get the sim stable without too much jitter, but the quality is now pretty close to shippable. So without further ado, shown below is what the new Little Crane looks like.

For next week, I want to see if I can get some actual game-play back in, probably in the form of the old basket-ball level from the mobile game version. I hope you'll follow me again in next week's progress report. Until then, I will leave you with this great shot of the truck's suspension.

Steaming Ahead - WEEK 00

Such great news, Friday 13th of February 2015: The Little Crane That Could has been green-lit, meaning my game will be published on the Steam store. Yesterday I announced that I pledge to, EACH AND EVERY WEEK, publish a progress report on my steam publication.

So without further ado, here is report 00, where I will report on the current state of the project.

There are two code bases relevant to this steam publication. There is the unified code base that is used to build the iOS, Mac, Linux, Win, Android, OUYA, GearVR versions of the game. This is what I call the Legacy Code Base (LCB). Next, there is a new code base where I have researched soil simulation, with real time terrain deformations. I will call this the Research Code Base, or RCB. The steam build will be making use of the RCB, to make it a fresh new game, with some amazing technology behind it.

Currently the RCB is a capable engine with the following features:

• Soil simulation where terrain can be scooped up, and deposited anywhere. It is a true isosurface capable of caves, overhangs and such, so is not limited to a simple height field.
• Supports an infinitely large procedural world. Only changes made to the terrain are stored to disk.
• Features a bulldozer simulation.
• Features an excavator simulation.
• Diesel-engine sound effect.
• Caterpillar track simulation that leaves depressions in the terrain.

The most notable omissions in the RCB include:

• Lack of integration with steam.
• Lack of levels, goals, gameplay.
• No crane vehicle simulation.

In the months ahead, I intend to address the crane simulation first, and will read up on steam publishing. There are some decisions to be made regarding publication, as there are:

• Will I do Steam Early Access? I'm leaning towards yes, but gameplay needs to be in place for this.
• Will I adopt any steam specific technology, as there are steam trading cards, steam big picture, etc?
• How many game levels will be part of the first release? And how much overlap with levels in the mobile game will it have?

Tune in next week to see what progress has been made. And let me leave you with the current vehicles from the RCB.

Here is a video of the excavator in action, and one of the dozer in action.

Accelerating GI computations.

So I have been developing a new game where a rocket engine Globally Illuminates its environment. It started out as an AVX2 implementation, but since then I have been pursuing other acceleration techniques. For instance, can I run the photon mapping algorithm on the GPU instead? Here are some initial results of the different approaches.

Technology: AVX2, single threaded.
OS: Linux
Device: i5-4570 CPU @ 3.20GHz.
Cores: 1
Frames per second: 51

Technology: GLSL- OpenGL3.2
OS: Linux
Device: Intel® HD Graphics 4600 GPU
Cores: ?
Frames per second: 37

Technology: GLSL- OpenGL3.2
OS: Linux
Device: ATI HD 5670 Graphics, Open Source Gallium driver.
Cores: ?
Frames per second: 60

Technology: OpenCL 1.2
OS: Linux
Device: i5-4570 CPU @ 3.20GHz.
Cores: 4
Frames per second: 38

Technology: GLSL - OpenGLES 3.0
OS: Android
Device: Adreno(TM) 420
Cores: ?
Frames per second: 10-14.
Remarks: Oscillates with a 3.5s period. Thermal throttle?

Technology: OpenCL 1.2
OS: Mac OSX
Device: i5-4278U CPU @ 2.60GHz.
Cores: 4
Frames per second: 11
Remarks: Could not handle work group sizes larger than 1.

Technology: OpenCL 1.2
OS: Mac OSX
Device: Intel Iris GPU
Cores: 40
Frames per second:-
Remarks: Apple's OpenCL compiler failed to build the OpenCL kernel source. Gave 'Parse Error' on a perfectly fine source fragment for no traceable reason.

Some conclusions I got from this: OpenCL has not been worth the effort. It takes 4 CPU cores to get to a speed that still lies significantly below the speed of my hand optimized AVX2 implementation that runs on a single core.

Apple's OpenCL seems to be in a bad shape. I could not get it to run on GPU, and running on CPU yielded a 3.5 times slower result compared to Linux.

The GLSL implementation seems promising. A dependency on ES3.1 or OpenGL 3.2 is less of a barrier than the AVX2 dependency. With some temporal caching, and reducing photon counts, it should be able to reach solid 60fps on integrated GPUs, and maybe even 60fps on future mobile CPUs.

Programming

Programming is my passion. It is the best life-time hobby I can imagine. It all got sparked in 1982 when I played Munchkin on a friend's Videopac G7000. This pacman clone blew me away, and I desperately wanted a 'game computer'. My father replied to my plea: `No we are not going to buy a game computer. We'll buy a real computer.' To which I replied: `What is a real computer?' The answer hit like a bomb: `With a real computer you can make your own games.' The rest, as the saying goes, is history. Here's an overview of the programming languages in my life in rough chronological order.

• It all started with ZX Spectrum Basic.
• Then Z80 machine language (Assembler came later!)
• Forth, using White Lightning from Oasis Software required a mental shift due to the RPN.
• Intel 8086 assembly.

Most of the programming languages I picked up were studied as part of my Computer Science degree at the University of Amsterdam:

• Pascal
• Motorola 68K assembly
• Microcode
• Scheme
• Sasl
• Fortran
• Prolog
• C
• Occam

And then in mostly in industry, I picked up:

• Postscript (stack based like Forth)
• C++
• Python
• Objective C

Currently, my favourites are C (I use a C++ compiler but try to use as little C++ features as possible) and Python.

Extraterrestrial spelæology

So my Global Illumination experiment made some more progress. The technology demo is slowly evolving into an actual game. And the hero of this game might very well be a spelunking rocket. Maybe I should call the game Spelunking Rocket? It currently has a single Google hit, so it should be easy to find online.

So what you see in the video is a rocket flying through a voxel world that is defined by a 3-octave simplex noise function. I sample one noise field to determine block/empty space, and sample another noise field to determine the hue. Notice how the rocket exhaust illuminates the scenery, both directly and indirectly via light bouncing off a wall. Also, the exhaust particles collide with the world, and act as light sources for my photon mapper.

In the left corner an instrument that combines attitude-indication (where is the rocket's nose pointing?) with a compass. Flying towards the little circle on the perimeter will make you go in the +X direction, where the first coordinate increases. The attitude indicator helps you to right the rocket, although there is also an autopilot function mapped on the gamepad that does this automatically using PID controllers.

Still to do are game play objectives. I was considering putting fuel drops in the world, and make them more rare as you move further away from launch position. Farthest voyage wins the leader board?

For technical challenges, there is still the issue of moving away from AVX2 which is not widely supported on current hardware. A possibility would be doing GPGPU. Possible APIs are OpenCL, OpenGL4.3 Compute Shaders, CUDA, Apple Metal. CUDA is too proprietary, as is Metal. OpenGL4.3 support is horrible: I don't think a single Macintosh can do this?

Rocket Engine Illumination

So I have been playing with my real time Global Illumination renderer some more. I added a particle system to model a rocket engine. The particle system is comprised of 1024 particles. And the kicker is: each and every particle is a light source that casts both direct and indirect light. For each particle, 24 photons are fired in random directions. When a photon hits a surface, a secondary photon is emitted in a diffusely reflected direction. This bounced photon creates the indirect illumination. See for instance the red and green glows that are created if the engine is close to a coloured wall.

In the video, the best demonstration of indirect light happens as very short flashes of green and red on the sides of the center block. If the engine flame is directly above the center block, its light cannot directly reach the sides. So mainly the light bouncing off the coloured walls reaches the sides, causing them to briefly flash in green or red before going bright white as the engine light shines directly upon it.

It currently runs 60fps on a single Haswell core. But I plan on multi threading the code so that I can increase the photon count. This should reduce the light flicker. The code is in AVX2 intrinsics, so it's rather incompatible with most PCs. I may have to port it to AVX or SSE at some point in time.

Next up in my GI research is integration into an actual game, preferably with rockets of course. I feel like making a GI homage to the ZX Spectrum classic JetPac.