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.