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.
Coordinate Systems
Posted on: November 21, 2016
In the 7th edition of the Fusion 3 development blog we will continue to discuss last weeks look at layers.

In the olden days

All the way back to Klik & Play, the “Click” series has only had one type of coordinate system – one that pretty much was 1 unit = 1 screen pixel (with the exception of intentionally retro-looking games with larger pixels). One object only ever had one [x,y] coordinate on the screen. This was simple and easy to understand for everyone. It was very limited though.

With the addition of layers things got a little more complex. There you have multiple “planes” (layers) of objects that could parallax scroll at different amounts depending on the scrolled position. To keep things simple in the case of parallax scrolling objects still only had one coordinate. If you did Always -> Set position of [object] to XMouse, YMouse then no matter which layer the object was on it would end up underneath the mouse. The coordinates were always interpreted as being some sort of “global” coordinate system.

While this was simple to understand it could complicate more complex games unnecessarily. If a layer scrolled with a parallax multiplier of something different than 1 then all objects in that layer would effectively change their coordinates as the screen scrolled. This meant that you could never store coordinates in alterable values and reuse them later for something as at that time the coordinates would have lost their meaning without doing some offset conversions.

Conversion between coordinate systems

As you saw in the previous blog post we will allow layers to exist in a hierarchy – even allowing objects to have sub-layers with no restrictions on the depth of this hierarchy. With this system then each layer manages it’s own private coordinate system. If you inside you’re own custom object position something at 0,0 then you expect it to be located at the top-left corner of the object no matter where you position the parent object in the frame. Each layer can also have it’s own scale, angle and “camera” position so suddenly the old system with only one coordinate system completely break apart.

As a consequence of this there will no longer *gasp* be a global XMouse, YMouse expression anymore! The one global mouse position you can get is in window-local-coordinates (which aren’t affected by the scrolled position). So how would you position an object underneath the mouse? Where do you get the mouse coordinates from then? Answer: From the layer! Every layer in your frame will now show up as any other object that you can get information from:


Or you can get it dynamically from whatever layer the object is currently on (in case your object type is on several different layers or is moved between them).


Or even chose to convert the window coordinates to the layer coordinates.


There are also expressions to easily convert coordinates between different layers. The action for moving an object between layers will have the option to convert all of this automatically so that you don’t have to worry about it.

Layer layout/display modes

The iOS runtime was the first runtime to get the notion of certain different display modes such as “Center”, “Adjust window size”, “Fit inside”, “Fit outside”, “Stretch to fill”. Instead of just being an option for the window those methods are now an integral part of how layers work. This is really useful for those of you who make your own objects with the layer hierarchy.

For example if you take our custom checkbox example again from last week:

If the checkbox object is originally sized to be 48×48 then the object’s content-size will be 48×48. Say you resize the object to 96×72 units, how will the object respond? Will it scale? Or just show more content if available? That is what the layout mode is for and is handled completely automatic for you.


An UI control like this custom checkbox might use the “Fit inside” option as the default. Some UI controls like a scrollable view would just use the “Expand” mode to show more content within the object. (- Yes, you can even make your own scrollable views if you want. It is just a layer that clips it’s content to the object size.)

As you can see, with all these new layer features it is quite useful to be able to convert between coordinates in all sorts of different layers. All of this is behind the scenes simply turned into a single “matrix” which are super fast to use for both drawing and coordinate conversion so it is very performant at runtime.

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 @