1000 Backdrop Objects or 1 Active Object
In Clickteam Fusion 2.5 the question is still on most peoples lips even today. Do I use 1000 backdrop objects (tiles) or do I use a Single Active (or backdrop)? The answer has fluctuated so much over the years nobody knows where they stand anymore and nobody knows who to believe anymore.
Backdrop Objects in Runtimes
Back long before the Direct3D (D3D9) or even DX8 for that matter was available in Multimedia Fusion 2, everything was drawn to the screen by the CPU. That’s your computer’s core for those who are not tech savvy. The same processor that is also processing your antivirus program in the background, your Media Player that is playing your music, analysing your computer all of the time and has 200+ other processes to handle to ensure Windows runs correctly.
So Fusion used to use the CPU to draw objects to the screen. This was not a bad method. Once the CPU received the image, it stayed in memory “untouched” and was drawn to the screen just once. If however, the image was changed, then the CPU would delete the backdrop and redraw it. We all know that backdrops rarely change, so in this Standard runtime instance, backdrops are like heaven to the runtime. Draw once, never again and that equals less CPU calls.
Introducing Direct3D (D3D8/9) which used DirectX. The first hardware accelerated runtime for the Clickteam range. It actually uses DirectX and thus in turn means it uses the GPU, which is the Graphics Processing Unit (ie: your graphics card). This was a HUGE advancement in terms of performance and speed in your Clickteam Fusion 2.5 games and apps.
How did it differ from the Standard Runtime? Well in this runtime, it throws everything at the GPU (your graphics card) and leaves the processor untouched (for draw calls at least) and we all know in Game Development that speed and performance of images, animations, scrolling and lots of other stuff is important for your game. However, it does come with a bit of a downside.
Backdrops ARE Active objects
Here is the issue (the ONLY issue with HWA runtimes) backdrops have to be treated like Active objects. Granted at runtime they don’t contain values (alterable values or alterable strings) but they are shipped to the GPU to be rendered but this time, every frame. Unlike I explained above with the CPU scenario where backdrops are only drawn once to the screen (until changed) with any HWA runtime, it has to be drawn 60 times per second (or whatever your frame rate is set to).
So unfortunately that little backdrop you call a platform that never moves, holds no values and only has a collision mask, is being drawn 60 times per second, just like every other object on your screen like counters, active objects, strings and… pretty much everything.
Now, this still isn’t really an issue as most modern day graphics cards are shipping with at least 2GB+ of Onboard RAM and plenty of cores for processing. However, it can ultimately lead to a bog down in your Fusion 2.5 application as more and more is thrown at it and it has to deal with all this and render it to the screen 60 times per second. That’s a lot of work if you have 25,000 platform tiles, 1 player character, 1 health bar, 1 timer, a full-blown HUD, layers, effects… etc.
The Solution
*If* your platforms are taking up a nice big section in your level, then it is more better for both the runtime and the GPU to render out 1 image as opposed to 25,000.
So it’s a good plan to design some of your platforms in your image editor and export them out as ‘chunks’. So rather than this…
Do this…
However, at the scales above, it’s not worth doing this with. If your tiles are much smaller and your level is much bigger then it will be worth it.
You have to remember that each persons laptop, PC or even Mobile Device has a limited amount of GPU resources including memory and processing power so you have to cater for this. In the above example, if your level was relatively small (ie: you see no slow-downs) then don’t bother with the above solution. However if your levels are large(r) and/or contains many more graphics/animations and your game is experiencing a slow-down, then implement the above method to see some more favourable results.
Just to finish off, everything described here is applicable for ALL runtimes except Standard. Yep, that means Mobile/UWP/HTML5/Flash and anything else that isn’t Standard runtime.
Oh and one last tip that works in conjunction with this one, don’t forget to keep all your objects to the nearest power of 2.
Join the Academy Today
