Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » collision detection

This thread is locked; no one can reply to it. rss feed Print
collision detection
Jeff Bernard
Member #6,698
December 2005
avatar

im making a 2d side-scrolling platform game, and now im using a tile based collision detection system. but im thinking about doing some tiles that dont take up the whole square. like having ramps and stuff. but i dont know how i would do the collision detection for that. ive also got pixel movement.

the only way ive thought to be able to do this would be to make a backup bitmap of the screen and make sure the player only moves through the transparent color (255,0,255). but i dont know how one would go about checking color and stuff.

is there any way to do this, or possibly another way that may be better?

--
I thought I was wrong once, but I was mistaken.

gnolam
Member #2,030
March 2002
avatar

For the love of Dog and all that is holy, your keyboard has a shift key - use it. While you're at it, try hitting the apostrophe once in a while.

Quote:

The only way I've thought to be able to do this would be to make a backup bitmap of the screen and make sure the player only moves through the transparent color (255,0,255). But I don't know how one would go about checking color and stuff.

For each pixel you're checking, get what tile it is over and the offset relative to it, and compare it to the tile graphic. There's no need to ever check the screen buffer itself - and actually, since logic and drawing should always be separate, that's a bad idea to begin with.

As for the second part of the question:

Once you've gotten the hang of your own collision detection you can start using more advanced methods, like bitmasks. But I highly suggest inventing your own method first. It's a learning experience.

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Synapse Jumps
Member #3,073
December 2002

Something like this?

if (key[KEY_RIGHT]){
    int color = getpixel(buffer, player.x+DELTA_X, player.y);
    if (getr(color) == 255 && getg(color) == 0 && getb(color) == 255){
      //let player move;
    }

    else
      //dont' let player move;
}

That's super inefficent, but will work. If you know for sure what color depth you're in, you can make that go a lot faster by using the _getpixel* and getr/g/b* routines.

I'm sure there's a better way to do it. People do it all the time. Just search the forums, really.

Jeff Bernard
Member #6,698
December 2005
avatar

thanks a lot guys, i think ill be able to do exactly what i want now.

oh, and my keyboard doesnt have a shirt key or an ' key. ;D

--
I thought I was wrong once, but I was mistaken.

James Howard
Member #262
April 2000
avatar

That seems like a very elaborate method to do collision detection. You should very rarely need to do pixel based collisions, and especially in a tile based game. If you have sloped tiles then it should be fairly easy to calculate. For example, if you have the following tile:

+-----+
|    /|
|   /#|
|  /##|
| /###|
|/####|
+-----+

Just check at a point (x,y) inside the tile. If x >= y then there is a collision (where x right is positive, and y up is positive)

----
Check out my final year university project 'Warring States', a 3-D multiplayer RTS game:
http://warring-states.blogspot.com/

Mr. Big
Member #6,196
September 2005

"make a backup bitmap of the screen and make sure the player only moves through the transparent color"

Worms games use that technique, but for a tile-based game, it's a very bad idea.
You won't only have to make a backup bitmap of the screen, but of the whole map, because unseen entities, like enemies on the other side of the map, need collision detection too.
And besides, you won't be able to calculate realistic collision response if you use that method.
I would suggest you to place "invisible lines" where needed and do bounding box-line collision detection.
I think that's how it's done in most tile-based 2D games.

Neil Walker
Member #210
April 2000
avatar

I don't know about the tile system you employ, but I use Mappy (tilemap.co.uk) and for that you can get each tile as a bitmap, so you know a) the pixel position of your sprite, b) the pixel position of the tile, so you can do a pixel perfect collision if you want.

Quote:

my keyboard doesnt have a shirt key

American-English keyboards have a trouser key, you need a UK-English keyboard to have the shirt option.

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

Onewing
Member #6,152
August 2005
avatar

Quote:

my keyboard doesnt have a shirt key

I think we should give the shirt key to the homeless.

------------
Solo-Games.org | My Tech Blog: The Digital Helm

gnolam
Member #2,030
March 2002
avatar

Jeff Bernard said:

oh, and my keyboard doesnt have a shirt key or an ' key. ;D

"Shirt" misspelling aside, an attitude like that is not especially conducive for getting help in the future. Trying to help someone who has demonstrated an unwillingness to learn from his mistakes is bound to be futile.

James Howard said:

Just check at a point (x,y) inside the tile. If x >= y then there is a collision (where x right is positive, and y up is positive)

Then downside is that you have to go around special casing all the different kinds of tiles. A true pixel-perfect collision scheme has the advantage of being general - as soon as you've drawn a tile, it Just WorksTM.

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Jeff Bernard
Member #6,698
December 2005
avatar

I didn't think typing with the correct case and punctuation was such a big deal, geez.

My tile system is something a wrote, might not be the best, but it works. What it is is each tile has an integer value, then I've got an array of integers that says where to blit each tile. Then there is an array telling which tiles are overlays and should be blit after everything else on the screen has been drawn. There is another array, one that tells which tiles are solid so it doesn't even give the player a chance to move through them. And the last array is the one of the semi-solid tiles, or ramp-like tiles. When moving through those tiles the y coord of the player gets changed so they are always on the ground (well, unless they jump).
The tile system is pretty much only used to blit the map. After that I wouldn't really considered my game to run on a tile system.

I agree with what gnolam says about James Howard's suggestion. I'm trying to make this system as robust as possible because in the end, I'm not sure exactly what my tiles will be looking like. I'm more of programming the engine right now than anything.

Mr. Big: My collision response seems realistic enough with this method. Though I haven't implemented anything else that moves around besides the player, but I suppose I can always change things around if I need to.

--
I thought I was wrong once, but I was mistaken.

Avenger
Member #4,550
April 2004

Quote:

I didn't think typing with the correct case and punctuation was such a big deal, geez.

Well.. I think it is for your own good. A person who writes proper sounds more intelligent and nice (I'm not saying you're not), therefore has a higher probability of getting help.

Tobias Dammers
Member #2,604
August 2002
avatar

...and all those odd characters are there for a reason. Reading proper grammar is easier; and since you're asking people to help you for free, you should make it as easy for them as you can. Plus making the effort of writing proper English shows you are really interested in getting your problem solved, instead of just blurting out a pile of gibberish and excpecting others to do your work.
Back on topic:
I guess you have two workable options: Pixel-perfect and vector-based. Pixel-perfect has the advantage that, as gnolam pointed out, once you get the system running, you won't ever have to touch the code again; all odd shapes will work. The disadvantage is that after detecting a collision, the proper response is harder to judge; especially if you want nice slope sliding.
Vector-based, OTOH, means that you make a polygonal abstraction of the slopes you may encounter (can be as complex as it sounds, or as simple as a single diagonal line across the tile). If a few slope types (say, 4) are enough, you can simply hard-code the polygon representation and hand-assign them to each tile type. If you want to support arbitrary shapes, you need some sort of edge tracing algorithm; tricky. Another vector-based option is to limit yourself to slopes on the top edge of the tile; all you need then is a "left height" and a "right height" value of the tile. The collision detection and response are almost trivial once you do that, and even the tracing is doable (though not exact for each and every possible shape).

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Go to: