Forums » Help » Box2D vs SVG vs Bitmap Collision?

I am trying to make a worms or tanks like game. In the game when the player shoots the ground it creates a crater, now to detect collision should I use Bitmap Collision aka pixel perfect collision, or SVG, or should I use Box2D (all geometry), or a combination of Box2d with pixelperfect... what do you recommend? Can you point me in any direction?

Box2D. SVG is still early with HTML5, and pixel perfect is too costly with Javascript. You may want to try the Box2D collision plugin I wrote.

I saw pixel perfect stuff done in JS 5 years ago and it was perfectly playable then, just there's no ready-made solution for it. It really depends what you want and whether you're prepared to implement it yourself, or rely on external toolkits with their respective quirks.

Do you have a link?

It was a direct clone of Lemmings, complete with original graphics. It was originally posted back years ago but was since removed due to copyright violation, though a quick Google search reveals http://www.elizium.nu/scripts/lemmings/ as a place that runs the code.

I first came across this in 2006, but discussion on the Talk page for Lemmings suggests it's actually nearer to 2003 that this came out.

Really, it's not that surprising that it's not that hard to do, imagine for a moment that you get the context of a canvas then getImageData() on it, you're getting an array of 4 numbers for every single pixel in the canvas... even on a 640x480 canvas, no browser sweats in exposing that array of (640x480x4 =) 1.2 million numbers, so really with a little ingenuity it's not that hard to imagine (said author of DHTML Lemmings was not only fudging pixel drawing with divs but handling level data in specialised RLE strings)

Bottom line, like most things: if you want a ready made solution for something, you're probably out of luck, but put a little imagination in and you can achieve anything.

Arantor do you think it's possible to:

Have a 2 color PNG image in canvas, Black means ground, white means air.
If a projectile has been launched, sample the 40 some pixels that surround the projectile every frame (60fps) and check to see if any of those pixels is black if it is then collision is true. can you sample using getImageData?

If so I can combine that with globalCompositeOperation and after I have a collision subtract from the ground.

Theoretically yes. Actually, earlier I was mulling over the exact method I might use to approach it myself, to be honest, as a result of this very sort of discussion.


The problem isn't whether it can be done, merely the logistics and practicality of doing it. First of all, stop thinking of it as a PNG, because it isn't. The moment you load it into a canvas it stops being a PNG in any real sense, it's a true 32bpp bitmap.

When you call for getImageData on the 2D context of a canvas, you don't get a nice pretty 2D map array. You get a single massive 1D array, where the first element is the R component of the first pixel, the second element is the G component of the first pixel, the third the B component, and the fourth is the alpha.

Now rinse and repeat for every pixel. So the aforementioned 640x480 image is a sequential array of 1228800 elements. It's up to you to perform the x,y conversion to the elements in the array you want and query them.

Doing it isn't as bad as it sounds, provided that you remember it is that (or write a nice wrapper function), and that you need to be careful about keeping hold of that separate canvas as a separate canvas.

Having the canvas do operations for you is not necessarily any more convenient, especially since you've got to replicate that operation twice - and make the mathematics pixel perfect, so that if there is a circular crater, the exact same pixels are removed from the collision map as they are in the drawn playfield.

In fact, were I to attempt it, that's not how I'd go about it. I'd still have the secondary canvas, of course, but that would be the actual level itself - sans any parallax background. It would be all the terrain, with any remaining area being transparent. I'd perform the same lookup, to check for collision, but when it came time to explode a weapon, I'd do the explosion directly on the one unified map itself.

Wait...you don't think incrementing through a 1.2 million element array isn't expensive? Collision detection is not an O(n) algorithm. First you need to do the broadphase testing done by ig.game.checkEntities(), and then you need to do the nitty-gritty Per-Pixel by overriding ig.Entity.touches(). I think it's possible, but easy? No. @ 60 fps? ...Maybe.

Jonathan, yes, that's the basic algorithm.

Wait...you don't think incrementing through a 1.2 million element array isn't expensive?

I didn't say it wasn't expensive. I said it was doable, as proven by the link I mentioned, which does basically the same thing but with strings (which has its own complications)

And you don't have to iterate over every element, that WOULD be unnecessarily expensive. But remember if you call getImageData, that's what you get. The browsers don't even seem to sweat doing it (because it should be a memory mapped operation internally to perform)

You already know the entity's position, it's not that hard to calculate the positions you need to check and look them up, which means you're doing far fewer calculations than you think you might otherwise need to do.

Well you dont have to sample everything just the data around your projectile. so it because a lot less expensive right there, take a circle for example. that's like 360 pixels to check at 60 fps, yes please.

It's not even that, depending on what you're doing, you can be smarter than that.

If you're detecting missile to terrain, it's nearer to 4 points to check rather than 360 because you know its velocity, its angle and where it's going to go next.

If you're detecting missile to entity, it's straightforward entity-entity collision.

If you're detecting explosion to entity, check the existing entity list and calculate the distance between the entity and where you are exploding (essentially apply Entity.distanceTo but with absolute coordinates rather than an entity, which is straightforward Pythogorean formula stuff) and detect whether that's in the blast radius or not.

There's all sorts of ways to do it, you just have to get a bit more clever about how you do it, and remember: folks were doing this stuff twenty years ago on machines with a fraction of the power we have. Ask yourself, how did they do it?

Where does the collision code start in the lemmings source?

It's been 5 years since I last looked at it, I have no idea.

that has the collision logic: http://www.elizium.nu/scripts/lemmings/js/animate.js
=============================================================


Ok here is the biggest question of all:
knowing what the project I have in front of me entails (I have to change collision behavior, mapping behavior, entity behavior etc...) would you do this project using impact.js or just vanilla javascript using homebrewed custom frameworks etc... is there enough in impact.js that still is worth paying $90 for knowing you would have to rewrite some of it's core functionality? If so, what is most useful?

Impact is a framework, meaning that you do not have to use all of it, indeed all the work I'm doing at present requires replacing non trivial parts of Impact with custom code.

That said, yes it is worth the $99 because it deals with a great deal of other stuff for you, and on top of that, you're probably going to make other games in the future that will use more of Impact than this project.

So I wrote an Impact Per-Pixel plugin.