Embedded detection hitbox not working with fastloops?

[EE]

Hi!

I usually do hitboxes for active objects acting as backdrops, but I just noticed that regular collision detection on those hitboxes doesn't work during fastloops, i.e when checking for a collision between a detector(active) and a hitbox(active).

At the top of my events I have my actives set up to change animation direction to the hitbox one, and at the bottom to restore the animation direction. The fastloops being called do all take place during the hitbox animation direction, but collision detection with the actives register using the mask/restored animation direction, how come?

I believe this used to work earlier, am I wrong?

Does anyone have any clue on how to solve it without using invisble doubles for collision detection?

//EE

[ChrisBurrows]

http://www.create-games.com/forum_post.asp?id=294641

[Pixelthief]

MMF2 does not update its collision mask during loops or during the event editor at all. It really only happens at the start of each frame, afaik.
This has interesting implications.

For example, when you compare "Is Object A overlapping Object B", it will test for collisions between each scoped copy of object A, one at a time, using a fresh collision detector for that A, against the pre-generated (at the start of the frame) collision mask for all Object B. So if object A had been moved around that frame, or had its animation or scaling or angle or whatever else changed, it would use its current collision data, including all those changes, as they are in that frame. However all the Object B's would use only the collision mask of what they were at the start of the frame.

It has to do with how MMF2 is optimized- if the collision mask was generated for every single collision test, it would vastly increase the amount of processing needed. So as a shortcut, it only tests compared to the mask made once per frame. I think this might include backdrops and other things, I'm not sure. Point being, the mask you test against, the data of where all the other objects are, isn't updated with positions and animations and all that jazz in the middle of frames, whereas the object that you're specifically testing (all instances of it, which are iterated through), *does* use its current data. Thus, you wind up with situations like yours, where comparing a detector (good) doesn't work on hitboxes (bad).

One way to think about it is the 'reverse duck hunt' problem. In the old NES duck hunt, when you pressed the trigger, all the screen would go black and the hit boxes for the ducks would turn white, and the sensor in the gun could tell if you were aimed at white or black. But in MMF2's system, the sensor can be updated constantly, but the collision mask- that whole screen you're looking at- doesn't "flash" and return, so you'd be looking at ducks and trees and sky, not white squares on a black frame.


But for as bad as that sounds, its done for good reason. Collision detection is one of the most expensive operations in MMF's engine, alongside read/eval loop overhead (string parsing on O(N^2) loops in particular) and the expression parser (the reason that the pythagorean theorum works faster than an optimized approximation algorithm for distance calculations). You can see this in big projects with huge obstacle backgrounds and lots of objects, where disabling "Check collisions offscreen" can make the game run a bajillion times faster

[EE]

Hmm, thanks for the info Mr.Thief, that's interesting.
I put together a simple example of the specific situation and problem if anyone wants to take a gander and maybe come up with any other good way of achieving the desired result.
Cheers!
//EE