Amazon kindly delivered the Addison-Wesley guide for it yesterday and I’ve read a little of it so far. OpenGl 2.0 (ogl) had both a backward-compatible fixed pipeline and the dynamic pipeline, and applications and games used one or the other of these. OpenGL ES (egl) is aimed at the mobile market, and for good reason, only supports the dynamic pipeline.

From reading the 4-page ‘Hello Triangle’ application, it seems that the basic change from a normal fixed pipeline is that you set up a ‘program’, a vertex shader (works before gl primitives – tris, polygons – are calculated) and a fragment shader (primarly dealing with colour and shading work after the primitives and base is done). The two shaders are bound to the program. So not too formidable so far.

However, the shading language itself is mostly unintuitive due to its use of undeclared globals (certain important variables exist, that you simply just have to know what they do and what they are for.) I’m certain that with a bit more time hacking away with this, it will be more clear.

All in all, I am still reasonable confident that using egl for the graphics of what I am trying to do is a good thing, even if I have to learn it as I go

http://pastebin.com/f69317261

x y angle
0.00 3.99 0.01
0.00 3.94 0.02
0.00 3.87 0.03
0.01 3.74 0.04
0.01 3.61 0.04
0.01 3.40 0.05
0.01 3.22 0.06
0.01 2.93 0.07
0.01 2.60 0.08
0.01 2.32 0.09
….
….
2.44 -98.01 0.00
2.52 -98.01 0.00
2.57 -98.01 0.00
2.63 -98.01 0.00
2.68 -98.01 0.00
2.70 -98.01 0.00
2.73 -98.01 0.00
2.75 -98.01 0.00
2.75 -98.01 0.00

Pretty sexy, huh?

Okay, so it’s not terribly exciting. Suffice it to say that this is a test box being dropped, with a small initial impulse, just to rotate it a little and give it a little side velocity to check friction/sliding. It comes to rest at -98 which is pretty much as intended (world is 100,100 to -100,-100 with a 2 unit wide barrier round all the edges.

I want to explore how to use heat and heat transfer in this game. My current thinking for a (non-environmental) source of heat is the grapple – grapple something -> button press to heat it up.

• Some ‘ore’ will be heat-sensitive – too hot or too cold will damage it.
• Some areas will have a latent temperature
• Some level vegetation/amoebas/etc can be ignited by a hot rock
• Some areas are unstable and will explode on heat
• Areas can be blocked by ice/fire unreachable by the grapple – limited puzzle possibility

Side-effects of heat on the ship

Ideas: (hot >> AMBIENT_T >> cold)

• A hot ship leads to weaker propulsion
• A hot ship is easy to spot by IR sentry guns (see later)
• A hot ship can damage ‘ice’ ore that it grapples
• A cold ship responds slowly (delay til thrusting jets ignite)
• A cold ship can get stuck to likewise cold objects

Sentry guns

Base game type is for a person to reach a certain level of refined and stored in their base, but refined ore can be used to make gun defences to defend the base (or repair the refinery, should it be damaged.)

Gun types

• IR guns – shoots at the hottest thing it can see.
• Distract with a hot boulder, or intentionally cool the ship to pass it by
• Jet detector – shoots at the vapour created by manouvering thrusters
• Don’t use jets – grapple between moving asteroids, or fling ship past gun
• Motion detector – shoots at the fastest thing it can see
• Move very slowly….

Chipmunk

Nice lightweight 2D physics solver, based on a Euler style integration under the hood (beware of implementing springs!) Written in C, and does use C-style function callbacks which proved to be a headache for me trying to add it into a C++ framework. I’m sure it can be done, but I found it too difficult to do, with my limited C-in-C++ skillz.

The demos run well, and the collision solver seems to be very fast indeed – from reading on the forums, it uses a spacial hash mechanism to handle this, and does look very shiny indeed. However, the documentation for the library is a bit sparse, it lacks a really good helloworld, and for my needs, a little more infomation on how to inject it into a C++ program would have been handy.

Box2D

This was the inspiration for the Chipmunk library (afaik) and is a less lightweight, C++ 2D solver. I haven’t peeked under the hood of the code yet, but the fact that it uses a constant time-step suggests that it too is a Euler based solver. It boasts some nice tricks such as a ‘bullet’ flag for dynamic bodies (sweeps the area covered by fast moving objects for collision testing), resting body optimisation, option for the centre of mass to be derived from shape and density, and a built in way to attach user pointers to an object (for per-object data).

The documentation is good, the build feels solid with an excellent testsuite and helloworld examples. The final feature that showed the maturity of the library, was that there was a (fast, ~ log n) inbuilt method for returning the objects within a viewport of the world – perfect for a scrolling viewport, which I happen to need

Conclusion

Box2D has the features I need, in a well-documented enough manner that enabled me to add it to my skeleton code (C++), with the hooks I need to add in the other features I need (heat + heat conductivity).

So, I looked around for an open source, straightforward 2D solver. And what did I find? The shiny, Chipmonk library. Small, and covers all the main physics I need it to (momentum, moments and constraints) this looks ideal. The demos run smoothly enough, and it definitely looks like the prime candidate for my use. The documentation is mostly helpful, (could use some better parameter documentation though) and the demos cover a lot of what most people might need. Running code can be the best documentation after all.