visible collision boxes?

[mobichan]

Is it possible to display the non-fine collision rectangles that MMF uses? Also, are there any resources for making radial collision checks (ie circular collision)?

Mobichan

[xyzzy]

non-fine collision boxes are just the boundaries of the object, including any transparent borders

[SEELE]

you are able to read the extents of objects in the event editor so making a 'Hit Box'(3d term) would certainly be possible.

[Olivier]

In the object's properties under Ink Effect, if you uncheck Transparent MMF will display the transparent color as opaque. Then you'll see the object's collision box which is used by MMF when "Use fine detection" is unchecked.
As for radial collision checks, I'd create a separate round shaped active object which would act like the collision box (not really a box in this case).

[mobichan]

Thanks for the tip on the ink effect. I'll give it a go.

I already use circular object in some cases, but it is still a pixel collision check. I am assuming that the pixel collision in MMF2 is the most processor intensive method. Since radial collision is the least expensive method (in general programming), I was just curious if someone had explored that in MMF2.

[DevonV]

You could probably code it using the .NET/C# extension. The problem is it would be an evaluated event rather than a true event, and might slow the engine down even more.

Basically, turn off fine collision detection for all square or rectangular actives (that is, those who's graphics and perfect or near perfect squares or rectangles), and for any actives that you do not check collisions for. You only need the pixel-fine checks on round or irregularly shaped things that you care about the collisions for.

[SEELE]

The Reason radial collisions are quicker is because there is no actual pixel testing... the positions are evaluated into distance and if the distance is smaller then a set number the collision is detected.

however this is slow until it is optimized, for example if we use the generic trig for distance;
D=sqr(x2-x1) pow 2 + (y2-y1) pow 2)

you can see that if the distance calculation took place in the lower right hand of a frame the computer would have to evaluate the square root of a massive number and that is where things slow down...

you can counteract this with things like x1=max(x1,x2)-min(x1,x2) x2=0

It should also be noted that you can remove the sqr argument completely as long as your radius is not to dynamic for example if your player always had a radial collision size of 10 you could remove the sqr function and simply compare your distance to 10'2 (100).


Srry for writing an SA on your post, but you should be set for life as far as radial collisions go :grin:

[mobichan]

Thanks. I'll give it a try.

I also saw in the wiki that if 2 types of collision are present (fine collision and box collision) that the fine collision will be used on both objects. Is that always the case as long as one of the objects being compared is set to fine collision? Or is it based on the object doing the testing (ie, the first object in the argument)?

What I am trying to determine is if having ANY objects that use fine collision will negate the optimized use of the other types of collision. Meaning, is it pointless to mix collision types, since having fine collision on even one object will force all box collison to use fine anyway? ...exhale.

Mobichan

[SEELE]

No.