Memory management inside of the Clickteam Fusion 2.5 runtime can be a bit of a ‘grey area’. This kind of stuff goes beyond the technical aspects of just ‘designing a game’ which is why it’s a grey area. However, it doesn’t mean because you can’t see it, it doesn’t exist.
An Optimised Runtime in Fusion 2.5
The runtime is fast for a reason. That reason is, it has been optimised to run at the most maximum efficiency it possibly can and this has been worked on religiously over the years that the runtime has existed. Imagine having a bog standard basic car. Over a duration of 10 years, you can add lots of new features. Eventually, the features could start to put a lot of weight and drain on the initial engine, so you would have to optimise the features that run on the engine. That is what Clickteam have done, with the runtime being the engine and the features being just that, features (Fastloops/ForEach Loops/Physics/Animations etc.) aswell as still optimising the core engine.
So when it comes to designing your games in Fusion 2.5, you can throw what you like at it and it will try its ultimate best to render it all in line with what it is supposed to do. However, this doesn’t mean that you shouldn’t try and ‘work with’ the engine, instead of against it.
If you have for example, a big enemy boss that is 900 x 400, does it ‘really’ need to be that big? If not, downscale it before bringing it into Fusion and then import it.
If it really does, then try downscaling to 450 x 200 and then import it to Fusion and in the events, do a scale action to double the size like so…
If it’s a pixel-art game, choose performance over quality (0 in the next dialog). If it’s vector, you might get away with using Quality (1 in the next dialog) over performance.
Animations and Graphics in Fusion 2.5
Animations and graphics in Fusion 2.5 can be a bit of a touchy area, only because there are so many options and file formats supported. From bitmaps and GIFS all the way to JPEG and PNG. What is my personal recommendation? Mostly PNG. There are typically 3 types of PNG format you can use. PNG8, PNG24 or PNG32. Let’s take a look at them…
PNG8
PNG8 uses a small colour palette. So your image output will contain a lot less colour than PNG24. It is best used for images such as icons that have little to no colour. If you have any gradients, forget it. Effectively, it roughly contains up to 256 of colours in the palette.
PNG24
PNG24 is the best alternative to JPEG if you want a lossless image, that is, an image without any loss whatsoever. It effectively means there are 24 bits to a pixel. It can also hold up to 16 million colours in the palette. PNG24 is highly recommended for background objects where you can use a single colour for transparency.
PNG32
Some argue that PNG32 is not actually a type of the PNG format. We aren’t here to talk about the in-depth technicalities, however for the sake of Pete, let’s define it as it ‘is’ a type, as both Fireworks and Photoshop see them as types. PNG24 (above) is RGB and PNG32 is RGBa. What is the a? It stands for Alpha. Alpha channels are highly recommended only for character use in Fusion 2.5 (Player Character/Enemies) etc. As this is the highest and most lossless format there is available. It gives the best clarity of the image you exported and will be maintained visually in Fusion 2.5.
So in a nutshell, use either PNG24 or JPEG for your backgrounds, especially stuff the user won’t really pay attention to and use PNG32 for player animations, animations that need clarity and enemies or objects that animate or need to seriously stand out. PNG32 images use roughly 33% more memory than any other format so it’s wise to adhere to the types.
Let’s take a look at an example. The 3 images below are PNG8, PNG24 and PNG32 respectively…
The first is PNG8, which is 13.6kb.
The second is PNG24 which is 42.3kb
The third one is PNG32 with alpha which is 47.5kb
As you can see not much difference between PNG24 and 32. Colour-wise they contain the same palette count but image 3 has an Alpha channel. The first image is PNG8 which means it contains 8 bits per pixel and it has a colour palette of 256 maximum colours but only contains 64 colours. So if this was a backdrop object, I would choose PNG8 with 64 colours as it looks quite good in comparison. That was just an example.
Power of 2 for GPUs
If you use the standard runtime (no DirectX) for Windows, everything is sent to the CPU to be drawn to the screen. This means if your image is 510 x 54, it will use pretty much the amount of memory a 510 x 54 image would use. However, when you select a DirectX runtime or one of the exporter (OpenGL) these are hardware accelerated exporters, which means they rely on the GPU to draw the graphics.
The upside to this is, a GPU is much faster and optimised to handling the memory management for the graphics and super-fast at drawing the images to screen. The downside to it is, there are certain procedures that HWA routines have to do. If you send an image to the GPU that is 510 x 54, it will use the power of 2 to ‘fill’ in the rest of the image so it’s mapped eventually to: 512 x 64. So a 510 x 54 image will now use as much memory as a 512×64 image.
This is now where you have to work with the Fusion Runtime here. If you have an image that is 514 x 65, it will upscale to 1024 x 128, as it has passed the 512 mark and it has passed the 64 mark, so it upscales to the next available power of 2, thus consuming more memory.
The power of 2 works like this (for both height and width):
2,4,8,16,32,64,128,256,512,1024,2048 etc.
So in the example above, where our 514 x 65 image is taking up the memory of a 1024 x 128 image, does it really have to be those exact pixels in width and in height? If you can drop just 2 pixels off the height and off the width, the image is now using what a 512 x 64 image would use, saving a LOT of memory. You add all these factors up into all your images you have (including backgrounds/actives) and alot of memory could go to waste thus not leaving more memory free for other graphics and ultimately, bogging performance.
The second thing to note on the difference between CPU (Standard runtime) and DirectX/OpenGL (HWA Runtimes) is; on the CPU things like Backgrounds and Strings are drawn once to the screen. They stay drawn until something changes (ie: you change the text) then it redraws it. In a HWA runtime, they are redrawn every frame, even if there is no change to the text in the string.
So if you have a string object that says “Coins:” in DirectX or Mobile (OpenGL) the GPU is forced to redraw this every single frame. So if your game runs at 60 frames per second, it will try to redraw that string, 60 times per second. That’s a lot of utilization. The same applies for virtually any object in Fusion 2.5 that is visual on screen such as backdrops, actives, counters, strings and viewable list objects.
So try and cut down on usage of these objects, don’t go overboard. If it’s not needed, don’t use it. Got a string on your interface that probably won’t change? Change it to a backdrop or an active object instead. It’s much easier and faster for Fusion 2.5 to use the same image rather than a string container that could change, even though you know it won’t.
Global Values and Strings
When it comes to memory management, you don’t need to worry at all when it comes to global values and strings, or even alterable values/strings for that matter. These types of data are so tiny in comparison, memory-wise, it’s a mere drop in the ocean. So feel free to go wild with your values and strings. Memory-wise, they are nothing. The only processor usage for values and strings is just computation of expressions and math. Even then, this usage is bare minimal and quite native to the runtime.
The cost of duplicates
If you have a large (or large’ish) active object and you want to use duplicates then go ahead and do it. If you’ve already committed to the original active object, duplicates will not take up much more memory, maybe a few kilobytes. This doesn’t mean you can throw in 500 copies and expect the game to run good. The CPU/GPU still has a processing limit to redraw all of these images, 60 times per second…
System Memory Limits
Fusion 2.5 builds are 32-bit builds. This means there is a memory cap of 2gb. This is through no fault of Fusion 2.5, it’s just a design limitation outside of Fusion 2.5. However, if your game is requesting more than 2gb of memory-usage, then you really need to start doing some more trial and error with learning the ropes of optimising assets prior to loading them into Fusion 2.5.
One of the best examples I can give you is a pseudo-3D engine I worked on just a couple of years ago. I had a 3D animation rendered out at 45 frames just for the walking animation. The animation was as smooth as Michael Jackson at a Pepsi party. Then I re-rendered the same animation out of the modelling software at just 20 frames. So effectively, I skipped 1 frame for every 1 frame. To the naked eye, you couldn’t see this skip. So now I am using the same animation, with half the amount of frames and half the amount of memory and I still have the animation I wanted. Frame skipping will not be done internally by the runtime nor the GPU, however you can manually frame-skip your animation before even importing it into Fusion 2.5.
If you really want over 2gb on a 64-bit machine, there is a patcher you can download from here. There have been reports of this working from some Fusion 2.5 developers. However, I nor Clickteam offer any warranties or guarantees to this and we accept no responsibility for the download either.
Image Splitting
Is it worth it? Do you have a 3000 x 1500 background image? Yes. It is well worth splitting this image down. Cut them up and match them to a power of 2 in height and width and you are onto a winner. You probably won’t see much performance enhancement on Windows runtime (DirectX) but you will certainly see an speed enhancement for any of the exporters (Android/Flash/iOS/HTML5) etc.
Garbage Collection
How does the Fusion runtime work for managing your assets? Well, it’s quite genius actually. If Fusion 2.5 is at Frame 1 and there’s a huge graphic in Frame 2, it will only load that graphic to be drawn in Frame 2, unless you use ‘Load on Call’ and then it won’t load it at all until you call it (providing it’s not in the frame to begin with).
If you have a huge graphic in Frame 2 and then you load Frame 3, Fusion will check at the start of loading Frame 3 if any graphics from Frame 2 are used, if they are, they are kept in memory. If they aren’t, they are discarded.
The key thing to keep in mind here is, frames that are next to each other. So what does this mean? This means, you can now use this to your advantage and create a seamless and efficient loading screen before the next frame. What you need to do is, drop the big objects you use into your loading frame. This way, Fusion 2.5 will load those objects before the game frame so when your game frame loads, it’s pretty seamless.
Is the active object visible?
If you are using an active object that isn’t going to be visible on-screen (sometimes we use them as placeholders to store values) then uncheck all of these properties:
Uncheck Visible at Start, Save Background (not effective in HWA anyway), Transparent, Destroy object if too far from frame, inactive if too far from frame, use fine detection.
You are sending better management pointers to the runtime and the gpu. You are not asking it to be drawn, it doesn’t need a transparent background, it doesn’t need fine detection as it’s not colliding with anything. All of these are just little bits of optimisation, tiny optimisations but eventually add up to lessening the overhead.
What about sound effects?
Sounds are pretty much handled in the same way. If they are classed as ‘preload’ in the data elements dialog then Fusion will do just that and preload them at the start of the frame they are used in. If not, they’re not loaded.
If you have a long sound effect (ie: music as a sound file) then it’s probably best to select ‘Play from Disk’ from the data elements dialog as this will stream it straight from the disk.
The best formats to use for sounds?
Without a shadow of a doubt, MP3 and OGG are the best formats to choose. MP3 can take a raw WAVE file and compress it down to about 1/10th it’s original filesize with not much loss of quality (if any). The way MP3 compression works is, it removes parts of sounds that are not heard by the human ear. These parts of sounds (each at different khz) when stored digitally, are actually data. Data that is not needed nor required, so MP3 compression does a great job of taking the raw data it has available and stripping out a lot of parts we don’t actually need in the audio.
The downside to MP3? The legal side. MP3 over the years has had a few license revisions and whilst it’s free, it’s free only for personal use without limitations. For commercial use, you will have to pay royalty. However, if your game or app is making money, a royalty is nothing to say thanks to the developers for assisting you greatly in playing a technical role in the development of your game. To take your 100mb wav files down to 8mb is quite an achievement in itself. You can view MP3 licensing here. Unless your game sells more than 5,000 copies, you’ll be okay. After that, you’ll still be okay, just adhere to the licensing royalty. If you’re selling your game, it’s only a small fee in comparison. MP3 Licensing is no more. As of June 2017, MP3 has no restrictions and no royalties to be paid. You can freely use it in your games and applications.
The OGG audio format is probably the developers best choice. It offers either a lossy or lossless compression, the choice is yours. Does it sound better than MP3? Subjective. Personally, I say yes. The beauty about using OGG as your format of choice is, it’s absolutely free of royalty. Free of charges and free of royalty. So nothing to ever pay towards it, ever. However, if you are making good money off your game and it uses OGG and you have some to spare, it’s always a very nice gesture to make a donation.
A final note on sounds. Some exporters require that the sounds are specific formats. For example, Apple convert all sounds to WAV for the export, Android is MP3. However, you should still optimise them ready before importing into Fusion 2.5 because it will assist with keeping the filesizes down upon export.
Join the Academy Today
