Archived

This topic is now archived and is closed to further replies.

pixl

Objects and Hit procedures!

Recommended Posts

Haya! I have some techniques issues I''d like to get some help with. I''m coding a 16-bit platform game in C under Win9x using a Borland compilator. It''s in mode13. Now, I would be glad if someone could give me a piece of advice on how to make my "player object" know when he runs into an object or a wall. I''m currently using the dubbel-buffering technique and to verify wether there is an object under the "player objects" feet I check for the color in the 320*200 byte sized buffer. If the color differs from the "ground object" color, he should fall. I''m not sure wether this is a healthy way or not to do it because I''ve seen that in several platform games, ie. "Super Mario Brows 1", when the "player object" stands on the very edge of a cliff or ie. mushroom like in SMB, it tends to stay in the air till the mushroom or the cliff ends vertically. Also when it hits a wall it seems like the "player obj" apprehends this object just by the coords! So, I''ve thought of using a second buffer at the size of 320*200 bytes that holds all the coords of invisible objects that I declare by setting those coords to 1s and all other to 0s, and then use a hit algorithm based upon that buffer so that when the "player obj" encounters that coords pos it will react. Then I will just place all visible objects at those locations. This is just an idea I''ve come up with, but I''m not sure if this is the right/common technique to use, and I dont want to waste time on coding procedures that are for no use, so plz just give me some hints and advices would you ? Thnx alot. c.wenner@telia.com

Share this post


Link to post
Share on other sites
Sounds like you''re trying to collision detection and response based on image data (the pixels you mention in the secondary buffer) rather than object (geometry or shape) data. It should work, though I''ve never done it myself. It may or may not work well. It depends. I see a couple of potential problems with your approach:

1) You wouldn''t easily be able to obtain reliable information on the exact point and direction of a collision----essentially this means you wouldn''t be able to do realistic collision response. But for Mario-style collisions this is not a problem, since the main thing you want to do is either fall or not fall through the floor or ground.

2) If you intend to have non-player objects that move (e.g., say a ball that rolls along and bounces and may hit the player or vice versa), then your image-based approach will be trickier to do (since you would have to update the collision buffer every time an object moves.) But I suspect you''re not wanting to do this yet, and for now your collision buffer is generated in, say, Paint Shop Pro.

3) Your collision detection could be quite slow, depending on how many pixels you check every frame. If you were to check every pixel beneath the character it would be prohibitively slow. But this shouldn''t be too bad since you''re only checking one or two pixels under the player''s feet. You could even check (say) a third pixel at the player''s head to detect if the player''s head bumped into a platform above that prevented the player from moving forward.

So, with care, your approach should work fine.

There are, of course, other approaches to collision detection, and a simple "axis aligned bounding box" (AABB) approach could work for your game.

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

Share this post


Link to post
Share on other sites