Original Article Location: https://stuartspixelgames.com/2014/05/05/how-to-optimize-your-fusion-game/

My early projects ran very slow on mobile. I used these techniques in my game The Nodus to speed things up, getting a smooth 60fps. I’m going to teach you Fusion developers how to do the same.

NOTE: You do not have to do all of these things in each project in Fusion. These are simply ways that you can make a game run faster if you are experiencing performance issues. This is most likely to occur in mobile games that have lots of onscreen action and object creation. For something like a puzzle game, there should likely be no problems. Take this as a, “If you need it, it’s here” sort of guide.

Before reading this article it helps to understand what we mean when we use the word “optimise”. To optimise your game means to make sure it runs at it’s best, possible performance. There are a few key areas that will affect this more than others:

• The size of the game
• The size of files within the game
• The physical size of graphical objects
• Calculations

When your game runs, it is set to run at a consistent frame rate, eg 60 frames per second, or 60fps. That means your game will attempt to process everything you’ve told it to do, 60 times per second. What we want to do is limit how much the computer has to do every frame, every second, which in turn will speed up your game. This guide will cover that process.

In my experience, Active Objects and graphics are usually the biggest cause of slow Fusion games. Creating objects at run time is a big one that uses a lot of memory. The more objects you create at one time, the more memory you are using up. The bigger the objects, the more memory you use.

A very good solution is to create a pool of the objects that you wish to reuse. For example, say you wish to create a fireworks particle effect. You would create the necessary number of particles at the start of the level, and then when you need to use them, you move their position to use them, instead of creating new particle objects.

Any time you are creating objects or particles at run time, especially lots of objects, consider if it might not be better to pre-create them at the start of the level off-screen to use them later. At some point there might be a trade off though for how many objects you have offscreen, because each object uses up memory. This will be a case by case scenario that you might just have to test.

Active Objects

• You can only have 20,000 on-screen objects at one time.
• Each object uses up memory. The more objects you have, the more memory that will take.
• It’s easy to forget how many objects are created with an event, eg. If Value A = 1, Create Object. If you don’t tell the event to stop creating more objects after the first is created, it could very easily start creating 60 objects every second. Check for little things like that.
• Don’t forget to delete objects that are not being used, unless they are going to be re-used.

Resolution

• It is best to make the game at the lowest resolution possible and let Fusion scale the game up at run-time.
• If you designed graphics at 270 x 480 but want the game to run at full HD, then create the game at 270 x 480 and let Fusion scale it up at run-time.
• The Nodus scales up dramatically at run time without losing any quality

Images

• Crop images of unnecessary transparent space. Transparent areas use memory even though there’s no graphics
• Use images with sizes at the power of 2, eg, 2, 4, 8, 16, etc. The software draws invisible boxes around objects in multiplies of powers of 2 – if the image is 9 pixels, there will be a box 16 pixels, wasting memory
• If an image is a large, solid colour, you can optimize by creating it at the smallest size possible in accordance with the powers of 2 rule, then scale it up at run-time in the Event Editor. This can save lots of memory
• The larger the object is, in pixels, the more memory (RAM) it uses up.
• If you load an image in at a smaller size and scale it up at runtime, it uses the amount of memory as the smaller size (or so I’m told). So a 100×100 image scaled up to 400×400 will still use the same amount of RAM as an image at 100×100 pixels.
• If an image is really large, consider if it can be broken up into smaller sections. Eg, if you have a long background image, can you cut it up into several chunks that fit in to better powers of 2? This would save lots of memory
• Alpha channels drain memory like a vampire. Use Transp. Color in the Animation Editor

Remember that when a game runs, the device attempts to read and calculate every line of code, 60 times per second. Now, the amount of lines of code isn’t necessarily as important as what the code is doing. One of the biggest drain on computers is when it has to perform calculations, like checking collisions, running loops, calculating physics, etc. By limiting the amount of calculations the computer has to perform, per frame, per second, you are requiring the computer to do less, which speeds up your game. The simplest way to do that is deactivating groups that aren’t necessary at that particular moment in time.

Code within inactive groups will not be read at run-time, until they become active, which speeds up your game. The more code you can deactivate when it’s not used, the less calculations the computer has to do every second.

• Think of what event should trigger the group being activated, eg a key press – often the more events you can fit inside an inactive group, the better
• Having the player moment group deactivated until you press a key is a good way to limit code. Since the player won’t be moving if you’re not pressing a key, the computer doesn’t need to check those lines of code, speeding up your game now that it doesn’t have to
• Deactivate the group as soon as it’s not in use. Most of the time I put an event at the bottom of the group that says “On group activation > Deactivate this group” but on a keyboard movement group, I’d deactivate it when the key was released
• Look at your code and ask yourself, could I optimize it any further by splitting up the code into more inactive groups? Eg, you might put all of your keyboard movements into a single group that activates when you press any key, but it would be better if you had 1 main group for keyboard movements that activates on a keypress, then several sub groups that activate separately for each individual key press, eg left, right, up, down

Example:

• Group your platform objects under an {obstacle} group qualifier, and have all of the code to do with collisions with platforms in an inactive group. Then you have the group activate only when the player is colliding with the {obstacle} group object. That way, if the player is in the air, that code’s not being read. 

• Use conditions to limit what is being scoped. e.g By checking if “the number of objects is greater than 0” when scoping, this stops the other conditions being checked if that particular object isn’t thereNumber of (“Active”)>0
  +Another Condition (“Active”)
  +Another Condition (“Active”)”If number of {particles} greater than 0 > do this” condition.Otherwise, Fusion can waste a lot of memory checking for things when it doesn’t have to.

• Avoid the timer where possible. If a game lags, timers compound the issue. Make custom timers with variables instead

Be wary of using the always event. Always means Fusion attempts to run that line of code every frame, every second, so at 50fps, that line of code is run 50  times per second. If you need to use it, that’s fine, just be aware of how it behaves and make sure it’s the best way to achieve your result.

• Avoid overlap conditions because they use more memory than straight collision detection

• The PMO object is a great alternative to fastloop movements for side scrollers.

• By putting collision detection within inactive groups and only activating the groups when collisions occur, you can save a lot of memory
• Fine collision detection uses a lot of memory. Use alternatives if possible

The bigger an assets files size, like music files, the slower the game will run because it has to hold it in memory. To use MP3’s you may have have to pay royalty fees, but you can convert a WAV into an OGG file with the free program Audacity. OGG’s are free and much smaller than WAV’s.You should be able to use them on Android or iOS as well as PC.

• Fastloops can chew up a lot of memory and slow down mobile or Flash games (or at least they used to, it’s supposedly better now). It’s best to use alternative solutions where possible.
• A good platform movement alternative to fastloop movements is the PMO object
• One alternative is the ‘For Each’ loop. This is much faster than fastloops.
• If you can’t use the ‘For Each’ loop, try not using loops at all. Be creative: there’s almost always a solution.

It’s the ‘On Loop’ command that causes slowdown. You can reduce slowdown by having all “On Loop” conditions inside an inactive group, and only activate the groups when the fastloops run, then deactivate it when it’s not in use again. When an ‘On Loop’ condition is read, Fusion will check all of the other ‘On Loop’ conditions and events in your game before running the loop or doing anything else. And it does this for every single ‘On Loop’ command. By putting them inside inactive groups, Fusion won’t read them until they’re needed, because Fusion won’t read anything inside an inactive group.

It is common practice to keep active objects or counters off-screen to store variables. If you make them invisible by unticking ‘visible at start’, you will use less memory

• Text, as in strings and the text object, can cause slow downs if they change or update regularly at runtime. If they don’t change, then they’re fine.
• Use bitmap counters instead where possible, as they are much faster – bitmap as in images, like the standard 0-9 counter object.

• Ink effects can cause a lot of slow down, especially for mobile or web games

Two of the following settings I have labelled ‘Last Resort’. They modify a projects colours. They are not necessary, and may throw off your graphics original vibe, but if you have tried all else and still need to squeeze out some performance, changing them can make a big difference.

• Open GL 1.1 is ideal for Android
• V-sync recommended for smooth graphics
• 60 fps (less can cause stuttering)
• Enable “Wake_Lock” under the permissions to help keep the phone backlight on and have the Android object in the frame. Then in event editor, “Start of frame: Android Object –> Start sleep prevention”
• Direct3d 9 – it allows the GPU to help the CPU to do processing. ‘Standard’ only uses the CPU, and may slow games down.
• Use Colour Reduction in the iPhone or Android property settings under Image Compression – last resort
• 32,000 colours is much faster than 16 million (ideal for mobile) – last resort