We've all played the game 'Worms' or 'Worms: Armageddon' at one point. How is the collision detection done in that? With all the curves and even custom maps, how do they check and handle collision detection?

Probably split the map into smallish squares, 64x64 or so, and every time an object moves check its pixel mask against the current square. Since there aren't a ton of moving objects in the game at any one point this should work fairly well and scales to arbitrary map sizes.

Sorry, but what's pmasking?

Have you ever used pmask? It doesn't sound like you have. If you aren't doing that much checking then testing a 16x16 sprite vs a 64x64 square isn't that bad at all. pmask is pretty fast.

Sweet thanks for help..

you don't.. the checking around the point is enough to stop the worm if it's hitting those little pixels. using the same checking routines as you do for the walls.. ok.. i call it one point but you check points around it, so it's kinda like pmask except the sprite doesn't effect the game and a million of unnecessary pixels isn't checked which you would have to deal with in some horrible ways too.

I only played the windows version (which seemed to be different) and all i have to say is: ok, good example of a game that has uses for pmask, but for a platformer like worms or castlevania or super mario, i don't think pmask is the right decision. i mean.. sure, pmask has it's uses.. but seriusly.. animation + pmask.. i just can't get those two together.

btw, i could not control the spacecraft , and here's a screenshot:
http://www.allegro.cc/files/attachment/593302

IIRC, worms doesn't really do a bitmap <-> bitmap check, but rather just a pixel <-> pixel check. The projectiles just check the pixels they go through, and the characters to the same thing with a pixel at the center of their baseline.
There's no need to subdivide the screen, really, since all you do is a single getpixel() on each check.

pmasking won't really work, since you'd basically have to recalculate the masks each time the terrain changes. OTOH, the terrain only changes once per move, and never while any movement occurs, so it might still be a good idea.

For those who don't know how pmasking works:
When checking for a collision between two sprites, you'd normally check each pixel from bitmap 1 against the corresponding pixel of bitmap 2. For a 16x16 overlap region, that's 256 checks, each involving a getpixel() and two comparisons - far from optimal.
So what you do is for each sprite, you calculate a "pmask" - two arrays of rectangles, each exactly 1 pixel wide cq. high. Once you have these, you can do a per-scanline / per-column bounding-box check on the two bitmaps. The effort is just 2 comparisons per scanline plus 2 per column. A 16x16 overlap area then requires only 64 comparisons. For larger overlaps, the difference is even more dramatic, since the brute-force approach is O(n²), while pmask is O(n).
The downside is that pmask is inaccurate for some concave shapes (which is why for a worms game, you'd want to split your area into smaller bits to minimize concaveness), and that it has some memory overhead. Also, generating the masks is O(n²), so if your sprites change on every frame, it's more costly than brute-force.

I'd go for a check of the bounding box of moving things (worms, mines, projectiles) vs the pixel mask of the landscape.

Yes and no. Sure pmask is a lot more precise than a simple bounding box or bounding sphere, but there are other pixel-perfect (or near pixel perfect) algorithms:
- the brute-force method being one (though probably never used in anything commercial)
- brute-force on a low-res version of the sprite (e.g. an 8x8 collision box for a 32x32 sprite)
- polygonal vector-based: trace the outline, represent it as a polygon, and do vector-based collision detection on that
- multi-box, multi-sphere, and other related techniques: represent your object as a set of collision shapes which together resemble the outline of your sprite
Each of these, if done well, can look very convincing and be hard to distinguish from pmask. Also, pmask can be modified to look different: you can build the collision mask on a modified version of the sprite, giving you the extra pixel for example.

I don't know exactly how they did it, but they probably checked for collision and if it's colliding they check the surrounding area and determine the(i don't know what it's called so we will just call it reflection plane..)

example:
XOOOOOOO
XXOOOOOO
XXXOOOOO
XXXXPOOO
XXXXXOOO
XXXXXXOO
XXXXXXXO
XXXXXXXX

P is the projectile, check the pixel that it's traveling to, if speed > 0 check posX+1 for example(i will call this Xpositive), in this case it going right down at that 45degree hill(we call it 45degree hill.. from where to count the angles ins't th eproblem right now), lets say the speed is Xnegative and Ypositive (in allegro Ypositive is not up it's down.. this gets really confusing when you switch to openGL) the reflection plane could be calculated like this(this is after we have confirmed a collision): since the collision point is Xnegative and Ypositive we should now check Xnegative (by itself) and Ypositive(by itself) and in this case we se that they are solid, this means that the original reflection plane stays as it is(45degrees), then check Xpositive and Ynegative, they're not solid, so it's still 45degrees.. then check Xpostitive&Ypostive vs Xnegative&Ynegative and they're also non-solid.. so where still at 45degrees.. (what i crappy example.. since i don't get to the point of what happens when two corresponding pixels are different..) I hoped you could figure that out yourself but since you asked you probably don't..
Anyway, we have a reflection plane, since we calculated the whole thing by starting with the incoming angle we won't have to take that into account..

and then just reflect the angle and slow down the grenade or whatever.

If you're still interested after this shitty and last post of help I'm going to give for the rest of the year(or so i say) i could make an example game for you.(maybe)

yeah, figured that much..

The simple version: look a few pixels to the left, look a few pixels (or just one pixel) to the right. Determine the height of the local area for the given x value. Use the pre-algebra slope formula . Now we know the slope of the ground. We can go anywhere from here.

I feel like I plug my (poopy) games too often. In my game Zonic the Hog, I do something similar to this to determine the slope of the ground, so that I can draw the pig at an angle so he looks like he is actually running along the ground.