Thanks, that's useful to know. Maybe I should switch to a model where the engine provides the entry point and main loop (if one is needed) and the game implements an 'app' interface.

I like the idea of the game being more in-control (it's useful on consoles where you might want to do special stuff before and in the mainloop) but for PC and mobile it would be easier to let the engine take over.

I'll have a look at how SDL does it so I can see how much pain I might be in for in future.

Will

That looks very useful.

I remember doing something on IW2 for 'modifiers' to existing ship systems where we allowed syntax like:

Code:

rifle = {
    range += 5
}

This would add 5 to whatever the parent range was. I guess that's not much easier to implement than super.range though. Maybe slightly easier to parse?

Will

The "write for Android, port to iOS" approach appeals to me as well, although my phone activities have so far been Nokia-based where C++ is easier to get at.

If you go with JNI, is the idea that you write your app in Java, and then call into C++ for e.g. the game loop, rendering, etc.? Or can you just pass control to C++ after setup and then forget about Java?

I guess what I'm saying is can you do:

Code:

javamain_or_whatever()
{
    // Create app, setup OpenGL context, other housekeeping
    ...

    // C++ takes over
    call_cpp_main(gl_context);

    // Clean up in Java after game finishes
}

   
Or does it have to be more fine-grained than that?

The reason I ask is that my app setup expects to have the main loop in C++, which works great in Windows and Qt (with some fiddling) but wouldn't be able to cope with JNI calls to render(), update(), send_input_event() etc. without some changes.

It's not that they'd be difficult changes, but if I cam avoid them, I'd prefer to.

Cheers,

Will

Finished porting Gasbags at Dawn to my 'phone! Complete with cramped 2-player and streaming music. So happy :D





Next is going back and de-kludging various bits now that I can see the shape of the thing.

Will

[edit: added some evidence!]

This is for N9, which is definitely supported despite being an evolutionary dead-end.

In a lot of ways it doesn't make sense to have one, but the hardware and OS are great and have that top-to-bottom-under-one-roof feel that Apple products have. It's also cool for development because you can flip a switch in the settings and suddenly you have an xterm icon,  sftp access and remote debugging that works :D

My tenuous excuse (apart from "oh, cool") is that 95% of the porting from windows is dealing with GCC and GLES2, and that's much the same on this phone as it is on Apple, or close enough.

Will

In situations where you do have a meaningful choice (when comparing fixed-point and floating-point arithmetic, for example) ints are good because you're forced to deal with range and precision issues, and floats are good because you don't have to. But then you might get bitten.

On the subject of 2D screen coordinates, if you're using a non-pixel-based renderer then you'll usually be talking to the HW in single-precision floats, and it can be advantageous to keep all the upstream stuff in floats as well since you'll avoid possible costly float<->int conversions.

Will

As of yesterday I have some of my C++ game library code running on my Nokia phone. Just some tests and debug output at the moment, file IO and GLES renderer next.

The interactions between qmake and QtCreator are probably a topic for the grumpy programmer room though...

Will

Code:

template<class T> class ConnectedBody : public T

That's a fun one, refer CRTP on Wikipedia for more details.

Will

That's really cool. I like the constraints on the overall shape, although it would be nice if the cavernous setting was compatible with more options so you could generate "spidery" caves.

That's awesome! Might take a while to finish though.

Just finished Shadow Planet on the 360. Not the longest game, but I loved it. Really varied puzzles and combat, and there's a great sense of physicality to the saucer controls and interacting with the world.

Now I need to try and finish the last level of Jamestown, and maybe try the new Fallout DLC.

Will

No, that makes perfect sense. Terraria-like terrain

I used PCCTS (ANTLR 1.x?) to parse the scripting language for I-War 2. Ir was a great tool at the time but it seemed like they were dropping that implementation (which was written in C and generated C or C++ IIRC) in favour of something Java-based - I guess that's what ANTLR is now?

It may be worth looking at PCCTS if you want something closer to C/C++

http://www.polhode.com/pccts.html

I thought at the time that it was an excellent tool, and although the generated code could be a bit messy you could mostly just use it without having to interact with it too much

Will

Maybe I'm missing something, but couldn't you just treat unfilled regions as "solid" and destroy into them just like you would if you had some solid patches generated by PN?

Will

Fair enough - I noted the predictability of Perlin as well. For most of the applications of random walks on this thread the space-filling-ness isn't a goal - you don't want to fill every pixel of space, since that would mean you've made one colossal cave with no features

There are approaches which can adapt random walks to cover more ground though - in my one I had some steering behaviours on the walkers to make them trend in particular directions, getting random walks with some fixed targets.

Anyway, YMMV. Be interested to see what you come up with with PN.

Will

This is truth (sort of. It doesn't actually assign a random value. It just keeps whatever value happened to be in memory)

Yes, with the caveat that in debug builds the value (if on the heap) is often filled by the runtime with something non-zero, and in release builds it's often zero. No. 1 cause of "but it works in debug" bugs is uninitialised variables!

This doesn't affect things at file scope, as Average Software points out - they are always initialised to zero if you don't initialise them yourself. In extremely marginal situations this behaviour can even be a performance issue

Will

The Nixon edit.

Harrroooooo!

These are both great. Do Jimmy Carter :D

I still don't get how you see the random walk as having performance problems. Generating one point of one octave of Perlin noise uses code similar to this:

Code:

Float PerlinNoise( const Vector& point )
{
// Make integral part
const Int i = static_cast<Int>(point.x);
const Int j = static_cast<Int>(point.y);
const Int k = static_cast<Int>(point.z);

// And thence fractional part
Vector p = point - Vector( static_cast<Float>(i), static_cast<Float>(j), static_cast<Float>(k));

// TODO: Fade fractions
Vector f = Smooth2( p );

// Hash corners
Int A = perm(i) + j;
Int AA = perm(A) + k;
Int AB = perm(A + 1) + k;
Int B = perm(i + 1) + j;
Int BA = perm(B) + k;
Int BB = perm(B + 1) + k;

//
Float AA_BA = LERP( f.x, grad(perm(AA), p + Vector( 0, 0, 0)),
grad(perm(BA), p + Vector(-1, 0, 0)) );
Float AB_BB = LERP( f.x, grad(perm(AB), p + Vector( 0,-1, 0)),
grad(perm(BB), p + Vector(-1,-1, 0)) );

Float AA_BA_AB_BB = LERP( f.y, AA_BA, AB_BB );

Float AA1_BA1 = LERP( f.x, grad(perm(AA+1), p + Vector( 0, 0,-1)),
  grad(perm(BA+1), p + Vector(-1, 0,-1)) );
Float AB1_BB1 = LERP( f.x, grad(perm(AB+1), p + Vector( 0,-1,-1)),
  grad(perm(BB+1), p + Vector(-1,-1,-1)) );

Float AA1_BA1_AB1_BB1 = LERP( f.y, AA1_BA1, AB1_BB1 );

return LERP( f.z, AA_BA_AB_BB, AA1_BA1_AB1_BB1 );
}

So you're looking at something in the region of 40 vector math ops per point per octave for one noise field, plus multiple table lookups and a bit of masking. This version is in 3D, so for 2D the compiler should optimise some of it away, and you wouldn't need to do as much linear interpolation.

For a real implementation you'd sum over several octaves. For your scenario you'd modulate same with another Perlin noise field in some way - i.e. another set of several octaves.

You can get a *lot* of random walk steps for that (handful of scalar integer ops to generate a random number, plus one increment and one read-modify-write per step.

I know when I used Perlin noise to generate the galaxy map background in Space Effort it was surprisingly slow. When I used random walks to generate caves it was surprisingly fast. I need to get those building again so I can get some legit benchmarks though.

I guess the advantage Perlin noise does have is that it's predictable - you pay the same cost per point generated, so you know how much time it'll take to fill a space. For random walks you don't really, but in practice running N iterations usually gives you a good result and you can constrain the walk to better fill space.

Will

but what advantages does your algorithm have in comparison to perlin noise?

I'm not sure it would be easy to filter Perlin noise to give the kind of connected cave that Subliminal and ChevyRay and others' "random walk" generators yield.

Because it is obviously slower, and I'm not seeing the advantage.

Have you benchmarked both methods? Perlin noise is moderately expensive to generate, especially if you need several octaves, and while random walks require many iterations to get a good result, the iterations themselves are ridiculously cheap. It may be less clear-cut than it seems.

Will

Lovely. Works much better than the previous one IMO - maybe because the background contrast is lower?

I like that there's some less traditional pixel art appearing on here - I was very taken with Swords&Sworcery's mixing of pixellated and soft/round/geometric elements.

Will