Let’s make a long story short, and let’s just say that I lost my identity document recently.
Now, while we’re at it, we’ll make another long story short and say that I haven’t had time until today to go to the Department of Home Affairs and apply for a re-issue of my ID.
The spiffy thing is that I was in and out of the Somerset West DHA office in about half an hour. The other spiffy thing is is that the DHA now allows you to check up on the status of your request on their site. Neat.
Megatrader Main Menu
For the past week, when I haven’t been working, I’ve been spending a good deal of my free time developing a J2ME mobile game. The basic premise is Dope Wars in space, albeit with less drugs and more futuristic trade goods. The inset image is the main menu screen running in the WTK emulator. Right now, I’m more or less at the point where I can actually start on getting the game up and running, having spent the time thus far on getting all the support functionality down (such as drawing text using my custom fonts and being able to easily support different resolutions, since I’ll be targeting at least QVGA and QCIF+ displays).
Initially, the game will be fairly simple, featuring only simple trading: buy at planet A, travel to planet B and sell, rinse and repeat until the time limit is hit, with random price fluctuations as per the drug busts in Dope Wars. In the future, there are a couple of distinguishing features I want to add to the game, such as competing against computer-controlled traders and being able to buy different ships which affect their cargo space and travel speed, amongst other things.
Terra: Full Heightfield
One of the homework assignments for our Graphics course was to implement a terrain renderer using a quadtree structure. After reading up on it a bit, I attempted to implement the method described by Ulrich’s article (although I won’t lie: the working demo code given in the article helped a good deal with that part). The image above is the end result of the terrain renderer, along with the quaternion-based camera library I implemented for the previous assignment.
Terra: Wireframe Heightfield
The random terrain in this example was created by generating a 1024×1024 image in GIMP using the Solid Noise filter and saving it as a PNG, which Terra uses to generate the heightmap. The image used to texture the terrain was created by applying a gradient map to the grayscale heightmap, and adding an embossed version of the grayscale heightmap on top of the gradient mapped heightmap to give the illusion of a directional light source.
The inset image is the same scene as the first image in this post, but rendered in wireframe mode. If one looks closely, one can see how the adaptive quadtree algorithm uses more triangles for high-detail parts of the heightmap, and less (”bigger”) triangles for less detailed parts.
Finally, the last image below is also the same scene as the other two images, but with a detail factor 2ΒΌ times higher than the first two images, also rendered in wireframe, highlighting the increased number of triangles.
Terra: High Detail Heightfield
The freelance work I’m currently doing called for some testing after I significantly changed the underlying framework’s internals. Considering I’d been spoilt with the idea of automating any and all testing when I was going through my Ruby on Rails phase, I started looking around for something similar in the PHP camp. The most important thing I had to keep in mind was that it needed to be something that was JavaScript aware, since the website utilises a lot of JavaScript fanciness.
Enter Selenium. More specifically, the combination of Selenium Remote Control (RC) and PHPUnit.
Selenium RC is a Java server application which launches instances of the browser(s) you specify, and then puts them through the paces of the tests that you define using plain old PHP and PHPUnit, checking the assertions you define. In other words, you get the effect of a real user using a real browser, without having to do all the grunt work yourself. Win-win.
The current version of Selenium RC (henceforth referred to as SRC) I’m using (version 0.9.2) works like a charm, but requires a small tweak to work with Firefox 3. When SRC instantiates a new instance of Firefox, it creates a temporary profile and installs a Selenium extension into the profile. This extension’s maximum Firefox version is still set to the Firefox 2 versions, so it will silently fail under Firefox 3, leaving you to gnash your teeth in frustration while you sift through Google to find out why the damn thing isn’t working.
Fortunately, the fix is simple. It involves unpacking the selenium-server.jar file, and changing the install.rdf located under the customProfileDirCUSTFF directory, so that the maxVersion element contains the value 3.0.* to work with Firefox 3.0.
From there on, you can either pack everything up again into a new JAR (which I didn’t bother with), or simply run the server in its unpacked form.
Next time, I’ll dish up a small sample of how to actually go about doing that funky thing we call testing with Selenium RC and PHPUnit.
Planetscape
I finally managed to finish my implementation of a deadlock detector for my year project (a C framework with which to develop distributed model checking applications) earlier today. While writing the code to output resource usage statistics, I noticed that I’d forgotten all along to add optimisation flags to my make files.
Running the detector with the -O2 optimisation flags yielded the following statistics:
pcronje@gecko modelchecker $ mpirun -H localhost ./deadlock -q -q
[0] Resource usage statistics:
* Store memory (bytes) : 192000
* User time (work) : 2.568160
* User time (total) : 2.652165
* System time (total) : 0.008000
* Page faults/reclaims : 0/1461Switching over to -O3 yielded:
pcronje@gecko modelchecker $ mpirun -H localhost ./deadlock -q -q
[0] Resource usage statistics:
* Store memory (bytes) : 192000
* User time (work) : 1.520095
* User time (total) : 1.604100
* System time (total) : 0.016001
* Page faults/reclaims : 0/1463Not bad. Force of habit running a Gentoo system makes me go -O2 by default when optimising.
Interestingly enough, running the deadlock detector across two systems yielded the following statistics (the number in square brackets indicate the process ID of the printing process):
pcronje@gecko modelchecker $ mpirun -H localhost,localhost ./deadlock -q -q
[1] Resource usage statistics:
* Store memory (bytes) : 96000
* User time (work) : 0.872055
* User time (total) : 0.948059
* System time (total) : 0.028001
* Page faults/reclaims : 3/1628
[0] Resource usage statistics:
* Store memory (bytes) : 96000
* User time (work) : 0.880055
* User time (total) : 0.972060
* System time (total) : 0.008000
* Page faults/reclaims : 7/1623Obviously, the memory usage is neatly halved (since that’s just how the state generator I’m using to test this sucker works), but the interesting thing is the decrease in runtime. I would’ve thought that the communications overhead involved in throwing work items around between processes would’ve made the whole thing about as fast as swimming in tar. I guess the smaller memory footprint is making the difference when the analyser reads through the work item store or something. It’s something I’ll look at once I start properly evaluating the project.