Non-rectangular maps?

I might be totally wrong now, so don''t take the following for granted! If so, someone please correct me

I would say that the game uses a bitmap-based map. The maps are -in some way- still rectangular, which doesn''t necessarily have to be "tile-based" (every pixel resembles what a tile in let''s say an isometric tile-based game would be).

As for the collision response between the worms and the environment: you could do a search on "pixel perfect collision detection", that might clear some things up

Hope that helped!


Indeterminatus

--si tacuisses, philosophus mansisses--

Worms:2 and Worms:Armageddon maps are lightly compressed real-time-modified bitmaps for hit detection, and several moderate-sized chunks of normal off-screen graphics for the visible terrain bitmap.

If I were to re-implement it, my collision map would have two bits per terrain pixel, stored in vertical columns instead of rows. The first bit says "solid or not", the second bit says "destroyable or not". For obvious reasons, if the first bit is set the second will also be.

Storage would column-minor for easy and fast scanning down for gravity; just increment until you reach bottom or until you hit a non-zero word, then find the non-zero by bitpair in that word. Except that I wouldn''t: I''d implement run-length compression. 2 bits for properties, and 6 (or 14) more bits for length of the run.

I''d then have a collection of probably 256x256 images, tiled together, to be a collage which the entire level map is built of. We have finite bounds of detail (infinite sea to both sides, infinite sky above, ocean level below) so we don''t need to store all that as more bitmaps, just draw it procedurally or out of small and easily tileable pieces.

Anything I missed?

Thanks a lot guys. The only thing I don''t get is what Wyrframe said about columns instead of rows and column-minor. And wouldn''t the pixel-perfect collision bog down the speed a lot, I mean checking for every pixel individually would take some time, especially with a 3x2 grid of 256x256 tiles? Well, time to hit the sack, school tomorrow

If you store the ''hit'' mask seperately with 1 bit for each pixel, then you can do pixel perfect collision detection on 64 pixels at once.
And you''d only do the collision detection along the path of the projectile(s) - not against the whole map. (give the projectile a bounding box - say its 32x32 pixels big - then you only need to do 32 checks (one per line of the projectile''s image) each time the projectile moves).

See http://www.ifm.liu.se/~ulfek/projects/2d_Collision_Detection.html
for an example of how to do multiple pixel at once collision detection.

- Wyzfen

I read the tutorial you suggested Wyzfen, but I just made me more confused, I get what your saying about bounding boxes, but the tutorial on how to do check more than one pixel at once was confusing, I don''t know C so that might be a factor, but the big formula and everything else in there isn''t very clear to me.

Hmm. Just had a look at that tutorial - it goes into details you wont really need for your game. All you really care about is the sections up to 2.3.

I originally just looked at the provided c code.

- What language do you use ?
- For now you could get by doing slower per pixel checks one at a time - making sure you use a bounding box to work out which pixels on the map to check.

- Wyzfen

As my name suggests, I use C#. Some people think it''s too slow, or not developed enough, but it works for me.

Hehe. didnt even click
Yeah, i use c# as my language of choice too. Much nicer to develop with.
I''ve been planning on converting that code over. Perhaps i should talk to the author first.

Although - you should be able to understand the code as it is

- Wyzfen