Liero/Worms type of ground definition.

[Lachie Dazdarian]

I was wondering what kind of code/method/engine is used to code these kind of objects? I am talking about ground(terrain), or just a irregular chunk of something that can be eaten away by a projectile or some similar thingo and which is also colloidal with other objects(which are moving while this chunk is not).

So you have some ground on which this character can walk around. Now imagine a projectile creating a crater somewhere allowing for background now to be seen where the hole is and this character to walk down the crater and out of it again.

I asume that screen would be refreshed(re-drawed) in every loop so all of the stuff on the screen would be pasted over and over again.

Just give me this in a nutshell and possibilities to code it in QBasic.

[adosorken]

From what I've seen in Worms 2...the ground is indicated by a certain pixel color...aka there's a certain colour index that represents the collision. Check for this colour, you got an object. When the terrain gets schmacked with a bazooka or anything else, the resulting blast always leaves an outer ring of this colour.

I remember some games on the Commodore 64 which could just check the character memory for pixels, which was really nice. Unfortunately, we don't have such hardware conveniences here

[Agamemnus]

Sounds like your blazing ball stuff.... erm..

To reduce memory requirements, you can use this:

1) Have it tile-based
2) Have each image be able to fit on 4 or even 16 tiles, so that it's not really seen as tile based....

[red_Marvin]

Check the source of my cannons game, especially
CREATETERRAIN and UPDATEDBUF.
Might give you a clue...

[Lachie Dazdarian]

I know about Cannons Marvin but I think Cannons is too static to help me with the thing I want. And I don't think Cannons graphic refresh in every loop.

Nek, are you talking about a color not visible to a player? Somekind of hidden layer? Wonder if I could pull something like that with RelLib.

[na_th_an]

What I would do is saving a group of N colours to draw the background with. Check for those colours, and you don't need an extra layer.

[Lachie Dazdarian]

Hmm....good idea.

[toonski84]

i've always liked the idea of keeping a b/w version of your board to use for collision detection...

[adosorken]

Nek, are you talking about a color not visible to a player? Somekind of hidden layer? Wonder if I could pull something like that with RelLib.

No, the color is quite visible actually...at least it is with Worms 2. na_th_an presented a most excellent method as well...more effective than using a contact color but more planning required, naturally.

A hit-test layer can work also, but it means more memory, more drawing, and being in-sync with each other. None of that is really all that difficult to do though.

Now you got the old wheels turning, man...I think I might implement some kind of engine like this when I get some free time (TBN and QBNZ's compo come first though...).

[relsoft]

You could also use a Hit-test layer using only a single layer for both your collision detection and your GFX.

ie.

Draw the Hit-test layer first
check for collision
draw the gfx in the same layer

its not that slow as I've used it in FJ.

30 FPS/150 sprites/puredos/one emslayer/pixelperfect collsion/486 dx/66mhz/no sound.

At least on the preAAP version. ;*)