Sunlight

'Lag' is one of the most confusing words used in gaming: it's used to describe wildly different problems. This makes communication difficult: when a player is complaining about 'lag', what's his problem exactly? Is he talking about his internet connection, framerate or input delay? So today I'd like to list the different meanings of the word 'lag', both to reduce confusion and to explain why all of them are important. I've grouped them into three main types. It can be difficult to know exactly what's going on, but it would already help a lot to always at least specify which of the rough groups you mean, instead of just saying 'lag'. Note that this post is not specifically about our own games. These problems can happen in most games, although the exact impact depends on how the game was been programmed. Internet and connectivity issues High ping : ping is the time it takes for an internet packet to travel from your computer to another....

Bokeh is an effect that pops up in a lot of new games. It is one of those effects that makes a game instantly feel a lot more "next-gen". It is also an effect that usually eats up a lot of performance. For Cello Fortress I came up with a simplified version of bokeh that looks really high quality, is very fast to render and even very easy to implement. My implementation also has some severe limitations, but I think it can work really well for many games. Bokeh is a part of focal blur, which is also known as depth of field blur or DoF. DoF is the effect that only objects at a certain distance are sharp, while everything closer and further away is blurred. This is an effect that every lens has, and the larger the lens is, the stronger the blur is. Focal blur has been done in many games for quite a while now, but with the normal DoF rendering techniques the bokeh effect is usually lost. Bokeh means that extremely bright spots grow with the blur and appear as clearly recognisable...

Everything in our tools is animatable. Not just position, rotation and scale, but also things like colour, skew, taper, texture scroll and the number of particles emitted. This is a feature that I know from 3D Studio MAX and that I had been admiring for ages, so as a programmer I really wanted to come up with a neat system to build this. Being able to animate everything also happens to be really useful for our artists... ;) Today, I would like to explain how we built this. You might already have seen our animation tools in the Ronitech tools trailer I made a while ago, but that was only a very short fragment, so here is a more complete demo of the animation capabilities of the Ronitech animation editor: Before I continue, I should note that although I designed most of this system, the real credit should go to Thijs (at the time a coding intern at Ronimo , now a gameplay programmer): he implemented it all, figured out the nitty-gritty details, and built the editor's animation UI. W...

The latest Awesomenauts patch increased the framerate a lot for players with older videocards, especially during fierce battles. We managed to optimise our special effects without making them look noticeably different. Today I would like to explain how we did that! Before I dive into the details, let me first give some background. In a 2D game like Awesomenauts, most objects are just a square with a texture on it. The texture contains an image, and you only see that image, not the entire square. However, the videocard renders the entire square. So from a performance perspective, it doesn't matter how much of the texture is actually visible . The entire square is rendered and the every pixel uses performance! Our artists know this, so they try to crop the image to have as few transparent pixels as possible (without changing the actual looks of the end result, of course). Since objects in Awesomenauts contain so many (partially) transparent pixels, we cannot easily detect whether an...

The part that I find most interesting and am most proud of in Snowball Earth (our cancelled game from 2008), is the melting effects. Every piece of the world is frozen and covered in snow, and by walking around with the heating turned on, the player can melt it all. In the prototype this had very few gameplay mechanics attached to it, but just seeing and hearing everything come to life is already so much fun that it could carry half the game on its own. Today, I would like to dissect this effect and give an overview of what went into it. (Spoiler: a lot of custom art by our artists Gijs, Ralph, Olivier and Martijn, and a lot of coding by me). The melting effects in Snowball Earth For those who haven't tried it yet: a couple of months ago (in this blogpost ) we released the entire prototype we made at the time, so you can download and play it yourself. Note that this is a Torrent file, so you will need something like BitTorrent to download the game. Here is the download link: Down...

To finish my little series on CPU optimisation (here were part 1 and part 2 , today I bring out the big guns: threading and timing! This is where optimisation really shines as a form of pure entertainment and delight. I can honestly hardly imagine why anyone ever does Sudokus or crosswords. Puzzling to find the best optimisations is so much more fun! Hiccups are horrible without the right tools Framerate hiccups are a special case. This is when the game is running at a high enough framerate, but once in a while a single frame takes a lot longer. Hiccups cause that a game running at 55fps might look a lot less fluent than one running at 30fps, if every second the 55fps consists of 54 smooth frames and one really long one. The difficulty here is that when you gather performance data, the time spent in each function will usually be averaged. This means that if a function runs really fast most of the time and is really slow only once per second, then it will look like a normal function in...

Last week I talked about some rather general things that I learned about CPU optimisation, when spending a lot of time improving the framerates of Awesomenauts , Swords & Soldiers , and even Proun . Today I would like to discuss some more practical examples of what kind of optimisations are to be expected. Somehow I like talking about optimisation so much that I couldn't fit it all in today's blogpost, so topics around threading and timing will follow next week. Anyway, forward with today's "lessons learned"! Giant improvements are possible (at first) The key point of my previous blogpost was that you should not worry too much about optimisation early in the project. A fun side-effect of not caring about performance during 'normal' development, is that you are bound to waste a lot of framerate in really obvious ways. So once you fire up the profiler for the first time on a big project, there will always be a couple of huge issues that give giant frame...

Optimisation is a very special art form, with lots of tricks and realisations that give it a place of its own in the programmers toolbox. Until I had to do it for the first time on Swords & Soldiers for the Wii, I had never done any optimisation. At university I had already learned a lot about time complexity (big O notation, like O(n) ), but optimising an actual game with a big codebase is a different beast entirely. I was like a virgin that had never been seduced by a handsome profiler yet. I just started fooling around with optimisations, reading tutorials and articles on Nintendo's dev website and the internet in general, and learning as I went along. Since no pro ever taught me how to optimise, I guess I might still be unaware of some really important tricks. Yet somehow I managed to get Swords & Soldiers from an initial 10fps to 100fps on the Wii (if VSync is turned off), and Awesomenauts from 10fps to 70fps on the Playstation 3. In past five years I spent some six ...

In today's blogpost, I'd like to do something radically different: I'm going to ask you a question . I know that quite a few of the visitors of my blog are hardcore programmers, and since I have a complex situation for which I would like to improve the performance, I figured I could ask for advice here! :) The problem is pretty complex, though, so I figured a short blogpost would be needed to really explain it. In short, this is the question: What is the most efficient way to synchronise renderable objects between the game thread and the render thread? There are a couple of subtleties you need to know to answer this for our situation, though. Let me start with a scheme that shows the approach to threading in the Ronitech (our in-house multiplatform 2D engine), as we use it in Awesomenauts on the Xbox 360 and Playstation 3: This works fine and we managed to get 60fps on console this way. However, the copying phase takes relatively long, so I am still wasting a lot of perfor...