A new year has begun and so we implemented new features as DirectX 11 and XInput. As DirectInput is depricated and not usable in windows 8 store games, it is still supported on windows 7 and 8. The Xbox 360 controller works also with DirectInput, but the two triggers on the back of the controller act as one axis. You can only use one trigger at a time which is rater inconvenient.

Therefor we implemented XInput to use all the Xbox 360 controller features like the two triggers on the back and the vibration function which. We choose to redirect all input of the Xbox controller to the game itself and not go though our input action mapper. This has some advantages as well as disadvantages. We can directly read the players input for each controller, but in the game we need to map the keys for the Xbox 360 controller separately, where the mapping was automatic for keyboard, mouse and DirectInput controller. We might change this in the future as the mapping turned out to be really convenient and versatile. We could for example map player 1 and player 2 to the same controller, a combination of a controller and a keyboard and/or mouse. The mapping function looks like this:

void MapInput(string action, string device, string button);

This is universal for DirectInput, mouse and keyboard. Action is a user defined string, device is the device, “kb” for keyboard, “mouse” for mouse, “joy1″ for joystick 1, “joy2″ for joystick 2 and to forth… with a support of maximum 10 joysticks.

To read the input we have a function:

bool GetInput(string action, out ActionBinding binding);

which returns a bool if the key is down or not and where action is the user defined string (e.g. “Jump”, or “Shoot”). The interesting part is the ActionBinding. This struct returns a few parameters like if the button that was press is a digital or an analog axis and if the key was pressed. This means if the key was up the previous frame and this frame its down, pressed is true. If the key was down the previous frame, and now it’s still down, false is returned. This is a simple event that can be used to prevent repeated actions while the key is down. It’s only fired once, and reset when the user release the button. For analog axis this is different, the pressed is never fired and the down state is always true except when the stick is perfectly centered.

As XInput defines 4 controllers and we want the controllers to be able to vibrate, this interface would be too generic as every action can be mapped to every available button or axis and the engine does not distinguish between different controllers.

We are able to enumerate devices, and maybe we can put a limit per controller on a player when we do the input mapping in-game. But this needs to be dynamic as player 1 may want to play with the keyboard and player 2 with a game pad or the other way around. Or maybe both players want to play with different gamepads. Also I do not want the user to continuously remap the controls when something is changed. This is still something we need to work out.

Happy New Year!

First of all, Happy New Year!

The new years resolutions are to port our engine from DirectX 9 to DirectX 11. So far we have the key components working and Chaosteroids are running like a charm! The engine is now almost 5 years old and some old stuff needs to be replaced by new stuff. The last few weeks we worked pretty hard realize all this new work. We don’t have features to show, but some things are slightly getting better and better.

Next we are busy with a new first person shooting game. We are still checking what style will work and what is not very time consuming to create as we are doing this next to our full time jobs. We may go by something flat shaded or some tron style. The aim is to create a game that is fun single player and fun multi player with random generated levels. More information on this topic later this year. For now here is a preview video.

Dynamic snow

The winter in the Netherlands was wet and warm with no snow to build a snow man, so we decided to implement our own snow system in our engine.

Basically what we did was use the deferred render normal and depth buffer to determine the normal and the 3D position of a pixel on the screen. Than with a little bit of dot product we created snow that will lay on the top of every object rendered with deferred shading.

Here is a movie of the completed effect.

As seen in the movie, the snow only lies on the up-facing sides of the tree branches.

Weather effects

Weather forecast for the coming game: cloudy with lots of rain!

We wanted to add weather particles to our games. And we wanted A LOT! Our existing particle engine was not capable of simulating millions of particles in real time and we could only add them to a limited area. To solve this problem we added boxed movement and batch rendering for particles. This means that we simulate between 50 to 200 particles in a limited area, say 3x3x3 meters and render this box of particles multiple times in an grid of 3x3x3, having a larger weather cube that follows the camera seamlessly.

We also stretch particles in the direction they move and also by camera movement so you get a star field like effect when you are moving pretty fast trough the rain or snow. Here are two movies to demonstrate the effect.

We can already color the sky and change the lighting, and by adding weather effects we hope to create a more dynamic world with real time changing weather.

Out of the old box…

When digging trough some old projects I found ‘race game’, a flight game that would have racing with jets as a main concept. Eventually we never finished this and on Online demo party back in 2008 we used it as a base for ‘Uber Schraal’.


A while ago I posted about procedural generating a city. To make it less boring, we added procedural trees – without leaves.

So, where do you start when you want to generate a tree from scratch. Well, first let examine a tree, you have a trunk that goes into the ground. This can be represented by a cylinder that get narrower at the top. Then you have branches, they start at some position at the trunk and also get narrower at the end and can be represented by a cylinder. So we now have we trunk and a branch that can be represented the same way quite easily.

Now we only have to place the cylinders in the world. Placing is pretty easy as the trunk just can be straight and branches can go half way from the trunk to the side with some random offset. Also branches can have branches, so making the code handle this was not an issue and gives a very nice result. But all the branches are straight?! Not when you make them out of multiple cylinders and give them all a small random rotation, then they seem much more organic and gives a pretty nice result.

Procedural city revisited

Just messing around and made a nice screenshot. Currently we have the plan to extend the procedural city generated sky scrapers and a better street network generator. For now we are stuck with some simple quads that are filled in with buildings. Maybe in the future we will also include a terrain engine so we can generate a world with one click of the mouse…