I have done a tutorial on star fields with The Gimp before, but I have found a new method that yields much better results. It’s very easy and can be done in a few minutes.
Start up The Gimp and create a new image. In this tutorial, I’ll use a 480×320 image (otherwise it would be too big for this page), but you’ll probably use something bigger. Fill the background with black and create a new layer named “Small stars”. Fill this with black as well and add some RGB noise (Filters -> Noise -> RGB noise). Uncheck “Independent RGB” and set every color to 0.5. Set the mode to screen. This won’t make a difference against a black background, but it will if you want to put other layers behind the stars.

Now we’re gonna adjust the density and brightness of the starfield. Open the brightness and contrast dialog (Colors -> Brightness-Contrast) and set the brightness to -40 and the contrast to 40. This will filter out a lot of the noise and create something that already looks a lot like a decent starfield.

Duplicate the layer with the stars and rename it to “Big stars”. Scale this layer x2 (Layer -> Scale Layer). You will probably end up with a layer of blurry dots. To turn them into stars, open the Treshold dialog box (Colors -> Treshold). By moving the left slider, you can control the density of the second layer of stars and it will sharpen the dots. Here’s the result:

This already looks like a pretty good starfield! For a finishing touch, you can adjust the opacity of the small stars layer. The final result, with the small stars layer’s opacity set to 70%:

It’s been a while since I did a particle tutorial, but here’s a new one at last. I tried something different for this one. Instead of putting lots of screenshots in this post, I combined them into a video file and published it on Vimeo. I didn’t put in on Youtube since you can’t download the original video file there, wich can come in handy from time to time. As usual, this tutorial assumes you’re familiar with Torque and the particle editor.

Fireball and smoke explosion tutorial from Videogame Biscuit on Vimeo.

If the streaming video isn’t clear enough, you can download the original WMV file on the video page. Also available are the tutorials as OpenOffice.org Impress and Microsoft Powerpoint slideshows. And finally, you can download the particle effect file with the particle sprites.

• View the video on Vimeo
• Slideshow in OpenOffice.org Impress format
• Slideshow in Microsoft Powerpoint format
• Download the finished effect

In this tutorial I will explain how to remap input keys using an XML file and a configuration dialog box. First of all, here’s the config dialog. I assume you are familiar with the TGB GUI builder for this.

Most of the action will take place in the listbox under “Keyboard input”, wich is a GuiTextListCtrl object. When the dialog box is opened, the input configuration is read from the config file and put in the list. This is the config section for the keyboard input:

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes” ?>
<KeyboardSettings>
<Leftkey>left</Leftkey>
<Rightkey>right</Rightkey>
<Upkey>up</Upkey>
<Downkey>down</Downkey>
<Subfire>lcontrol</Subfire>
<Shipfire>lalt</Shipfire>
</KeyboardSettings>

And this piece of TorqueScript will read the settings and put them in the dialog box:

function FillKeylist()
{
//Open config file
%Xml = new ScriptObject()
{
class = “XML”;
};
%Xml.beginRead($ConfigFile);
%Xml.readClassBegin(”KeyboardSettings”);
//Clear and fill list
KeyboardList.clear();
KeyboardList.addRow(0,”Left” TAB %Xml.readField(”Leftkey”),0);
KeyboardList.addRow(1,”Right” TAB %Xml.readField(”Rightkey”),1);
KeyboardList.addRow(2,”Up” TAB %Xml.readField(”Upkey”),2);
KeyboardList.addRow(3,”Down” TAB %Xml.readField(”Downkey”),3);
KeyboardList.addRow(4,”Anti-sub torpedo” TAB %Xml.readField(”Subfire”),4);
KeyboardList.addRow(5,”Anti-ship torpedo” TAB %Xml.readField(”Shipfire”),5);
%Xml.readClassEnd();
%Xml.delete();
}

So now we have a list of input keys, now we need a way to change these. For this, a new dialog box “RemapDialog” is created, wich is opened when the list is double clicked (put canvas.pushDialog(…) in the AltCommand field). The RemapDialog window is a small window wich holds a text label and, most important of all, a GuiInputCtrl object. This is as good as undocumented, so it took me a while to figure out how to use it. The key function here is the “onInputEvent” callback. This is executed whenever an input event takes place. Here’s the code for retrieving the key wich was pressed:

function RemapInput::onInputEvent(%this, %device, %action)
{
//Only respond to keyboard input
if (%device $= “keyboard”)
{
//Close dialog
canvas.popDialog(RemapDialog);
//Remap the keys
RemapInputkeys(%action);
}
}

The %device parameter is used to filter out keyboard input, so the event ignores mouse events. The %action parameter is the key that was pressed. This is a string value wich you can use for the “bindCmd” function. I won’t go into detail about the RemapInputKeys function. What this does is replacing the entry in the input key list and saving it to the configuration file, but those are topics that are well documented (check my previous tutorial for info on reading and writing XML files).
Perhaps I’ll write a small demo project that demonstrates this all, and make it available with the source code so you can experiment with it.

I finally got a system up and running for setting and storing configuration settings. It wasn’t easy, since many of the functions I had to use weren’t exactly very well documented. Everything works now, so here’s a tutorial on how I did it. I’m gonna start with XML files, since that’s what I use to store the settings. I tried using a simple text file first but that was kinda tricky and not very stable; a small glitch could cause the entire game to go into an endless loop, freezing it. I’m not gonna explain what XML files are, there are plenty of websites already that do that. From now on, I’ll assume that you know what they are.
The XML file I used for my settings contains three sections: display, keyboard and joystick settings. Later on a highscore section will probably be added as well. Here’s what the file looks like:

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes” ?>
<DisplaySettings>
<Width>1440</Width>
<Height>900</Height>
<Fullscreen></Fullscreen>
<Autosize></Autosize>
</DisplaySettings>
<KeyboardSettings>
<Leftkey>left</Leftkey>
<Rightkey>right</Rightkey>
<Upkey>up</Upkey>
<Downkey>down</Downkey>
<Subfire>lcontrol</Subfire>
<Shipfire>lalt</Shipfire>
</KeyboardSettings>
<JoystickSettings>
<Subfire>button0</Subfire>
<Shipfire>button1</Shipfire>
</JoystickSettings>

The name of the file is CustomConfig.xml. Now, before I start explaining how to read and write this file, here’s something very important, especially if you’re using Windows Vista: make sure you have the most recent version of Torque Game Builder! In Vista, the older version (before 1.6) won’t work. This is because of a security feature in Vista that doesn’t allow a program to write to files anywhere on the system (unless you save a document, of course). On XP, you could write to any directory, but on Vista you can only write to the application data directory, wich is hidden in the “Documents and Settings” directory. This article explains everything in detail. Old versions of Torque will attempt to write to the game directory, wich won’t work on Vista. Also, you’ll need to call the setCompanyAndProduct function as soon as possible in your game to make sure you’ll put the config file in a unique location.
Another thing to keep in mind is that while you won’t be able to write to the game directory, you are able to read from it. Torque will first look in the application data directory and if the file isn’t found there, it will go to the game directory. Why is this important? When you distribute the game, you don’t need to copy the config file to the application data directory. Instead, you can leave it in the game directory. The first time your game runs, it will read the settings from the file in the game directory. The first time the player changes one of the settings, it is written automatically to the application data directory.
Okay, enough about the Torque file system, and let’s start coding! Torque contains a class for reading and writing XML files: SimXMLDocument. Unfortunately, this class is mostly undocumented. Fortunately, however, there’s a wrapper class that does everything you need! This class is, conveniently, called “XML” and is located in the common/gameScripts directory of your game, in the file xml.cs. Here’s some sample code on how to use it. It reads the display settings from the file.

%Xml = new ScriptObject() {class = “XML”;};
%Xml.beginRead(ExpandFilename(”~/CustomConfig.xml”));
%Xml.readClassBegin(”DisplaySettings”);
%Width = %Xml.readField(”Width”);
%Height = %Xml.readField(”Height”);
%Fullscreen = %Xml.readField(”Fullscreen”);
%Autosize = %Xml.readField(”Autosize”);
%Xml.readClassEnd();
%Xml.delete();

Here’s how it works. Line 1 creates a ScriptObject instance and assigns the XML class to it. Line 2 opens the configuration file. The ExpandFilename function is necessary to turn the filename into a valid path; you don’t have to worry about the exact path, this happens automatically. Line 3 tells Torque to start reading the DisplaySettings section of the XML document. By sorting the config data into sections, you’ll first of all keep the file easy to read, and second it allows you to use values with the same names in different sections, wich could come in handy in large config files. Lines 4 to 7 read four different settings from the file. The last two lines stop reading the DisplaySettings section and then delete the XML object.
Writing to an XML file happens in more or less the same way. You create an XML object and open the file in the same way, and here’s how you write data:

%Xml.writeClassBegin(”DisplaySettings”);
%Xml.writeField(”Width”,%Width);
%Xml.writeField(”Height”,%Height);
%Xml.writeField(”Fullscreen”,%Fullscreen);
%Xml.writeField(”Autosize”,%Autosize);
%Xml.writeClassEnd();

Pretty much self-explaining. This method can be used to store all kinds of data in an XML-style format. I used it for configuration settings now, but it can also be used, for example, for custom level builders. The possibilities are unlimited.
In the next tutorial, I will explain how to remap input keys.

Okay, so I decided to explore Blender again. Since POV-Ray and Moray don’t work as they should on Vista I need a replacement, and preferably a free one. I had tried Blender before, and while it’s incredibly powerful, it’s also difficult as hell. Dev.Mag, a South African game development magazine, has an excellent series of tutorials, so let’s try that out.
But that’s not the main point of this post. What this is about is this: a Blender hotkey map. Since Blender relies heavily on keyboard shortcuts, something like this is a must have. It has a full reference for both object and mesh edit mode. Before I can print it I have to change a few details, though. The problem is, here in Belgium a querty keyboard is rarely used. Instead, we have azerty keyboards, and it turns out Belgium and France are the only countries in the world where that layout is used. I have no idea why that is. It has nothing to do with language, because the Dutch use querty keyboards and they speak (more or less) the same language. Nothing to really worry about, just switch a few keys and the problem is solved.