Welcome to the Clickteam Blogs
This new area of our site will host a range of blogs including Clickteam News, information about Fusion 3 development, ClickStore Features, User Devlogs and much more besides.

If you would like to write a guest blog article about your game, app, development or something else then please Contact Us for more information.
Sprite Sheets
Posted on: April 10, 2017

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!

Visit Clickteam @ FacebookVisit Clickteam @ TwitterVisit Clickteam @ YoutubeVisit Clickteam @ TwitchVisit Clickteam's The Reactor @ PatreonVisit Clickteam @