Okay, so I've been having some trouble with slowdown in the game I'm making, and some more trouble identifying exactly what's causing it.
I suspected it was probably one particular part of my code - about 7-8 lines - that was causing the slowdown.
I decided to test the theory by adding a "never" condition at the top of each line, but to my surprise, it made absolutely no difference to performance - I was still only getting 25fps.
I then deleted the same 7-8 lines altogether - suddenly the framerate jumps t0 50fps
I was under the impression that if you put "never" at the top of a condition list, then MMF2 wouldn't bother checking any of the other conditions, but obviously this is not the case
There were various different kinds of event, but it turned out there was just one causing the slowdown - it was a condition checking whether an active is overlapping another active. Fine collision detection on large objects is *very* slow, apparently.
Since my objects were circular anyway, I just replaced the collision detection with a simple distance check (comparing it to the radius of the object) and now the framerate is back up to 50fps, with no visible side-effects
Incidentally, I tried putting the event in a group, and disabling it (like in Pixelthief's method for making fastloops more efficient) - didn't help at all. MMF2 was obviously still evaluating all the conditions, even in the disabled group.
Originally Posted by Sketchy Incidentally, I tried putting the event in a group, and disabling it (like in Pixelthief's method for making fastloops more efficient) - didn't help at all. MMF2 was obviously still evaluating all the conditions, even in the disabled group.
That's interesting about fine collision detection on large objects and especially about the fast loop grouping technique. I'd heard of that method before and always thought it worked (without actually having tried it myself). What I heard was that it helps if you have a lot of fast loops (i.e. not the amount of loops in them, but the fast loops themselves).
I believe it does help with fastloops, but the event I was trying to disable doesn't involve them. It was just something I thought might help, but it didn't seem to.
I haven't tried testing it in a more controlled example yet though.
The collision detection problem is definitely real though. Obviously the bigger the objects, the worse it is. I tried to do destructible terrain, with a Surface object the size of the frame (2000x2000) - it was perfectly fine until I added collision detection between the surface object and an active, and then the framerate dropped to 1-2fps.
It's easy enough to test: just untick the box for "use fine detection" in the properties panel, and see if it helps at all. You should always untick that box unless you really need fine collision detection, but I doubt most people bother.
If you think about it, the number of pixels that need to be checked increases exponentially (a 500x500 square contains 100 times as many pixels as a 50x50 square) so small objects probably aren't a problem.
yeah, fine collision detection is pretty much going to be quadratic if they just do it the easy way
i'm not sure how it could be sped up on their end, unless it's possible to use quadtrees or something to represent the collision masks, so they could test chunks of the masks in many cases rather than pixels... this would end up using a fair amount of memory though
Originally Posted by Sketchy It's easy enough to test: just untick the box for "use fine detection" in the properties panel, and see if it helps at all. You should always untick that box unless you really need fine collision detection, but I doubt most people bother.
If you think about it, the number of pixels that need to be checked increases exponentially (a 500x500 square contains 100 times as many pixels as a 50x50 square) so small objects probably aren't a problem.
When I uncheck that box, I get things registering collisions many pixels outside their boundaries.
It should just use bounding-box collision detection if you disable fine collision detection.
Obviously that will mean a lot of false-positives if your objects aren't vaguely rectangular in shape.
I haven't tried it, but I suspect that bounding-box collision detection is used even if only one of the objects involved has fine collision detection disabled (possibly an old bug that has since been fixed?).
Anyway, I was just suggesting it as a way of testing how much it's affecting your game's performance, since AJJ asked.
No, me neither. Is that using an extension, and if so, which one?
What did you do to "remove them" - just use the normal "repeat while key is down" condition instead?
Originally Posted by Sketchy Incidentally, I tried putting the event in a group, and disabling it (like in Pixelthief's method for making fastloops more efficient) - didn't help at all. MMF2 was obviously still evaluating all the conditions, even in the disabled group.
This is odd. Lazy evaluation is one thing, but this is entirely inexplicable- theres should be no reason an event is making an effect while it is closed- the game is never evaluating it. I'm going to do some testing with large collision objects and see what happens
Yes, it's very strange.
I tried making a test app to see if I could reproduce the results, but it all seems to work normally - except in my game.
I can send you my game file if you're really interested - maybe I've just missed something simple (it happens ). I have another bug you might be able to help me with too, while you're at it (duplicates not doing what I want them to again)
Hmm.. that's really odd. I'd guess that it constantly checks for collisions if you have any conditions doing collision detection, regardless of whether or not you're using collision detection.
You might want to mention this on the Clickteam boards, they could figure out the problem and patch it.
When I uncheck that box, I get things registering collisions many pixels outside their boundaries.
Might be because there's empty transparent space around the sprite? It's why I love that crop button.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Advertisement
Post Reply
Edited by alastair john jack
). I have another bug you might be able to help me with too, while you're at it 
(duplicates not doing what I want them to again)
