Thoughts on AS Hit Testing

[SeiferTim]

I was playing McGiver's Footer, and noticed something that I had noticed before, elsewhere, but that I never really thought about:

When making games in flash, you usually put some type of HitTest code when Object A Touches Obejct B.

And if you have an object moving, you generally say to move "_x+VarToMoveBy"
Or whatever.
And the Higher: "VarToMoveBy" is, the faster the object moves, basically the bigger the steps.
But the problem is, if the step is too big, it might step over the object your trying to hit-test, or go much further than it should before registering a hitTest.
IN the footer, I noticed that if you fire a missle at high speed, it will sometimes leave part of the wall closest to you, before making a hole, looking like the bullet 'missed' the first part of the wall, and then blew up the inside... I hope I make some kind of sense...
so I was thinking... what if, instead of having the moving object determine the hit-test, why not make a 'tracer' object, or line...
So that, if I'm firing a bullet, and it's going to go up, and come back down in an arch, and hit a wall and explode, I could have the computer draw an imaginary/invisible line in the path the object is going to take, and then find out where the bullet is going to hit, then have the bullet follow the path, and perform the correct animation.

It may not make a big deal here, and in some games, perhaps it won't work properly, without a few modifications, but does anyone have any other thoughts/ideas to add to this? Is it feasable? Worthwhile? Or am I just thinking too hard again?
:red: <- Brain Overheating... ;)

[Marz]

Some of your ideas are very valid.. But I'll explain to you my "cough" secret way of teaching flash how.. NOT to overlook those huge steps :) And a couple of other ideas and pointers to help you out..

In any flash game.. Optimization is the key to success.. You could have a graphically wesome game that hitTest perfect dynamic physics.. But if the playing speed is only 12 fps... It's going to suck... So... You have to cut the amount of calculations your computer does.

Have multiple movement paths and multiple hitTest per frame...

onEnterFrame...

hitTest one..
move ball.....
hitTest two..
move ball.....
hitTest three
move ball.....

end enterFrame

This has a couple of more operations.. But you can make the steps smaller... say.. 6 px / frame you could split up into 2 px amounts.....

There are other methods too.. But describing them would take me an incredible amount of time.

[SeiferTim]

So move it a little bit at a time, then check in one frame?
Like say: (and I know my AS is crappy right now)


numA = disPerFrame / 5;
numB = disPerFrame / numA;
for (i=0;i<numB;i++) {
moveBall(numA);
HitTest;
}


I think I pulled that off okay... but can you see what I'm trying to do? :P

[flash4food]

i think that a solution could be higher framerates and lower speeds, to emulate the same speed, but with more hitTests in between

[The Brown Cow]

Or you can do it with math...

Find the equations of the vectors of both objects, then find the point of intersection. Next, figure out how long it will take until the objects reach that point: If it is less than 1 frame, a collision will occur that frame.

That's frame-independent collision detection... Kinda confusing, and a bit more processor-intensive, but it works fine as a solution to the problem.

[SeiferTim]

That's kind of what I was trying to get at to begin with, but I think Marz's 'secret' would work more fluently... :)

[junahu]

You could have the object start to move only after it knows when and where it will hit. Slow down during the calculation stage would be undetectable since there is no movement yet to guage it with. This would work great with turn based games that need accurate hitesting.

[Johnny64]

Originally posted by Marz
Some of your ideas are very valid.. But I'll explain to you my "cough" secret way of teaching flash how.. NOT to overlook those huge steps :) And a couple of other ideas and pointers to help you out..

In any flash game.. Optimization is the key to success.. You could have a graphically wesome game that hitTest perfect dynamic physics.. But if the playing speed is only 12 fps... It's going to suck... So... You have to cut the amount of calculations your computer does.

Have multiple movement paths and multiple hitTest per frame...

onEnterFrame...

hitTest one..
move ball.....
hitTest two..
move ball.....
hitTest three
move ball.....

end enterFrame

This has a couple of more operations.. But you can make the steps smaller... say.. 6 px / frame you could split up into 2 px amounts.....

There are other methods too.. But describing them would take me an incredible amount of time.

I know you know what your talking about so I'm proberly off...but what your saying there is to have more hitTests in a frame! Is that Optimization?

[pom]

I'm with the Brown Cow here, even though it only works in a line/circle collision situation. For more complex shapes, you're screwed (ie you have to use hitTest).

Concerning the triple hitTesting... I don't think so. It would have to be dependent on the speed of the moving thing and all. Seems too complicated to me.