Designing Tiles

Tiles are a very important graphic resource for your games, but their design and use can sometimes be problematic.

Tiles are a graphic resource which can add colour, detail and interest to your games with very little processing overhead due to the fact that they have very few "built in" properties and do not generally interact with any instances once placed in a room. However, they do need to be prepared carefully before use, especially if your target device is something other then the PC or Mac, or if you are planning on scaling them up or down. Let's start by looking at an image of a typical problem that can occur when using tiles in your game and then having the view scaled: The image above shows the kind of visuals you can expect to get if you zoom in on a typical tileset that has been created with a space between tiles. Now, most tiles are like this, with spaces around the edges, or they are placed all together in one solid image where the tiles actually touch each other, but unfortunately when zooming out and (in particular) in, this can cause some really nasty issues to solve if your not sure why it's happening in the first place. It's also one of these bugs that you'll be convinced is GameMaker: Studio's fault, after all... if it allows you to scale the tiles, it should work! Well, it does work, but only if you know how the graphics are drawn and prepare your resources accordingly. Let's take a look at a couple of normal tile sets that you might create: These are the most common ways that people create tile sets - either all jammed up together or with little spaces separating them out. Now for a non-scaling game, this is normally fine and you can happily predict what the device will render meaning you pretty much create the tile set anyway you like. But... what happens if we scale them? What does the device actually do? The image shown below illustrates how tiles are mapped generally mapped by the device graphic drivers, with the red line around the tile showing where the U,V coordinates are mapped to (The letters "U" and "V" are used to describe the 2D texture mesh because "X", "Y" and "Z" are already used to describe room and object spatial coordinates): As you can see it picks the center of the texel (a texel is just a pixel in a texture map) to map directly when drawing the image in the room. Now 1:1, this is all well and good... but what will happen when we scale this tile down? The issue with scaling down is that when you shrink, the UVs also scale down and try to fit into a more compressed space, but this obviously can't happen, so graphics driver picks which pixels to draw based on the available pixel centers. So, if we are "just" moving into a new screen pixel then, because the graphics drivers use the center of the pixel to decide what to draw with, it'll pick a texel surrounding the tile, not a texel on the tile itself. Shown above is a tile being draw scaled down into 6 screen pixels, and this shows that when you overlap a little into the next screen pixel, the graphics driver has to make a choice to either drop that texel, or it try and fill it with what it thinks is a valid texel. Let's just say that in this case it decides to draw the overlapped texel into the screen pixel, and, since it's now clearly outside our tile it gets this pixel from either the next tile, or the little bits of space you provided around the tiles, which means that when it shrinks you'll get cracks between tiles "glitches" in how they are drawn and this is where a lot of confusion arises... Each graphics driver and device actually does this in its own way, meaning that the results can be unpredictable and look terrible... but if you're careful and plan ahead you can work around it.

With high end games if you draw from a single texture (not on a texture page or texture atlas), you have the option of using a texture mode called clamp and what this does is repeats the last row of texels infinitely off into the distance, allowing you to scale without problems as it forces the hardware to get the last row of pixels no matter what. However, when using a texture pages in GameMaker: Studio with tiles, you must "fake" this yourself (for more information on texture pages see More About Backgrounds: Texture Pages). Shown above is a "fixed" tile set and you can see it now has a repeated section around each tile meaning that when the hardware overruns, it will always pick the last texel from the tile rather than one of the spaces or the tile after that! When importing these new tiles into GameMaker, it is important to make sure you point GameMaker to the tile inside the "smear" using the x and y offset options in the background resource window as this means you will still get the original tile while the device hardware can use the external area if necessary. The space between tiles is optional and may help you keep track of the tiles better within the tile sheet, but that's up to you. The image below shows how this would finally look when loaded into GameMaker: Studio: Note: All the tiles used on this page courtesy of Lost Garden.

Back: More About Backgrounds
Next: Texture Pages
© Copyright YoYo Games Ltd. 2015 All Rights Reserved