How do 2D platformers check collision between a sprite and the level foundation (solid ground)? Im not sure of the best way to do it, but what i''ve done is i''ve basically kept a vertical line within the solid boundaries of my level, testing each pixel of the vertical line at each update. Diagram: the sprite, and the collision line.. --------- / l / / i / / n / / e / --------- It works fine, but one problem (if u can classify it as a problem) I encounted was when u hit a wall, half the sprite is blitted over the wall like in Donkey Kong Country. Ill live with it, unless there is a way to collision detect a proper rect. I have created a RECT for each sprite which ive called rcCollision that is smaller than the actual sprite size, but its not in use because im affraid if I test for ''solidness'' at every pixel within this rcCollision rect, i will lose valuable speed efficiency, especially when there are many sprites in my level. My sprites'' positions are controlled by a Multimidia timer updating at 100 times a second, so i need it efficient.

you wouldn''t test every pixel in the rect... just test if the rect overlap.

if rect1.topcollision

if rect1.bottom>rect2.top then
collision

and so on... this is about as fast as it gets....

Great Milenko

Words Of Wisdom:
"Never Stick A Pretzel In Your Butt It Might Break Off In There."

http://www.crosswinds.net/~milenko
http://www.crosswinds.net/~pirotech

One method I used in some Java stuff I did was to create multiple bounding boxes for oddly-shaped sprites. For a circle, you would use two boxes:

{{I tried to display my idea with text graphics, but the parser turned my pipes into slashes. Imagine a circle that has two rectangles crossing in the middle, filling all of the circle except for a small portion of each corner}}

This would cover nearly every pixel of the odd shape (sans a little bit in the corners). Then you could check the overlap of every box in the object with every box in the colliding object (so with two cirles, there would be four tests (c1->box1 vs c2->box1, c1->box2 vs c2->box1, etc)

This works exactly the same as the standard box routine that Milenko was talking about, but adds some more refinement (by covering more pixels)

A pixel-by-pixel technique is pretty much nuts to try to do, so bounding boxes stop the process of reading from the horribly slow surface.

-Chris

---<<>>---
Chris Rouillard
Software Engineer
crouilla@hotmail.com

Edited by - crouilla on 2/29/00 8:10:51 PM

Yeh, but im not using RECTs for my construction.
That overlapping technique is good for testing collision of 2 rects, for example two sprites, but my construction is made up of 32x32 blocks of tiles, which each tile belonging to a 32x32 array, (not a surface), containing the pixel collision information, which is quite detailed in structure.

If I used RECT''s to test overlapping, I would get stuck in pixels. Anyway, I just wanted to know how other''s have done it. I wish I had some source code for some SuperNes games. )-;