Configuration options

This is the last week of GSOC, the date in which our evaluations begin is tomorrow. It's been a pretty short and exciting trip, sometimes I'm still amazed that I have the chance to work on this at all. On to the additions!

A checkbox for "saving details" was added to the login screen. When checked, the username, password, last server connected to and some other preferences are saved in the user's home directory, so that reinstalling the client will not affect the preferences. The password text is masked now, and saved to disk in hexadecimal format. Pretty primitive, but the idea is just to prevent casual lookers from getting the password.


The configuration dialog was expanded with a couple more options as well as two additional dialog boxes for graphics and sound configuration. The main dialog now has the option to tweak the zooming speed, as well as to adjust the distance scaling. This is meant to help deal with the variety of rulesets which use different units of distance for their maps. The distance unit ratio makes stars further apart the lower it goes, as all distances will be divided by this value when starting a new map.

Graphics options allows the player to change the renderer (although I recommend Direct3D for Windows), resolution and anti-aliasing options. Unfortunately, only the full-screen option works instantly, the rest take place after a restart as only full-screen had a convenient setFullScreen() method which I could use :). Also, each renderer (opengl or direct3d) takes in different values as their configuration. For instance, direct3d takes in resolution and colour depth as a single string, while opengl takes in resolution and colour as different parameters, which means that the user should change the either the renderer alone or the other options without changing the renderer.

For sound, the options are pretty basic (I know it is missing a volume control :)). Setting the driver to other values provided by openal (other than the default 'Generic Software' option) doesn't work for my system, perhaps because I am using on-board sound and not an actual sound card.


Some work was done to allow the client to adapt better to different rulesets. The map centers properly now (I had a dumb bug where I should be reading x and y values, but instead read both values from x). Zoom distance, which is like the 'step size' for zooming, takes into account the distance scale so that larger maps will not take forever to zoom in. Panning takes into account the current zoom level, so it zooms more when zoomed out. Also, a map boundary was added so that the user will not move out of bounds and get lost, although I'm wondering whether this is a good idea as it sometimes results in apparent 'locking' when the camera runs up against the invisible walls. Perhaps the camera could slide along the walls instead, so that the user can still move about smoothly.

One issue with having an adjustable distance scale is that for large distances, the background of stars (which was a particle system) would have to be expanded to encompass everything, thus resulting in a sparser starfield. Although I like the idea of generating the starfield at runtime, increasing the number of stars would have made performance even slower than it already is, so I made a skybox in blender instead. This skybox also replaced the one in the login screen, as it is from the default ogre media - something I am trying to move away from.

The following shot shows a camera placed inside a sphere, with it's field of view set to 90 degrees. The starry texture was done by blender's built-in texture generators: some noise, clouds and playing with layer settings. After that, I rendered a screenshot in every direction and set it as a skybox. Easy to do, but getting good settings for the texture is hard, I haven't really figured it out yet.


The next shot shows the starmap with the skybox in use. Sadly, my computer chugs pretty slowly in this server with 34 players. I believe it's the overlay placement code that's the problem as the polygon-heavy models should have been hidden already.

To end on a high note, I received a nice package this weekend, courtesy of the lead dev mithro. Thank you very much! This made my weekend (well that and Singapore winning it's first Olympic medal in decades, woohoo!)

Interface additions

I adjusted my priorities a little this week, due to the sudden realisation that GSOC is drawing to a close.

Firstly, I added a logo to the main menu.
The logo was taken from the Thousand Parsec website and put into a CEGUI ImageSet, which is the combination of an image file and an xml file which defines the pixel locations of all images within the set. Right now, it is rather empty:


I hope to fill it up with a lot more icons and image elements to add more spice to the interface.

Next, I added a map navigation panel to the lower right of the screen.

The functions of the buttons from top to bottom are zoom in, zoom out, deselect, focus on object and fit map to screen (although the last two buttons are indistinguishable at this size, one points inwards and the other outwards). The icons may be familiar already, as they come from the famous famfamfam silk icon set. I tried creating my own icons at first, but some creations should never see the light of day. With this, there will be a lot less reliance on keyboard shortcuts, hopefully making the client easier to use. The zoom buttons move in larger steps than the mousewheel zoom and are not animated, as I find the zooming animation a little slow on my older computer (it is framerate-dependent).

Lastly, I added a main menu option, allowing the user to return to the login screen gracefully.

I discovered that logging in and out caused a lot of problems with the management of system resources. Models, images, interface elements and such needed to be unloaded and reloaded again, something which I could not find an "easy" solution for. In the end, I traced the loading of all the resources and added a corresponding unload command upon logging out.

Regarding the linux installer, I edited the setup.py file so that the client installs in the same manner as the wxWidgets client. With that, the debian maintainers for Thousand Parsec will be able to package the client into a .deb file, although I'm considering whether to include the binary version of Python-Ogre inside as well, so that the package can run standalone.

This week's focus has mostly been on the user interface, and I think any additional features will have to be put on hold for now, so that I can tie up the loose ends. For now, I will be writing the documentation and working on the mac installer, which is a giant time sink :)

Sounds and Battle

This week I took a look at introducing sound into the client. I found OgreAL a snap to use, it's API is modelled after the built-in Ogre managers such as material and resource manager, so not only was it familiar but also cleanly designed. Unfortunately, technical problems (crashes without any indication of the error - my favourite!) arose when I tried running the code, which I attributed to driver issues, as switching to "generic software" audio drivers - done by passing in a parameter during creation - solved the problem. This parameter is not available for Python-Ogre 1.1 which uses an older OgreAL API.

So all I had left to do were the sound effects.

As I mentioned, I found a program for generating ambient soundtracks last week. It's really a sine wave generator and I'm currently trying it out as a background track. I haven't thought much about what sort of music would be suitable for a game of Thousand Parsec, perhaps I will have the client play any .ogg files it finds in the directory, similar to how Oblivion does it. This way, the user can specify his own soundtrack, although it would be nice to have some original music of our own too.

I spent a while trying to create sounds for other parts of the client. Right now, I've put in a "engine rumble" and clicking sounds for buttons on the gui. Once again, I found a useful utility for these sounds, called sfxr. Most of the sounds produced are pretty lo-fi, but it's suitable for stuff like laser noises and the engine rumble was made from this too (plus some processing in audacity). Hm, there should be some way to embed sounds in blogs too...

I think that the background track does add a lot of atmosphere, but my taste in music is pretty much like that anyway (see Drone Zone on SomaFM) so hopefully it won't annoy others. The sound effects will require a bit of tweaking as well, as their volume varies based on the user's location (automatically handled by OpenAL) and they can sound too loud or too soft at times.

One of the primary motivations for adding sound was to supplement the Battle module, a standalone program for viewing BattleXML files.

Currently, it does not process the actual battle, but it does create and show the initial locations of the fleets. I'm still figuring out how to define weapon locations and attach them to the ships, which should be fun once it is done. Also, there seems to be some texturing issues with the models as well, hopefully I can fix them in Blender.

An additional windows installer script has been created as well, which actually just places the compiled client into your program files directory and create start menu shortcuts. The process of creating the installer actually exposed some bugs - although everything works, on shutdown the client outputs an error log, saying that some background threads had been forcefully shutdown, which made me realise that perhaps I hadn't been closing the client library threads properly, something that I have yet to look into.

Next week, I will be finishing up the battle module and tying up loose ends:
- the starmap could use a navigation bar for zooming and centering
- the title screen should have the TP logo
- using theora to display the intro movie
- a minimap for lost players
- writing up documentation
- packaging linux and mac binaries (big problem here)