In the coming weeks we will be throwing a few tweaks around to make sure the physics are both challenging and fun. I will talk more about how the physics have been put together in the future once more media of the game has been released.

Recently I took a break from game code and decided to try and get Multisample anti-aliasing (MSAA) working on iOS. It was a lot easier than I thought it would be. Due to the default renderer on iOS rendering to a Framebuffer Object (FBO) all that was required was to create another FBO and a multi-sample render buffer and just get the draw loop to render to the new FBO and resolve and display into the normal FBO.

Here’s are the results…

Whether this effect makes it into the final game is unknown. We will need to do a profiling step to make sure we still have time to render the MSAA and process the rest of the models. At the moment it seems a little expensive especially with the amount of objects we have to render and process.

Although it’s far from perfect, we have decided to make the tool (along with its source code) available to the public in the hope that, if you find it useful, you might also want to contribute to help improve it.

Click here for download links and more information.

Texture Atlasing is a concept whereby you place multiple textures into a single bigger texture or textures so that you drastically reduce your texture binding and swaps during the rendering of a complex scene.

Atlasing has existed for a while and has been used on many older games as a primary technique — the Quake games for example started using atlasing for a level’s lightmap information. We have recently been looking into this technique because we have increased our texture usage, plus atlasing has a lot of benefits on devices such as the iPhone where texture bandwidth is limited.

Usage

Previously we had been using a limited form of a texture atlas for our UI elements in our games. Here is an example of the atlas for the Air Cadets UI artwork.

As you can see we used a 1024×1024 texture which contains every button, character and element seen throughout the games’ menus and HUD. This atlas was created manually and we had to store image positions and dimensions in a spreadsheet which then was used to create the correct UV coordinates for the in game buttons/images. Although it worked, it was terribly slow for both of us and meant changes to the menu artwork caused many headaches!

For the current project we need to take advantage of atlasing for the main level scenes because our texture usage has drastically increased. After some research, I found that nVidia had released a command line driven tool back in 2004 that had various features to create an atlas automatically and output a useful text-based file (.TAI Texture Atlas Information file) that listed the original texture, its new atlas file and the UV offsets of the position in the atlas (see links at the bottom of this page).

After a few tests and most importantly having the source code to the tool, it looked like the perfect option to get this working within our pipeline with a few changes to help us make sure everything would work on the final iPod/iPhone hardware.

The route I chose was to create a new maya ‘command’ plug-in that would externally call the command line tool with the scene textures, read the created TAI file, then use the new offsets to update all the UV coordinates for the scene. After some testing and custom changes to the nVidia tool, we can now generate atlases efficiently and have all our geometry updated in maya referencing the atlas with the correct texture coordinates.

This now has multiple uses across everything we do as we can decide to place multiple similar objects into an atlas or keep them separate. For example, if we have a scene that contains various prefab objects like tables, chairs, cups or other general incidental items (and we know that these items are going to have a high probability of always being drawn together even if they are separate models) we can simply put all their textures into the same atlas thus cutting down multiple texture swaps when the renderer is drawing these objects.

Once we iron out the few remaining bugs – and once we have got all of its features documented – we hope to release the maya tool at some point in the not-too-distant future.

The Pros and Cons of Atlasing

I’ve been quite positive about atlasing so far, however I should probably make a rundown of all the pros and cons so you can judge for yourself if this would be useful to projects you might be working on or if you are just researching the technique.

Pros

Texture batching / Speed
Mentioned throughout this post, this is pretty much your main benefit. It is not guaranteed to give you a speed up, but with good render ordering it most likely will. For iPhone if you make your atlas a PVR texture as well, you will see much better bandwidth usage.

No power of two limitation within the atlas
With an atlas you get the benefit of placing non-power of two textures into a large power of two atlas – thus allowing much greater freedom creating odd texture shapes and UV setups.

Multiple use – UI elements, UV Animations
You can use the atlas in various forms as mentioned earlier: Air Cadets placed all UI elements into an atlas; you could also (for example) have a waterfall texture animation in your game that uses separate textures for each frame — if you place all the animation frames into an atlas all you have to do is perform UV coordinate shifts on a single atlas.

Image assets easier to manage
Having all your texture information in a single big texture can make life a little simpler for art changes as everything is there in a single image resource for tweaks throughout development.

Cons

Mipmapping and Filtering
Since all your textures are tightly packed, if your UVs are right on the edge of an image within the atlas and you want some sort of mipmap filtering on the atlas to smooth out pixelation, then when the image is mipmapped and using as an example, bilinear filtering — since it uses nearest neighbour you’ll potentially get pixels bleeding from unrelated textures which will look jarring in the final render. A solution to this can be to shift your UVs away from the exact edge of the image or make the image bigger itself inside the atlas with extra pixels so there is a safety border between two images.

Limited texture wrapping / Texture tricks (rotate/scale) will not work
Since your UVs are all referencing the same texture, you are pretty much limited to the (GL_)REPEAT texture wrapping mode. It also means if you were using various texture matrix tricks to increase the repetition or to rotate/scale a texture image you become incredibly limited to small changes, otherwise you will see the surrounding images in the atlas.

Moving/changing images within the atlas can be restrictive
The main point of creating an atlas is to pack as many images into a single texture as possible. Problems may arise when you decide that you want to remove an image from the atlas, which leaves a large wasteful hole that you don’t want. Simply moving the other images about in an image editor is no good as this breaks your UV values for the images that you move. I’d always recommend doing atlasing at a late stage in level creation so you can make more of a correct judgement on what images should be atlased on what objects.

Round up

I know this post is a bit text heavy, but I hope it provides some information to those looking into this technique. We’ve found this system to very beneficial in our current game as it allows us to push the uniqueness of an environment by using more textures than we could have previously. As mentioned, we hope to release our which you might find useful, so watch this space. As ever comments, corrections or any other information is always welcome.

Links

 nVidia Texture Atlas Tools – Tools and source.
Algorithm plus another usage example – Good example.

In our first dev diary we will cover some of our core tech that we have been developing on and off since our first release in 2008. To illustrate our tech we will be showing off a prototype that we were working on called “H3”.

About H3

H3 was a prototype for a puzzle-based platformer.

Most platformers are purely level-based where the player starts a level, travels from A to B (sometimes having completed a set of objectives) and then moves on to the next level. In H3 we wanted to make a continuous, seamless game where the emphasis was on the journey, but so that it still played like a traditional platformer.

The following videos show some game-specific features that our core tech enables us to do.

Video 1

In this video you can see some of the basic mechanics that were implemented in the H3 prototype.

Auto climb/jump

For this technique a simple collision tagging method is used. When the collision data is created each collision polygon can have up to 5 numerical ‘tags’ attached to it. These tags can be used for anything from auto jumps; which footstep sound effect to play; which footsteps particle effect to draw; as well as changes to the default physics settings for that surface (e.g. friction/restitution).

In the case of the auto climb/jump system we use a single numeric tag with a value of 1 or 2 to pick which animation should be played based on the height of the object. When the jump animation starts, the system grabs the current root bone position so that when the animation finishes, the player’s new position is correctly matched with the final animation frame within the level.

Near the end of the video you can also see another use of the tags which causes the player to slide down a slope.

Switches

Switches are managed via an invisible area that checks firstly to see if the player inside it, and secondly whether the use/action button was pressed. When a switch is used it calls an ‘OnUse’ scripted function which triggers any valid scripted event to occur (such as move a block, move the camera, enable/disable another switch etc.)

Ladders

Ladders are handled in much the same way as switches where there is an invisible “use” area in front of the ladder. If the player chooses to “use the ladder”, a scripted event occurs that moves the player towards the ladder and into position so that the player can control their ascent or descent. To ensure the hand positions of the climb animation match with the rung positions, and to ensure mount/dismount positions are handled correctly, we also encode into the invisible area the number of ‘climb’ animations that should be played for that ladder instance. This makes the system very robust as it enables us to have ladders of any height, and means we have direct control when matching our animations to movement.

Video 2

This video shows a test level which includes a block-based puzzle. The movement of each block is handled via a scripted event where a climbable staircase is formed if the player uses a switch.

The blocks are simple box2d objects which are attached to the world on a prismatic joint. The prismatic joint allows a block to be moved horizontally or vertically, and can be limited within min/max values depending on how you set them up.

The blocks are tagged in exactly the same as a normal world collision obstacle, which means the player’s auto climb/jump code works as it would on a static obstacle.

Video 3

For a final look at the H3 prototype, this video shows a render test to see how we wanted things to look.

The world itself is made up of multiple layers that are ordered to make sure all the alpha and blending is correctly passed through the render system. Most of the level consists of 2D quads that are textured with silhouettes of grass, branches, rocks and other objects, which gives it a very organic look.

Since the game was to contain a limited colour range, we experimented with some overlay effects to try and give the world more of a unique style. As illustrated in the video, we implement a noise and sketch effect. These effects were achieved using some basic greyscaled textures which were mapped to a full-screen quad.

Our Tech and Tools in Brief

We currently use Maya as our main ‘editor’. In Maya we have written a selection of custom exporters and plug-ins that are all derived from a generic base type which we can adapt to the specific needs of whichever game we are working on.

From a code point of view we mainly use open source technology which helps us enormously when it comes to getting things done quickly. The following is a list of some of the libraries that are currently in our pipeline:-

• Box2D – We use this for our collision and physics in games where we only need 2D feedback. All the Cabby levels had box2d physics for the vehicles and levels.
• Freetype – When a game requires some nicely rendered fonts Freetype is used to create quad glyphs from TTF files to pass to OpenGL.
• Ogg Vorbis – Air Cadets used ogg for sound effect playback. We have since switched to the AV Foundation from the iPhone SDK as it uses hardware for decompression which is much faster overall.
• Lua – Lua is our choice for anything script driven. Cabby for example used lua scripts for level setups so we could customise various parts without the need to ever recompile the game.
• Ode – This is a recent addition which will be used for any full 3D collision/physics that we will do in the future.
• Libpng/zlib – Used to load/save our png files in both game code and exporters.

Our current philosophy is to keep things very light and simple so that we don’t need to waste time creating tech, so that instead we can concentrate purely on creating games!

Round Up

We hope you enjoyed this first look at some of our core tech in action. In the next few weeks we will hopefully be able to show off how we’re applying it to our next game…so watch this space! If you have any questions, comments or requests for things you’d like to see in future installments of our development diaries, then please leave a comment.