Arcade cabinet: The second one!

Some years ago I build my first DOOM II themed arcade cabinet. Back then I was happy with the result of my first build, but it had some things missing in the finish and was not as polished as I hoped.

So I gave it an other shot and build one again. This time I have some experience and tried to create a new DOOM II/UAC themed arcade cabinet with lots and lots of lights to make it really an eye catcher in the dark.


I started of with some particle wood, cut out the right sizes. The curves I drew free handed and traced it with a jig saw. The design was basically some measurement from my old cabinet, only the control panel is now 10 cm higher for comfort. I did not document every part of the build, but here are some pictures with a little explanation.

WP_002241 WP_002256WP_002278

I recycled some parts from my old cabinet, like the TV, speakers, computer, ipac, and the joysticks.
I bought new AimTrack (light gun), marquee light, and illuminated push buttons for the looks and a plunger for playing pinball games.


For UAC logo in the front I made a sticker with a lot of lines to make it easy traceable with a jig saw. I think it came out pretty neat and it breaks the flat clean look of the front.


Now that all this is finished, I painted the whole cabinet in the color ‘Dark steel’ from Flexa, which is actually a paint suitable for walls, but also works on wood when you use a lot of primer. Below is a side-by-side of the old and the new cab!


For power I used a PC-kind of socket (dunno the exact name) in the back.WP_002259

Light it up!

  • For the marquee I used a LED bar that runs of 12v.
  • The buttons all use 12v LEDS
  • For the bottom I used a 5 meter flexible LED strip that changes color.


The marque is almost the same as my previous cabinet, I only slightly changed the planet behind the DOOM II logo.
For the control panel I went for a DOOM 3 PDA look.


The control panel is made by painting a piece of wood gloss black and stick the control panel art on top of it. Only thing left to do is drill the holes for the buttons and wire it all.

WP_002316WP_002318 (2)WP_002323

And with power applied it absolutely looks gorgeous!


Almost finished. All to do now is put a PC inside, make a drawer for the keyboard and mouse to make maintenance easy, and fix the light gun inside the cab with some velcro.


Aaaaand…. DONE!

WP_002412 WP_002532 ????????? WP_002529 WP_002527WP_002396



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…