Bah, I seem to be attracting hardware failures of late. The new stick of RAM I bought for my laptop in June decided to up and die, corrupting my Windows installation along with it. Luckily it has lifetime warranty, so I didn't lose anything, except my patience with the sluggish remaining 512MB of "not enough" RAM and having to reinstall everything which sucks when you're a developer (it takes ages).

But let's move onto the more interesting things. What I've begun doing is having a folder in my bookmarks in Opera, and when I get a particularly interesting article I stick it in there to write about later. This should mean I will blog more frequently*.
* Terms and Conditions Apply. :)

So. The first item: Windows PowerShell has gone 1.0! As we all know, the standard command prompt and scripting offered in Windows blows when compared to Bash in Linux. PowerShell is here to rectify that. However, don't go jumping into it thinking that you can just run all of Windows from the shell. Windows is still a strongly GUI-centred operating system and you can't just run the OS from the command-line like you can in Linux. Certainly it has been touted to make Windows Server administrators' lives easier, but unlike Linux, most apps for Windows aren't written with command-line functionality or COM interfaces.

The PowerShell syntax is a weird amalgam of C# syntax with a little Bash and some weirdness thrown in there for good measure. I almost wish it was more C#ish; just some things like the equality operator being -eq, as opposed to the more C-style ==, seem strange when you are doing C# style foreach loops.

Where Bash is often centered around plain text hacking, PowerShell does it differently. When you "pipe" things around you are piping objects. Yes, PowerShell is weirdly object oriented. Kind of. PowerShell is built on top of the .NET Framework, and it shows through. Passing objects around instead of plain strings is better since different cmdlets (pronounced "command-lets", these are the commands in PowerShell) can act on the objects differently without the need of string hacking ala Bash. For example, instead of (in Bash) getting a list of files, using awk to rip out the filenames then throwing them into file, PowerShell does it by getting objects that represent the files and passing those objects to some other command which will extract the filename object property and write them to a file. Its a crappy example, I know, but I haven't spent a lot of time in PowerShell yet. :)

If you're interested, you can download PowerShell here, and read a rather good starter tutorial here. In my summer holidays I'm looking forward to fiddling around more in PowerShell.

The next item on today's agenda: threading in the Source Engine! If you don't know what the Source Engine is you either live under the "I don't play computer games" rock or you play way too much Starcraft. For you people, the Source Engine is the game engine that powers the bestselling Half-Life 2 game and has been licenced for other good games like Dark Messiah - Might and Magic, and Sin Episodes.

Most game engines these days don't properly take use of dual/quad core CPUs because they are not "multithreaded". A program that is multithreaded has multiple lines of execution all running concurrently. This means, on a multi-core computer, more than one thing is happening at once. If your game isn't threaded it pretty much means a whole half (or three-quarters or whatever) of your CPU is going to waste. So its an important thing for games to become multithreaded.

Valve (the makers of the Source Engine, oh uneducated ones :P) have started work on making the Source Engine multithreaded. This is difficult since threading can be a real pain in the butt and will require a large amount of the engine to be rewritten. There are three main ways that multithreading can be done in a game engine: in a coarse fashion, in a fine fashion, and in a hybrid fashion that uses elements from both coarse and fine.

The coarse fashion is where different game subsystems are put on different threads. Valve found this to be ineffective in utilising the entire CPU fulltime. The fine fashion is where low level tasks are split across cores. This method was also unsatisfactory since not all tasks are well suited to being split in this fashion. Valve settled on the hybrid method which pretty much means it uses the coarse fashion where it suits the problem and the fine fashion where it suits the problem. This way is the most complex but it scales well and maxes out the CPU.

What Valve has done is to create N-1 threads (for N cores on the CPU) with the other thread being the master controller thread. Valve uses lock-free algorithms to help remove the problem of threads sitting around blocking (doing nothing) while they wait for access to data (two threads cannot write to the same piece of data at the same time, that would be bad).

Multithreading in Source can only bring benefits to Source-based games. I know that currently half of my CPU (1 core of 2) sits around doing nothing when I play games, and last time I checked I didn't fork out good cash for it to be slacking! There is a full on article about multithreaded Source which goes into more detail and has a good focus on the technical side of the threading, which a lot of the other articles about this didn't.

A nice thing to hear is that Valve uses iterative development on the Source Engine (building and improving it piece by piece over time, rather than writing it and then rewriting it from scratch for upgrades) because my course at University likes to rave about iterative development. Wonder whether they do unit tests :).

And finally on today's show is a little something to back up my rant on Apple a few blogs ago. I will now degrade into IM-speak: LOFL, ROFLMAO, LOL.