Sorry your browser is not supported!

No code just a good idea for collision detection.

I havn't really messed with DBPro enough to know how to get it all to work yet, but from the posts that I've read collision in 2D is a tough animal to tackle.

At the moment people 'pick' colors from memory and specify that that color is impassible. Instead of doing it like that how about this...

You design your 2D level, then you design a second overlay that is two colors lets say, black and pink. Black is passible areas, pink is impassible.

You would basically have two levels that are the same. one is the level that everybody sees when they play your game and the other would be...lets call it a 'collision map' You would not be able to see this collision map.

The definatly would be faster as your arn't picking bits from a complex picture.

Basically would work like transparent, not transparent sections do in Adobe photoshop.

Your method works well for static images but most applications require collision testing of moving imagery, specifically sprites.

Interestingly the same theory still applies.

This is a process called masking which is also used for recording the screen history when an overlayed image is placed and subsequently moved. My understanding is that DBPro uses layers and has no inherent mask, and therein lies the defficiency of it's collision detection system.

I am considering writting a masking system for DBPro but as far as I can see there are two ways to tackle the problem and I cannot decide which is best.

Option One: Have a function to create masks using DBPro commands, this would be a one-off function call performed by the programmer after loading all images and would take some time to process. This would cause a delay during loading, but the results should be fast and the code easy to write using standard DB commands.

Option Two: Work out how to access DBPro display RAM which I don't think is too hard to do, and then peek the displayed image content directly. This method might be slower in runtime but would be easier for 3rd parties to implement as it would result in a one off command to use whenever collision needs to be tested. Programming this would be more complicated, but requires no pre-processing.

I believe that's the way they did the level collision in metroid fusion.

Whatever you do, don't do it my way. My way is the horrible way. Basically I have an X and Y variable for my main sprite, and then for EVERY freaking level I have to go through and say:

If X# > point1# then X# = point1#
If X# < point2# then X# = point2#
If Y# > point3# then Y# = point3#
If Y# < point4# then Y# = point4#

A major pain in the rear. Through that experience I've learned that map editors are your best friend.