Physics(Again)

I haven't had that much time to sit down and code away but, there were a couple things I wanted to mention.

First, multiple inheritance:  it's wonderful.  There's this idea that language features that can result in you shooting yourself in the foot are bad.  I disagree with this.  Language features don't shoot programmers' feet, programmers shoot programmers' feet.  Using a language feature is a privilege.  That feature doesn't owe you anything so if you use it without fully understanding it, too bad.

This does of course mean that if you should never use it in an environment where others may not know it or expect to see it.  As with every feature it has a time and a place, much like how you should be careful about using the ?: operation as it can result in difficult to read code.

Now, I've been shot in the foot before, I'm actually really great at it.  But if you look closely, no two bullet wounds (or at least no.. four, I'm going with four) upon my foot look the same.  And as this project is devoid of other people's feet entirely, I get to experiment.

This brings us back to MI, people have shot themselves in the foot with this before.  Some people with C-style casts and forward declarations, others with diamond inheritance and I'm sure there are many more interesting ways I just haven't run into.  This has resulted in this idea that it's dangerous.  And it is, I suppose. But, more importantly, it's versatile.  The main point I'm getting at is Policy Based Class Design which often relies on MI (and templates.)

My initial idea for the Policy Based Class Design bastardization in C# was to hide all the routing to interfaces in routing interfaces which the PhysicsEngine would inherit from.  This required that those interfaces had either a pointer to an implementation (which isn't allowed) or a function (or property) that would retrieve that pointer, allowing the functions of IBroad, for instance, to be overloaded to a simple routing to that pointer.  This isn't possible because first, interfaces can't have data members and second, properties/functions have to be public, which I don't want.  The solution would be multiple inheritance of classes but, that's not supported in C#.  For shame.

This means I'll have to do the routing within the PhysicsEngine which will cause an even greater level of coupling with implementations and a lower ease of extending.

The second thing I wanted to talk about is the first implementation: the spatial hash grid.

I had considered doing a few different Broad Phases initially, one of them being the Quad Tree which I've already done a couple time.  I settled on the spatial has grid for a few reasons.

0)  It implements all of the extension interfaces I've thought of (IBroad, ICull, IAdjacency).  It does this better than any other implementation I've thought of as each of these are very fast.  The first weeding for all 3 implementations is O(1) (hash grid cells) and the second weeding in O(n) for very low numbers of n (the number of PhysicComponents in the hash cell.)

1) It's scale-able.  The Spatial Hash Grid, perhaps more than any other implementation, scales very well.  You can configure it to use more memory and that will decrease the processing time needed (the n mentioned before will drop) or to use less memory which will increase the processing time.  This is good for an engine that will (eventually) deploy to the Vita (and ps certified smart phones) as well as the Xbox and the PC.

10) I haven't done it before.  I love learning.

Oh, numbered items, how you allow for geeky programmer jokes.

When I have a bit more time I'll discuss the spatial hash grid on it's own.  I should figure out a way to keep track of what blog topics I've promised to post about...