Emscripten

Could I possibly get The Little Crane That Could to run in a browser window? If a modest Raspberry Pi can run it, why not a 'lowly' browser?

Inspired by a blog posting from Dirk Krause over at web3dblog, I decided to look into this. And my weapon of choice: emscripten, because I grow fonder of the C programming language each year, and have no appetite for Javascript. Hurdle number one is the outdated build instructions on linux that I found here. So in this blog posting I will document the attempt to emscripten my game.

• Instead of building llvm/clang from source, I simply install those from the ubuntu repository using 'apt-get install clang-3.2'.
• It turned out that emcc cannot find llvm-link on my system. This is because ubuntu installs it as llvm-link-3.2 so this needs fixing.
• Like clang and llvm, node.js can also be obtained from Ubuntu's repository using the 'apt-get install nodejs' command.
• With those modifications, the compiler seems to work just fine.

  $ nodejs a.out.js
  hello, world!
  

• To target ASM.JS you can use this command line:

  $ ./emcc -O1 -s ASM_JS=1 tests/hello_world.c

• There is an emar archiver tool, but combining bytecode objects into an archive gives unresolved symbols when I link against this archive. fixed by using -L. flag.
• You can put files onto a virtual file system using the --embed-file compiler flag. I've not yet figured out how to successfully use dlopen() though.

Lastly, these slides on an emscripten talk are very interesting.

OpenDE and Bullet

I would like my simulation of tracked vehicles to be faster, so it could possible run on mobile hardware. Currently, you need a modern desktop to do it, at the bare minimum my mid 2011 MacBook Air is even struggling. The 1.7 GHz Intel Core i5 struggles to run the physics simulation when a lot of dirt is active. Additionally, the integrated graphics HD 3000 struggles to render it at full screen resolution.

OpenDE lacks support for SIMD processing. However, there is another physics library, Bullet, which is streamlined for things like Neon, Cell SPU, multithreading, etc. And there is even an OpenCL version. Here I try to summarize the implications of a potential switch:

✪ Bullet builds out of box for all platforms with minimal dependencies. The dependencies it has, come included.
✪ Bullet supports cylinders, capsule, boxes, meshes: all the shapes I use with OpenDE.
✪ Bullet supports (even though it is missing from the manual) the OpenDE style hinge2 joint, crucial for my vehicle simulations.
✪ Bullet uses OpenDE's ERP (Error Reduction Parameter) and CFM (Constraint Force Mixing).
✪ Bullet comes with SIMD implementations, so should be faster in theory. It's probably still AoS though, and not SoA.
☹ Bullet has a C++ API, not a C API.
☹ Bullet lacks the concept of collision spaces to quickly ignore collisions within spaces.
☹ Bullet advices against differences in mass. OpenDE does this too, but at least I know OpenDE handles it well. You can never create a realistic vehicle simulation if your wheels have weigh the same as the chassis, no matter what you do.
☹ The bulk of my game development comes down to endless tuning of the physics parameters. Switching physics library means retuning pretty much everything.

I am still on the fence about this, and will probably hold off on a port. Maybe it would be better to use it in case I start a project from scratch.

UPDATE

Here is How Wolfire switched from OpenDE to Bullet. Also, Bullet3 seems yet to be released, and its development branch seems to still lack the C-API unfortunately.

UPDATE

I switched! Colliding and solving are both multi-threaded, which is great. Unlike ODE, Bullet does proper collision detection on convex-versus-convex. Something that tripped me up: Bullet's transformation matrices have the axes stored as columns, not as rows which I am used to.

Making a mess

I call this composition "Making a mess." It takes a bit of manoeuvring, but after 15 minutes of playing in the sand, the landscape looks considerably changed.

But the sad news is, I am still having a hard time finding a game play design for it. I've got this incredibly advanced simulation technology, but that does not make a game in its self. Should I just hide some treasure in the mud, and have the player dig it up? Maybe with a "warmer" "colder" hint system? Do I create a fancier version of the "Yukon Gold" level in The Little Crane That Could? I don't know at this moment.

Then there is the problem of hardware platform. Mobile is far too underpowered to do this. Even my second generation Mac Book Air is struggling to get fluid frame rates. So PC then? Well, steam greenlighting is not working out for me. And Amazon's app store keeps rejecting my PC build of Little Crane v1. Should I shelf it for a few years, and release it for iOS9 when cpu performance has increased another order of magnitude?

Lean Code

I guess my code is pretty lean.
$ find ~/apps/LittleCrane -name \*.cpp -exec wc -l {} \; | awk '{total = total + $1}END{print total}'
19653

Compared to these monstrous code bases. This would designate my game as a 'simple iPhone game app' according to their classification. Also, I do not believe their assessment of the code size of a modern car.

First release of Little Crane for MS Windows.

I'm happy to announce my very first release of The Little Crane That Could for MS Windows. You can try the first 6 levels for free, in the Free-To-Try distribution. If you want to play all the 25 levels in the game, I urge you to vote in the green light campaign and tell all your friends.

In case you try this out, please drop a comment in this posting. I love to see feedback on it. In case of troubles, copy the console output and paste it into a comment please.

Requirements:

• 64 bit Windows OS.
• OpenGL capabable graphics card.
• Support for GLSL (shading language) V1.1 or higher.

DOWNLOAD LINK
LCFREE-516.msi

README

The Little Crane That Could.
Free-To-Try release v5.16 for Win64.


KEYBOARD CONTROL:

CURSOR KEYS: Drive truck
Q/A:         ROTATE
W/S:         ELEVATE
E/D:         BEND
R/F:         EXTEND
T/G:         GRAPPLE

+/-:         ZOOM CAMERA
ESC:         RETURN TO MENU / QUIT


JOYSTICK CONTROL:

ONLY XBOX360 COMPATIBLE CONTROLLERS ARE SUPPORTED.
Tested with Logitech F310.

Support: http://thelittleengineerthatcould.blogspot.com/
gmail user: b.stolk

LOD, Clipping.

This week I have been adding LOD (which is pretty hard for terrains, because cracks appear between the high resolution chunks and the low resolution ones.) Easier was adding frustum clipping. Actually I simply clip against the left/right/top/bottom planes, and don't bother with near/far planes.

I also did some profiling and optimization. My old Mac Book Air with HD3000 graphics is struggling. Both the GPU and the CPU are a bit too slow, especially when a lot of dirt particles are created.

Digging it.

After the dozer, I now added a digger as well. It's already pretty convincing I think. Although it does have some difficulties with boulders getting stuck between the jaws, and then suddenly and violently get expelled from the bucket. Movements are jerky, mainly because the app would not sync to the 60fps display. Even though I used glfwSwapInterval() to make it sync. Maybe it is a GLFW3 bug.