In Aaron Silvers’ Asteroids game he set up colliosion tests without using hitTest.
http://www.macromedia.com/desdev/mx/flash/articles/asteroids.html
What’s wrong with hitTest? Does it really slow things down?
Well if it is in an article written by someone from Macromedia, I think it is safe to say that it is true. But the key word he used is “older” he said it is processor intensive on <B>older</B> computers. So I believe it is safe to use, but people on older computers will experience lag. I like the method he used though, it is nice coding.
Well… That’s great and all… And yeah that would be an excellent method… But it’s faults appear then…
This will work… But it gives you the basic bounding box detection… If I’m correct… This will test out an area around the movieClip and give it a bounding box… And sometimes bounding boxes are insufficient like that… Which is why the hitTest method can become alot simpler to use after that…
Just thought i"d throw my 2 cents in there… For his game… it’ll work alot smoother and it won’t matter… But for a game that wants mroe precise hitTesting… I’d suggest keeping it at the hitTest level…
PEace Out
Well you are the game programmer playa, I don’t know jack about that area, so I would take your advice over my own in the situation.
Yeah…
It just dpeends on your game… If you can deal with the bounding box instead of precise… By all means… GO FOR SPEED! hehe…
But if you gotta have more precise detection… Just stick with hitTest… If you’d like… I cna make you a function so that all’s you have to do is say : testHit(object1, object2);
If you’d like… Take care Guys
I heard back from Aaron Silvers. He said that some developers he knows use a grid placement system to do hit tests where you assign coordinates to the stage and detect objects in active blocks. Has anyone here ever done something like this?
hitTest tests for an actual collision, his example is NOT testing for a collision but rather just testing for how close one object is to another, basically laying out a circular perimeter which, when passed causes the actual in game ‘collision’. This is done using the pythagorean theorem a² + b² = c², which when solving for c (the hypotenuse) gives you (in flash terms)
c = Math.sqrt(aa+bb);
he went to the trouble of simplifying Math.sqrt and Math.pow into single small non Math Object referencing function calls which was good but still through that function distance in the Math object which seems to go against that reasoning :crazy: Btw, since the individual points were being passed, a and b actually make up the difference of those points which is why pow ‘worked well’ there though I typically always make temp variables - good for reuse if you need to snag the angle with atan2 as well.
…Anywho, the point is, its a different type of collision detection which is not necessarily slower or faster, just more ‘accurate’ for what this guy wanted to accomplish. Since the asteroids are ‘round’ of sorts, this kind of collision detection is fine to use. For any circle to circle collision, its hands down THE one to use; asteroids work as well.
“Flash chews through mathematical processes very effeciently” is a crock of poo though.
grid hit detection is common for grid based games and is fairly blazingly fast in comparison to other types of collision. All it needs is to compare one objects placement in the grid with another, if they are the same, they are colliding. This isnt very accurate, especially when you complication animations to and from different grid locations, but when it boils down to it, this type of collision is like reducing your stage size to something like 10x10 then just seeing what objects are on the same spot.
Like I said this is mostly used with grid-based games where this kind of collision is most applicable and acceptable. It really depends on what you are making and how different objects interact to know what kind of collision detection is best suited.
