Summer of Communication

As most can tell the Fusion 3 blog has been dry recently. And for that we apologize. The reason is our two main developers on the project have reached an important phase in the development during which they cannot communicate a lot. They are putting the pieces of the program together and we have chosen to have them focus on this.

Don’t expect any significant news like the announcement of the beta or release date before the last quarter. We’ll try to post intermediate news but at the moment the developers are under big pressure and don’t need more in the form of writing blogs.

Clickteam does clearly hear that you, our users, want more communication from the team. As such we are planning on converting the Fusion 3 Blog to a general Clickteam blog. We will use this space to not only talk about Fusion 3 but Clickteam Fusion 2.5, Clickstore, our educational market plans, #MadeWithFusion games and anything else relative to Clickteam. We hope this will continue to build on our already great community and make for a stronger user base of Fusion developers.


We would love your input on this blog in our community Blog post Comment thread here: Forum Post

Or we would love to hear your comments on our blog posts and on our development on social media. Throw us a mention on Twitter or Facebook and tell us what you think!

Tisnart Shapes delivers an exciting unique take on the familiar match game styles. There are many challenges for you to conquer, twists and turns that await you on each new level. Dice Blockers, Rivet shields, Rotators, Shape Shifters and more will be there to surprise you just when you think you know what to expect.
Fading Suns Noble Armada is a new fleet combat game set in the Fading Suns universe, featuring some of the same awesome gameplay found in the table-top version with new twists for the world of video games. Play one of five different houses, each with unique campaigns, as you attempt to assert dominance in any of the systems of the Known Worlds.
Outbuddies is a deeply crafted 16-bit style Metroidvania for Windows-PC and a story of teamwork and friendship between two very unlikely heroes. It was our natural desire to integrate a local Co-Op option, so you can explore, enjoy or even speedrun this game together.

Sprite sheets

A lot of our users enjoy working with sprite sheets when they make graphics for their games as it keeps all of the similar images in the same file.

“Sprite sheets” is a technique to store several images into one image while still being able to draw them as if they were individual images.

It is convenient for graphics artists and it makes it easier for one to find the file one wants to edit. A typical approach would for example be to have one file per object in the game that includes all the animations.

* Hero.png
* Enemy1.png
* Enemy2.png

Sprite sheets also have a performance benefits at runtime in some situations.

The graphics cards in your computer/phone/console is a very specialized piece of hardware and is very fast at drawing lots of geometry really fast – but only as long as things don’t change too much between each thing that the graphics card is asked to draw. Changing the texture between every object that we draw can become a performance problem quite quickly.

By bundling together lots of sprites into one texture then even though we want to draw a different sub-image from the same texture we avoid the time-consuming texture switch. This will be especially noticeable if you want to draw hundreds of the same type of sprite (for example in particle-systems) at the same time.

Graphics API’s such as OpenGL or DirectX have over the years invented new ways to make using many different textures “cheaper” time-wise. One example is ‘texture-arrays’ that allows you to make an array of textures and then simply ask the graphics API to draw using the texture at some index.

Right now we target the lowest common denominator of OpenGL ES 2 such that the same code will work on phones and in WebGL. This means that for now we stick to the good old sprite sheets. We might have optional support of newer OpenGL features in the future when available.

There are cases though where sprite sheets give no real benefit and that is unfortunately when you have a very diverse set of different objects you want to draw and you use the typical sprite sheet approach mentioned first in this blog post.

From the graphics API’s perspective it will typically only have to draw a very few number of sprites from each sprite-sheet for every texture switch it does. This is because the “logical” organization of your sprites doesn’t correspond very well to the order of how your sprites are drawn.

If your game for example draws these sprites in order:

* Hero
* Sword
* Enemy
* Grass tile
* Earth tile

Then it would switch to a new texture almost every draw call:

* hero.png
* weapons.png
* enemy.png
* ground.png
* ground.png

This would for a lot of sprites be slow. For small games it is hardly noticeable but it still matters. You could of course try to put all of your sprites into the same sprite sheet to minimize the texture-switches but that would remove all the benefits of the having the sprites in sprite sheets in the first place. For Fusion 3 we have a simple solution.

Sprite sheets in Fusion 3

Fusion 3 has native support for sprite sheets in the sense that it only cares about drawing a subset of a texture. Where the texture comes from is not important from the runtime’s perspective.

Fusion 3’s approach to the sprite sheet problem is can be either one of these or both. 1.Generate optimized sprite sheets at build-time. 2.Continuously update sprite sheets dynamically at runtime

Our runtime can during testing collect texture-switching statistics from “representative playthroughs” and figure out which images gets drawn most often in succession. Using this data we can generate optimal sprite sheets (for those representative playthroughs). In any case our build-time sprite sheets will be better than hand-made sprite sheets because of the statistics we can collect.

The static sprite-sheets will of course not be optimal in all cases. This is where a dynamic approach to sprite sheets really can shine. Those sheets can be continuously be updated over time to adapt to any situation. We already have most of this dynamic system in place.

We also have a working system that uses the exact same algorithms to cache the image of certain complex GUI objects that takes a relatively long while to draw but are rarely updated. We then store the rendered images of those objects into dynamic sprite-sheets and draw the cached images back to the screen. This has already proven to be very robust and works completely without any other user intervention.

Sprite sheet editing in Fusion 3

As you saw in our last blog post we are still working on the image editor. For now the inbuilt image editor only opens up the part of the image that is used for the image. When the image is saved we update the section in the sprite sheet.

If you want to edit the image where you can see all the other sprites at the same time you can of course simply chose a different image editor. That will open the chosen editor with the raw sprite-sheet image. There is of course the problem that arises if you want to resize an image that came from a sprite sheet. Making the image smaller is no problem. Making the image larger is a problem as there might not be space for it. For when there isn’t space we will have to save the image into a separate image.

We’d love to hear your comments on our blog posts and on our development.Throw us a mention on Twitter or Facebook and tell us what you think!