New feature request: Low resolution collision test flag
I wonder if it would be possible to add a new flag to MMF specifically for iOS, Android etc called 'Low resolution collisions' along with a resolution factor setting?
In my game I tried placing in a rotating active object that was a specific shape that the player had to avoid. This works fine in Windows but on iOS, including iPad2/iTouch 4th Gen devices, the frame rate dropped to around 30FPS when the player and the rotated object were in proximity of each other. The rotating object is quite large, 256x256 but even making it smaller or breaking up into several active objects didn't help. I also tried after the recent optimisations but it was more or less the same.
I understand why performance takes this hit and I now have lots of smaller active objects that don't rotate themselves, but move in a rotating path around the centre point to make the same shapes I wanted. This method is nice and quick and achieves what I want but at the expense of how it looks.
I was wondering if some performance can be clawed back at the expense of accuracy by offering a low resolution collision option?
My thinking is if you choose to tick this option on an active object, any collision tests that involve this object would be done with a smaller collision mask resolution. For example, if I have a 256x256 object that is rotating, MMF by default has to create a mask in memory that is a minimum of 256x256 in size but most of the time will be bigger as the object rotates before testing if a collision has occurred. With the flag on and the resolution set to 1/2, the size comes down to upwards from 128x128 and the collision accuracy is still good. Even if the resolution factor is set to 1/4 the collision accuracy would still be pretty good but the size of the object for collision testing goes down to around the 64x64 size. It would mean that all objects that are affected by the low resolution test would need to be scaled down do the performance boost could be significant with an acceptable trade off on accuracy.
This would of course be an optional setting if it could be implemented.