Pixel Perfect Collision Example

I whipped up a quick little example for making pixel perfect collisions using TimeDelta and loops. Using this method, objects traveling at extreme speeds will never miss collisions, unlike using TimeDelta by itself, but will still travel at the same speed no matter what the framerate.

Pixel Perfect Collision Example

Tell me what you all think.

Nice example! The effect is more noticable if you use a low fixed framerate eg. 15 fps - the blue object passes right through the barrier.

You could neaten the events using the 'repeat' condition instead of a loop, which keeps everything in the same event, eg:

+ Right arrow key is down

----+ Repeat 5000 / redguy('Accuracy') times

----+ Red does not overlap wall

----> Set X to .X + (TimeDelta * redguy('accuracy'))

This keeps everything inside one subevent. I don't really like the action-based loops - I'm not sure they deserve to be there - I think using condition loops is always superior. The runtime can run condition loops faster, and it keeps events in one place (it's bad for readability that 'start loop' runs the loop body somewhere else).

Also, your example doesn't take in to account if it's running too many loops - if each iteration the object is being moved less than one pixel, it is a waste of processing to check the same pixel twice.

Hehe looks like people are gonna be needing my move safely extension ported to construct. Although I wonder if it would be better to just add an action like 'move x,y pixels, stopping if you hit >>object type<<' and it would stop the object if it overlapped. Would be a lot easier for people to implement into games etc.

Hehe looks like people are gonna be needing my move safely extension ported to construct. Although I wonder if it would be better to just add an action like 'move x,y pixels, stopping if you hit >>object type<<' and it would stop the object if it overlapped. Would be a lot easier for people to implement into games etc.

And maybe it could have a callback-style condition too? 'Move x,y pixels stopping if condition A is true' where condition A would be a function. That would make it very flexible... no, wait, is it possible for extensions to rely other extensions, for example, function object?

Are distance/proximity calculations a cheap way for doing collision detections. And How about distance based acuracy?

That's a good idea, Ashley. It certainly helps to condense the events.

Nice, this works with 1x1 sprites at 9999 speed. What kind of preformance hit do you get from using this will all your movement events? And since this was posted a while ago is this now obsolete?

Man, I almost forgot I made this. The performance hit really depends on how many objects you're using this method on and what the accuracy level is. An accuracy level of 256 has a minimum effect on performance even across 100 objects.

Hmm... Guys... I don't really get how it works.

Anyone can explain?

It breaks the distance down into smaller parts. In this case, it breaks down the 5000 pixels distance it would make within one tick into numerous parts and loops through each part, checking for collision, and stopping when it detects the collision.

I made a similar example once but instead of repeating a high number of times it just consumes a time pool.

The time pool was refilled on each frame, so you could have fixed frame rate logic (good for exact collisions) with dynamic frame rate graphics. It's somewhat similar but not exactly the same and only useful if the graphics rate stays way over the fixed logic rate.

I posted a similar thing a long time ago and people dogged it

wah

Ah well, I probably didn't do it as good as linkman does things