This is a good blog post about optimisation of fusion games. Lots of small things that atleast I didnt think about
Thanks for sharing, a very good article!
We're currently dealing with this problem as well.
If you're activating and deactivating event groups; you can afford to untick the boxes which says "Active when frame starts", which seems to help us a bit.
Not sure if this actually changes anything but setting the active objects to invisible when out of view, and unticking the box "Visible at start" helps a little as well.
No idea what the best way to activate and deactivate events based on proximity is though, we've got a massive invisible sensor which is making our game stutter a bit.
As far as Iīm informed an object that is outside the visible frame area is auto neglected by the renderer, so it does not have to be set to be “invisible”. You have to take into account though, that every backdrop/picture/ animation frame that has actually been rendered at any time adds to your RAM usage. Iīm not sure if Fusion is very good at “releasing” RAM, when objects are not displayed anymore. To be sure all resources are liberated I would restart a frame when itīs possible in the games flow rather than running everything for infinity.
If you use an invisible detector for proximity checks it should be set to “box collision”, otherwise this can be an expensive operation. In general I would prefer checking X/Y coordinates of your objects relative to your screen focus, as itīs more flexible and probably better in case of CPU load.
Thanks a ton guys! Had no idea the debugger could cause that. Also I have spent the night applying several things mentioned here such as turning off fine detection where ever possible and redoing some events to cut down on loops. Our frame rate is pretty much perfect for the time being! You guys always save the day.
Uncheck "use fine detection" on everything you possibly can, it's in the object properties.. this gives a good boost to performance.
The author says to avoid using "always", as they take up a lot of memory. First off, I'm not convinced that they would take up memory, but rather CPU cycles. Secondly, there are some cases where using "always" is actually faster than not using it. For example:
...is likely to be faster than...Code:-always >change direction of fredFlinstone to left -lookLeft("fredFlinstone") = 0 >change direction of fredFlinstone to right
...because the first version doesn't have to bother checking the value lookLeft(fredFlinstone's) twice, but only has to check it once. (Though realistically, neither option will give you any noticeable performance difference except in very extreme circumstances)Code:-lookLeft("fredFlinstone") = 1 >change direction of fredFlinstone to left -lookLeft("fredFlinstone") = 0 >change direction of fredFlinstone to right
The author also says to "Avoid overlap conditions because they use more memory than straight collision detection". Again, I'm not convinced that memory would be the issue here, but rather CPU burden (ie. it might hurt your framerate, but not your RAM). Though I could be wrong. But if CPU burden IS the issue, then according to tests I did with VACCiNE, there is absolutely no difference.
VACCiNE (link in my sig) is quite useful to figure out stuff like this, because I built into a mechanism for easily testing the performance impact of two things at once. You can see in this post that I tested overlapping vs collisions (2000 loops per frame) and the results were identical.
Another very good thing to know is which variable types are the most efficient. Most of the inbuilt ones (globals, alterable values, etc.) are very efficient, though some of the 3rd-party ones (eg. named variable object, list object) can be many, many times slower. Tompa published a really great list of results (and the tool to reproduce them), which you can see here.
Maybe you are right. What i know for sure is that using always on iphone 5-6 gives it a good kick in the knees.
I think it depends on what actions are in the "always".
If it's something super-cheap like "set Alterable Value to 1", then I can't imagine even a phone would be bothered. And in those cases, it might be cheaper to use always rather than to force a more complex condition. But if there' more than one action, or an action that involves complex math, graphics scaling, shaders, or whatever, then yes, you should probably do your best to limit how often it gets called as much as possible.
I guess what I'm saying is that you have to take into account the conditions and the actions, because they both have a cost. And "always" is probably the cheapest of all 'conditions'.