Posted in Examples on September 3rd, 2010 by sHTiF
Indeed yet another post even if i am getting spammed by work i am still down here. Lately i was playing with an idea to create a little tank destruction game you know the one there are tons of them out there already, anyway since i used my Genome2D engine i run into a little problem very soon. Lets take a simple destructible terrain for example, player shoots a missile which hits the terrain and makes a crater then another player shoots… you get the picture the terrain is going to be pretty much devastated the problem here is to create a collision with such terrain. Since Genome2D uses Box2D for collisions it would be really hard to represent the terrain as a polygon or polygon groups and update it according to destructions. First problem is the obvious complexity and as we delve even deeper to possible scenarios its getting worse such as concave polygons, polygon separation etc.
Seemed like a dead end and not really worth the effort so i discarded Box2D or any collision engine based on primitives and went back to the roots. To detect a collision between two bitmaps which is what we want basically even when they were represented as Box2D primitives is pretty easy after all flash has this neat function hitTest and i am not talking about the DisplayObject method but about the pixel perfect BitmapData method which works like a charm. So its over, done we can play.
Nope not that fast, to check for a collision is one thing, to get a worthy feedback from it is another entirely. Lets say we threw a grenade in our little terrain scenario, it will hit the terrain obviously and we will get a positive hitTest callback however thats hardly enough, there are couple of other things we would like to know but one that is crucial is the reflection vector so we can update the grenade and bounce it off the terrain. And this is exactly the difference between one line of hitTest code and quite lot of lines that make the Pixel Collision Engine i created.
So i’ve created a little demo since i am so happy with the state it is, i was also looking for similar engines/algorithms out there which i could benchmark with my PCE and i stumbled upon CDK which is pretty neat and i am glad i didn’t find it before i started because i would be tempted to just use it. It does simply the same thing however there are some major differences. The main is that CDK can work with any display object which is then internally processed as bitmap where PCE always works with bitmaps since that was the plan. If for some reason you want to work with display objects its up to you to create the bitmap representations where CDK does it for you. CDK returns angles upon hitting an object, PCE returns vectors…
As i went over CDK i stumbled upon some really strange stuff there and if some of you use CDK or maybe even the author if he is reading this drop me a line dude and i can point out a lot of optimalizations and changes if you are still working on it.
For stats i am using Mr Doob’s great simple Stats class you sure want to check out.
Anyway thats enough of small talk, here is a simple demo with 500 particles where you can switch between the engines using SPACE or even increase/decrease the number of particles using ARROWS. Click the image to run the demo.
EDIT: I’ve got an email stating that CDK offers more when it comes to collision and response such as overlapping and color exclusion. To clear this i need to mention that PCE also offers overlapping information in the collision response without such information the physics would be hardly possible. When it comes to color exclusion nope PCE doesn’t implement this feature simply because i didn’t need it at the time but its implementable with ease and whats more there will be no major impact on the performance.
PS: Why most people prefer emailing me rather than using the comments? This way its so sad here when it comes to comments numbers ;)



