SteveStreeting.com

As I’ve said before Harmonix really like Foo Fighters, and/or the Foos really like Rock Band, because this week we had more tracks from the band (plus some from Nirvana, where of course Grohl cut his teeth as a drummer before emerging from the shadows as a bloody good all-rounder) which is great in my book. Despite this year’s album being a little too easy-listening for my tastes, Foo Fighters remain one of my favourite bands of the last decade or so.

My last ‘must have’ track was The Pretender, and that got delivered this week, along with Best of You (also a great track) and a couple from the new album, Wheels and Word Forward, which are ok but I can take or leave (in this case, leave). I actually think my list is all Foo-ed out now. Not that I’d resist if they added more to choose from of course

The Nirvana tracks I’m sure are welcome for their dedicated fans, but once again they deftly manage to avoid the tracks I’d pay money for – Smells Like Teen Spirit, Lithium and Come As You Are. I’m not a huge Nirvana fan, clearly they were ground-breaking for their time, but too many of their tracks sound too much alike for my post teen angst tastes. Only those 3 really stand out for me as worth a purchase; the rest feel a bit like rearrangements of the same songs.

And the Joan Jett track? Hmm. Great video for laughing at crap video effects though.

Git is picky when it comes to converting large, moderately complex Subversion repositories and so far the only option I’ve found that works reliably is using the very latest version on Linux. Forget about using 1.6.5 on Windows via msysGit, at least for the git-svn conversion it’s very, very unreliable. Similarly I found Git 1.5 on Linux very flaky for the svn conversion. This doesn’t give me the greatest confidence in Git but in order to properly explore all the angles, I’ve committed to making it work even if it means I have to monkey about a bit.

So, I installed a fresh Kubuntu 9.04 (and of course, 9.10 went stable a few days later) and tried to build Git 1.6.5 from source. The configure script is unfortunately a bit rubbish and doesn’t bother trying to detect the dependencies though, so for those that don’t want to go through the fail/retry build loop I went through, here are the packages you’ll want to install via apt from a clean version:

• build-essential
• curl
• libcurl3
• tk
• subversion
• libsvn-perl
• cpio
• zlib
• zlibg1-dev
• expat
• perl
• iconv

If like me you use the excellent wajig wrapper around apt, you can also do ‘wajig build-depend git-svn’, but that seems to install things that are not strictly necessary in the default build (but maybe are needed with some non-standard options).

sudo apt-get install curl
   41  sudo apt-get install libcurl
   49  sudo apt-get install tk8.4
   53  sudo apt-get install cpio expat
   55  sudo apt-get install zlib
   61  sudo apt-get install build-essential
   66  sudo apt-get install zlib1g-dev
   72  sudo apt-get install asciidoc
   75  sudo apt-get install xmlto

Aussie gamers don’t half get a raw deal. We bitch here in Europe because of delayed releases (less of a problem these days), and more expensive games & hardware (the typical exchange rate is 1.2 dollars to the pound, which I can’t remember us ever getting close to), but compared to Oz, we’re laughing. Not only do games take ages to appear down there sometimes, they’re often ridiculously priced and mutilated by censorship. The latest example is what Valve had to do to Left 4 Dead 2 to make it acceptable to the censors.

I can sort of understand the gore reduction – the amount of blood and bits of bone and sinew flying about in the sequel was quite a surprise compared to L4D1, and I’m not sure it really adds to the game except for perhaps being more true to the zombie movie tradition. Things that do have a serious effect though include:

1. No riot cop zombie. I guess the Oz authorities didn’t like you shooting the police, even if technically they aren’t exactly suitable for active duty anymore, on account of the fact that they’re trying to eat the brains of law-abiding citizens, which I’m pretty sure is a disciplinary issue. The ‘uncommon infected’ are good for mixing things up a bit and I liked this one.
2. Bodies fade away quickly. This is awful – when we played L4D1 on split-screen we were struck by how quickly the bodies disappeared (for perfomance reasons) compared to the PC and it really saps the realism. In L4D2 after you’ve survived an attack it’s a source of pride to see the area littered with vanquished zombies as a testament to your will to live. Looking around and seeing a bare street just undermines the experience. I don’t know why they thought they needed to do this, especially as the gore is already turned down so it’s not as if you can marvel at the hideous new damage models Valve has implemented.
3. No burning. Oh come on – so now you’re not allowed to set zombies on fire? They still die if they’re in the fire, they just don’t catch on fire themselves. Right.

I fail to see what the Aussie censors are trying to achieve here. Are zombie films not allowed in Australia either? Because essentially L4D2 is just a better sim of that experience. Here’s the comparison:

About the L4D2 demo which we got a few days ago (because we pre-ordered) – it’s a lot of fun. The demo isn’t as creepy as L4D1 because it’s in daylight, and in a developed setting so it’s less about peering into the dark and shooting trees that you’re sure twitched, and more about just trying to hold off rampaging hordes. Different L4D1 levels had different feels so I’m hoping the night-time campaigns will have more of the suspense element; in particular I’m sure the swamp level will be pretty nerve-wracking. The demo was much more of an arcade shooting romp than a suspenseful survival experience, I’m just hoping that Valve haven’t caved in to the vocal people that just play bombastic Versus and keep more of the tense & pressing atmosphere in the other levels for us co-op players.

That said, the new special infected were great to mix things up, as are the uncommons, melee weapons, new ranged weapons and buff variants like the adrenaline. Instead of just going Boomer-Smoker-Hunter-Smoker-Hunter-WITCH!!-Boomer-Hunter-Smoker-Boomer-TANK!!, which started to get repetetive after a while (but still fun), you get a bit more variety. The Charger in particular is great for instilling panic, smashing through a group if you don’t see him quick enough and dispersing you from your defensive huddle, with one unlucky person ending up being smooshed into the dirt. He’s not that tough, but boy he runs fast.

I liked the idea of Realism mode, where you can no longer see hinting outlines of team mates / objects to assist you, and that if you die, there’s no coming back unless another team member has a defibrilator unit (nice idea). Puts a new spin on the harder modes! Anyway, should be fun when it’s released on November 17th.

As soon as Macs started running on Intel, they became infinitely more attractive just because suddenly you had the option of using Windows on them too if you needed to. Because let’s face it, as lovely to use as OS X is, and as much as its popularity has grown, the majority of the world still runs Windows. Boot Camp is a great little tool provided by Apple which makes setting up a dual-boot into Windows generally a breeze, barring a few small niggles such as the slightly ropey support for the extended functions of the track pad (two-finger right-clicking and scrolling is very flaky).

I have Vista installed as a secondary boot on my 2007 MacBook Pro, something I’ve come to regret as it’s regularly far more hassle than XP would have been. In practice, I’ve found that I hardly use it, with weeks passing without me bothering to boot up Vista (which makes it worse, because when I do boot it up its intrusive and wholly unstoppable update process starts kicking in in the background, making me grind my teeth at the CPU / RAM loss). Nevertheless, it’s useful at times.

I’ve dallied with virtualisation occasionally, from Parallels to VMWare to VirtualBox, but have been generally disappointed – my day-to-day work and most of my recreation involves 3D acceleration in one form or another, and virtualisation has historically been pretty bad at supporting it, making it an impractical option. VMWare Fusion 3, however, claims support for Shader Model 3, which is good enough for the vast majority of the work that I do (Dx10+ is still a tiny, tiny niche that is still rarely in demand), so I thought I’d give it a shot.

One of the nice things about Fusion 3 is that it lets you boot your existing Boot Camp partitions in a VM, which meant I could test it quickly. Parallels supported this too but I found it didn’t work that well in practice when I tried it. Fusion 3’s support is excellent – just a few minutes of adaptation and the requisite install of VMWare Tools on the Windows partition and it was up and running. The main problem I initially encountered is that the default 1GB memory allocation is, of course, absolutely no use for running the sweating hunk of lard that is Vista. This is the OS that is capable of getting up to 1.2GB on my machine after first boot with only Explorer open, if you’re unlucky enough that it feels it needs to run update processes in the background. I only (only??) have 2GB on my laptop so I had limits, but a quick tweak of the VM to 1.6GB (and also letting it use multiple CPUs) made it run OK and still let me jump back to OS X, albeit a bit slower than usual (but show me a post-millennium Windows OS that can stay usable on 400MB!).

For general non-specialist use, Fusion 3 is as awesome as other virtualisation tools. Either in a window, full screen, or in ‘Unity’ mode, where Windows apps look like first-party OS X windows in your task list (a bizarre feeling to have Explorer and Visual Studio show up in Exposé), it works great. They even fix the track pad issues, it works much better than in Boot Camp natively. I’d definitely want to upgrade the RAM on my machine if I did this regularly, but it’s certainly solid. But, for me, it’s all about the 3D, so let’s get to that.

I ran through a few GPU tests, after having to wait an hour or so for Vista to go through its background update processes so that it stopped sucking CPU and RAM, distorting my performance sampling (grr), and sure enough all the OGRE demos ran ok. They did, however, run pretty slowly; simple fixed-function demos that usually run at 2000fps on this machine ran at about 300fps, and moderately complex SM2 demos usually pegged at 250fps here ran at about 40fps. Highly complex SM3 demos (e.g. OgreSpeedTree) were unfortunately almost unusable. So, you can expect a pretty steep performance penalty of at least a factor of 6 times running virtualised 3D in my experience. Clearly, at this performance degradation, this would be no good for me as a sole Windows option on this machine. But, it still is valuable, since it’s using the Boot Camp partition, I can use this to quickly test things for compile & run-time behaviour, albeit at unrealistic performance levels, and reboot ‘properly’ into Windows for the times where I want to performance test or demo something.

That is, I would be able to if it wasn’t for Windows Activation. As we all know, this is Microsoft’s anti-piracy strategy and involves requiring you to re-activate your copy of Windows within 3 days if a ’significant’ hardware change is detected. Since a VM basically emulates all of the core system processes, inevitably Windows sees that as a ’significant’ change and requires you to reactivate. You can do this online, but only 5 times, after which you have to phone someone every time you want to do it. If I used my Boot Camp partition in both modes, as is useful to me, I’d have to reactivate way too often.

There are some threads and articles about this issue on the VMWare site; they claim that provided you follow this article, then the Windows activation monster will be sated and leave you alone when switching between Boot Camp and Fusion 3. No such luck for me, I’ve rebooted many times between Boot Camp and VMWare and have had the VMWare Tools installed since the first boot, and all I continuously get is an activated product when I use Boot Camp, and a ‘2 days to activation expiry’ message in VMWare. I’m not the only one: people are reporting this issue in the forums, including with Windows 7.

If they can’t get the activation issue fixed, so that I can choose to use Boot Camp and VMWare interchangeably, this effectively kills the product stone dead for me, as with every other virtualisation product before it. Which is a shame, because apart from this,  it works great. It’s Windows fault of course, rather than VMWare’s, but regardless the effect is the same. This is a perfect example of bad, customer-unfriendly DRM – it’s especially galling to have MS accuse me of stealing when in fact I’ve paid through the nose for many, many copies of Windows before, and am set to do so again with their expensive Windows 7 (Pro+) pricing – where they still seem to stick to this ridiculous principle. Another option would be to free up a spare Windows license from my collection and have separate Boot Camp and VMWare partitions, but I’d really prefer not to burn the time & disk space on maintaining two installs.

Fix the activation issue and I’ll be buying a copy of this plus a 4GB RAM upgrade immediately. Until then, it’s another nice product that’s scuppered by one small, but nevertheless major issue.

Edit: Ok, I’ve resolved this issue. Actually the original KB article on the VMWare site was correct, I just didn’t follow it correctly. In my defence, the key to success is in the small print at the bottom of the article rather than the ordered steps: you have to make sure that you’ve booted once into Boot Camp with the VMWare Tools installed, then afterwards to start the VM under OS X and reactivate Windows. Having done this, both my hosted VM and Boot Camp configuration show up as ‘activated’, which is precisely what I need.

So, now to buy a copy of this puppy and get 2 new sticks of RAM to shove in the laptop.

Woohoo, Torchlight, the new ARPG by Runic Games and using OGRE for rendering, is launching today! Well, strictly speaking the single player game launches today, with an MMO version planned for 2010. Torchlight has been developed in Seattle by a veteran team composed of the designers and leads of projects like Diablo, Diablo II, Mythos, and Fate, so you knew this was going to be good.

Well, Runic were kind enough to send me an advance copy which I played a little yesterday, and boy, is it polished. You can really tell the heritage of this team, it’s immediately fun to play and has really great production values with tons of neat little touches and is something of a visual treat, which considering it was designed to work on low-end hardware too (it has an explicit ‘netbook mode’ for goodness sakes) is no mean feat. A level editor is coming out very soon too – the very same one that Runic used to create all the levels in the game – so that will be a lot of fun to play with too I’m sure.

Obviously we’re very proud that OGRE has been a part of creating this title. Torchlight is available to purchase in about 10 minutes time according to the countown clock, as a digital download from Perfect World, Steam, Direct2Drive and other partners. It’s staggeringly good value, so go get it!

[edit]In case you need more convincing, here’s a nice video review / overview:

As  you know I’ve been reviewing DVCSs lately. I’m taking my time doing real use cases on them, and deliberately not doing the sort of feet-first leap into whatever looks best / most popular on the surface because I don’t particularly want to discover unexpected problems down the track. It’s consuming a lot more time than I expected – I’m writing up my findings and may publish the entire results later on if I can find the time to clean them up and format them better, but for the moment I thought I’d share some experiences with the conversion process of a relatively large, long-lived, multi-branch repository (OGRE) from Subversion to Git and Mercurial, because that’s what I’ve been wrestling with in the last few days. I discovered a bunch of additional issues during this process that did not occur when starting from scratch or doing conversions from more trivial repositories, so I thought it might help others to talk about it.

Source Subversion repositiory specifications

Revisions: 9215 (as of today)
Branches:  9 permanent, 22 temporary / experimental
Size: 375 MB

Also of note is that the source repository is still at Subversion 1.3 – this is because Sourceforge was stuck on this version for a long time and we haven’t upgraded the repository since they started supporting newer versions. We never bothered because it requires locking out the repository while you download the whole thing to a local machine, upgrade it and re-upload it, which is a hassle, especially when you have things to do. In practice the server-side version hasn’t been a major issue since you can still use newer clients with it and svnmerge operates regardless.

General Approach

I rsync the OGRE repository down to a local Linux server several times a week, so that was the source of all my conversions, eliminating most of the network time. I tried to convert the repositories using Windows clients in the first instance, because that was easier to use the latest versions of the tools (my Linux Server is on Ubuntu 8.04 LTS and even with hardy-backports available it’s not as up to date – and for simplicity because this is an important server I stick to the official versions). There is a 1Gb network connection between the machines so it could be pretty speedy.

The principle is that I want to preserve all history, all branches, and all tags. In practice I may actually prune off some branches later on, so that the clone process is quicker, but the base principle is that it should be a lossless conversion in the first instance. Definitely no top-skimming of the trunk like some conversion articles advocate – we have stable branches that must be maintained and regularly have work that we want to keep in experimental branches. In particular, post conversion it must be possible to continue committing to and merging from stable branches.

Git Conversion Experience

I’d previously converted some other, small and fairly simple Subversion repositories using git-svn (less than 500 revisions, and 2-3 branches) and it worked fine. However, when trying it against the considerably more complex OGRE repository I hit problems very quickly. On Windows, using msysGit 1.6.4 the process failed after 1900 revisions, just after doing the automatic repository tidy (git gc). The error message was simply ‘fatal error running git-svn’, even though it had been running exactly that command for the last 1900 revisions. Thinking there might be an msysGit issue here, I switched to the Linux server (git 1.5.4) and tried the same thing. This time it fell over at revision 176 with absolutely no error message. In both cases the repository left behind was corrupt so I could not resume the process.

The other thing I noticed was how long the process took on Windows. 1900 revisions took 5 hours (!) and thus I wasn’t in a hurry to retry the process there. On Linux the process was much faster, as far as it got. It’s worth noting that this is not caused by running across 2 machines – not only do I have a very adequate 1Gb link, Mercurial managed significantly faster conversions using the same topology. msysGit’s git-svn conversion is simply incredibly slow.

At this point I decided to try upgrading the Subversion repository, just in case git-svn hadn’t been tested with older repository versions. My Linux server had svn 1.5 on it, so I upgraded the OGRE repository to that locally and re-ran the git-svn process on the Linux machine (as I say, I wasn’t keen on repeating the glacially slow msysGit conversion). Sure enough, this time all 9200-odd revisions converted fine, in only about 1 hour 40 minutes, or about 15 times faster than doing it on Windows.

So, I may have had a few problems, and being forced to upgrade the repository before converting was a bit of a pain, but at least it worked and was fast (on Linux anyway). After that, I started cloning the repository both on Linux and Windows and tried performing some standard operations.

The first thing that surprised me was that when cloning the converted repository, I could only see the ‘master’ branch on the remote machine. It’s common practice for Git not to create any local branches other than master on clone, but usually you can do ‘git branch -a’ to see all the remote branches that are available, which show up as something like ‘origin/v1-6′ – you can then check them out to local branches. However, no branches other than ‘origin/master’ showed up, even though I knew they’d been converted. It turns out that git-svn converts all branches except master into remote branches in the converted repository, referencing the original Subversion URL – so very much like having cloned from another Git repository. That sort of makes sense, but in the context of a full conversion to a repository that is destined to become the upstream master, isn’t that useful. In practice what you need to do is after the git-svn conversion is complete, git checkout each of the branches that you care about in your converted repository, thus creating local branches in that repository which subsequent cloners will be able to checkout themselves.

So, once I’d figured this out I started to check out different branches to test if it had worked. At first it seemed to, when checking out the first branch (switching from master to v1-6 in a local clone from the conversion). When I came to try to switch back to master however, Git complained that I had modified files in my working directory. WTF? I’d only just checked out the clean copy of the v1-6 branch. But sure enough, git status told me I had 5 modified files. Diffing them showed no changes, and “git reset –hard” returned with no error, but git status still showed these files as modified. Bizarre. A git checkout -f still let me switch, but again after completion a set of other files showed up as modified. Switching back and forth (with -f) a few times revealed that the list of modified files after checkout was different each time. Again worried that this was a Windows thing, I tried checking out on my Linux machine instead (so at that stage the entire process, conversion to checkout, was done on Linux). But no, the same problem occurred – a random selection of 5-7 modified files on clean checkout.

This has raised some serious concerns about using Git for me. Firstly the flaky conversion which requires a bunch of extra steps just to get it to work at all, then the post-conversion bizarre behaviour of thinking files are modified when they’re not. I had none of these problems with smaller repositories, created from scratch or converted, which up until now I’d been using for testing (and Git had been winning me over in fact since it had been working well). But the bottom line is that this process needs to work reliably for the OGRE repository. If it doesn’t, it’s pretty much untenable.

Mercurial Conversion Experience

I started off with the in-built ‘hg convert’ process. It all went smoothly and took about 8 hours, and the resulting repository was mostly fine. However, the default behaviour is to process the revisions in an order which “produces the fewest jumps between branches in the commit log”. In practice, I found that this meant the revision log when reviewing multiple branches was badly jumbled and difficult to use; the use of the ‘–datesort’ option resolved this but increased the conversion time to just under 10 hours (still faster than msysGit but a lot slower than git on Linux).

The guys from BitBucket, who I’d talked to to see if they would offer free unlimited hosting for OGRE since we wouldn’t fit in the default 150MB limit (result was that they were super-friendly and offered not only that but lots of advice), suggested that I try hgsubversion instead. I was initially put off by their website suggesting it wasn’t fit for production use (they’ve removed this statement now), but BitBucket told me that was a little out of date, and in fact the Python project is using it for their conversion, which is obviously of major size. So, I gave it a shot and got some good help from the hgsubversion guys, and the results were great – 1hour 40 minutes from the Windows end (coincidentally the same speed Git managed on the local Linux machine), and the log view was properly ordered right off the bat.

The one remaining issue I had (and this is true of git-svn too) is that all of the branches are open-ended on conversion – that is, no record is made of merges that have been done between branches. That means you would have problems continuing a branch and then merging it, because Mercurial would think it has to merge everything from the point the branch was taken. Neither svnmerge or svn:merge properties are taken into account.

One way to resolve this is to manually create a merge point to close off the branches. The easiest way to do this is:

• Grab the default tip
• Open a command line and define a temporary environment variable “HGMERGE=internal:local”. This means that you want to keep the local files and throw away the other source when doing a merge, which is important for our dummy merge
• hg merge <source_branch> -y
  
• commit – only the .hgtags file should be modified, the rest of the commit is merely metadata alteration to close off the source_branch

Once you’ve done that, your branch is joined back to the trunk and you can carry on as before, any new commits to that branch will merge across cleanly. The only downside of this is that the merge is strictly at the wrong point – if you view the history in the trunk it won’t be technically accurate and you’ll need to use your commit messages as the real guide to the actual merges before the conversion.

A better way to do this would be to record the merges during the conversion, that is for merge commits in Subversion to have 2 parents. So far, none of the conversion tools read svnmerge or svn:merge metadata to implement this, but the standard ‘hg convert’ has an option called ‘–splicemap’ where you can specify merge points to be applied during the conversion. Unfortunately I’ve tried to use this twice so far, and both times it hasn’t worked (just silently done nothing). The documentation for –splicemap is not great so it could be I got the URLs wrong. But anyhow, following 2 failed attempts (20 hours! because this was the standard hg convert with –datesort) I decided I’d try to get a similar bit of functionality working in hgsubversion instead, since that’s much faster (1hr 40m a pop). Right now I’m hacking away on it to try to make this work, so far it’s not but I’ll let you know if I eventually succeed. One of the benefits of Mercurial is that it’s all in Python so it’s very easy to modify, compared to Git which runs all kinds of random scripts and executables, including sh and perl so it’s much more tangled to dig into.

Conclusions, so far

I started my DVCS evaluation very pro-Mercurial and very anti-Git. While working through my detailed use cases, a process which I’ve not quite completed yet, Git has grown on me a great deal, and I discovered a few things about Mercurial which I found a bit limiting at first, but which are mitigated via extensions – Rebase, Queues and Transplant particularly. My recent experience with more complicated, full-scale and imported repositories has once again gone in Mercurial’s favour though, and I saw a nastier side of Git – when it goes wrong, it’s a lot more difficult to figure out why. In contrast when I’ve had my Mercurial conversion crash – and I stress this only happened due to my own screw up, once because it ran overnight when my rsync kicked in and changed the repository under its feet, and a few times when I’ve been experimenting with hacking the Python to get the merges done – the reason has always been clear; a nice Python trace, and the repository was always intact anyhow – in the case of the core hg convert the conversion even restarted from where it left off once I’d fixed it.

If I were to graph my relative opinion of the two over the period I’ve been doing this so far, it would look something like this:

Git totally came up from behind and I was really starting to dig it, until it started freaking out on me with the conversion and I started to try to diagnose why and found it mostly unhelpful. Again I stress I’m not done with my tests yet, but I’m perhaps 75% of the way through now and the conversion problems I’ve had with Git in the last few days don’t look good. Bazaar, I’m afraid, is no longer likely to be part of the evaluation – it takes a long time to do these evaluations properly rather than just trivially, and our survey has indicated that it is the least commonly used among our community by a very large margin, so I’m focussing on the ones more users are likely to already be comfortable with.

The evaluation process continues…

I’m not sure if this is the intro or just a trailer, since the first game had an intro which led directly to the starting point of the first chapter, which worked well, which this one clearly doesn’t (unless they start you in absolute mahem which would not make sense). If this is the intro, then I have to say I preferred the intro from the first game, which was a bit more suspense and atmosphere and less chainsaws & explosions, but I suspect it’s just a marketing trailer and hence appealing to the attention-span-challenged is paramount. At least this movie, whatever it is, gives you a better peek at the new characters than we’ve had before.

One of the undersold characteristics of the first game was that the characters were genuinely likeable without ever needing to litter the game with cutscenes (beyond the short intro) – just the little snippets of in-game dialog and the AI behaviour (we play only 2-player most of the time) was enough to let you know what they were about, which is no mean feat: Bill was a gruff veteran who is too stubborn to heal himself, Francis was a surly biker who hates everything and kinda likes killing stuff, Louis was an everyman in the wrong place at the wrong time, and Zoey was a naive horror fan completely out of her depth. That’s just enough character to set the scene and get players happy to be embodying the roles in my view. Francis was my favourite in the first game, closely followed by Louis (“Do I look like one o’them?!!!!”) – in the sequel I’m already liking Coach and Ellis particularly. Looking forward to this!

I could hug Harmonix. They have lived up to their original promise to providing a large, ever-expanding and varied collection of tracks on Rock Band with the kind of fervour that I think even fans have been surprised by. Apart from a couple of odd cases (Lego Rock Band and Beatles: Rock Band – the former puzzling, the latter due to brand management insistence that The Beatles should be revered as gods and can’t be seen mixing with peasants) Harmonix have avoided fragmenting the content available as much as possible and the result is a lot of people who have no reason to buy another music game; in fact there’s a positive incentive not to. It makes games that don’t try to integrate their content look a bit backward – it’s like being forced to use a portable CD player when you’ve been used to having everything immediately available on your iPod – inconvenient and horribly outdated.

So with the release of the Queen Pack today we passed the 300 track mark on Rock Band (307 in fact), which is both awesome and a little scary. That’s not even a third of the current content available, and it’s likely to go up once the Rock Band Network comes online. Will we ever stop? Well, we never stop stuffing new tracks in our iPods, so I don’t see why we would stop buying Rock Band tracks for the forseeable future either.

In related news, corporalgregg, the best source for full-band HD previews of tracks got his account suspended again (he thinks by Activision because he posted a GH video with Kurt Cobain in it) so has opened another one. Still the best place to go to review new RB tracks you’re thinking of buying IMO, but it’s a shame all that history has been lost. Thanks, big corporate bully.

Before 2009, I’d never set foot in Germany before; not for any particular reason, I just hadn’t gotten around to it yet. However, thanks to gracious invitations to conferences I’ve now been twice. In May I went to Stuttgart for FMX, and last week I went to Munich for Qt Developer Days.

It was an enjoyable conference, as always the best part is just meeting other delegates, the sessions themselves are merely the icing on the cake. I shared my presenting slot (in which I showed a couple of applications that use Qt and Ogre together) with two other open source veterans from projects which I have a huge amount of respect for: Bill Hoffman, CTO at Kitware and the founder of CMake (which of course we use in Ogre now, so it was great that I had chance to have quite a few discussions with Bill), and Jean-Baptiste Kempf, Chairman of VideoLAN which is of course in charge of the excellent VLC.

It was also nice (not to mention flattering and somewhat humbling) to have random people I’ve never met before spontaneously say nice things about Ogre. One of the major curiosities of open source is that you never really know quite how many people have encountered & used your software; you get a sampling of that through your community forums etc, but it’s also clear that that only represents a portion of your user base. On the day I was wearing my Ogre T-shirt I had a number of people who were more peripherally involved in the community but who had had a good experience with Ogre, and were more than happy to tell me about it. Definitely a good feeling.

Perhaps most surprising of all though was getting a sizable donation to Ogre in person from a community member while I was there (I won’t mention who just in case he’d rather not be identified, he can post in the comments if he’s happy to). We had what I thought was a theoretical discussion at one of the dinners about how much we get charged by PayPal for donations, and I’d said that although it’s undesirable, any kind of electronic payment mechanism has a cost (merchant accounts, bank transfers all come with some kind of charge). I jokingly said that the way you’d avoid the most charges would be mailing cash in an envelope, although that had it’s own risks. I thought nothing more of it, until I saw him the next day when he presented me with an envelope with a donation in it! Way more than I expected too, enough to push him straight to a Platinum sponsor. Turns out he’d just got his deposit back on a flat he had been renting, and decided to donate that to us in the absence of any code contributions, since Ogre had helped him at university and subsequently in getting a job. I have to admit, I was a little lost for words at that! His donation will definitely help cover the server running costs in the coming few months.

Back to the conference subject, Qt, the conference reinforced my opinion that it’s the best cross-platform UI system out there for C++ developers. It was great to see the range of applications that were being developed on it these days, including a coffee machine which was serving custom beverages in the dining area via a Qt interface. Obviously the Nokia acquisition has meant that they’re keen to move into more dynamic, touch-based interfaces too now, which will obviously power new phones in more interesting ways, but it was clear that they remained committed to a huge range of application targets. Well, except iPhone anyway, that was definitely the elephant in the room – occasionally mentioned but mostly avoided

Obviously Qt’s switch to LGPL this year will have a huge impact on adoption rates. One of the things that had concerned me though is that there’s a clause in the commercial license for Qt that requires you to decide between using the commercial license and the LGPL before you start developing. The reason given for this is that Qt is licensed on a per-developer basis, so if you could wait until deployment to choose the commercial license, you could scale back your team and pay less than you really should have done, which is why you have to decide up-front. I could understand this argument, but in my experience, perfect foresight is impractical and conditions can often change, so making a once-and-for-all choice before a line of code is written did not seem realistic in some cases. Also since the principle was that the entire team must use the same license, I was wondering about the practical implications of say, a commercial outfit leveraging some pre-written code by people using the LGPL version (such as QtOgre). Qt want to encourage greater community involvement (which was the reason for me being invited to the conference after all), so not allowing this seemed to go against the kind of broader adoption they were chasing.

To try to answer these questions, I went to the legal presentation and put this question to the speaker afterwards. Luckily, she mostly allayed my fears on these two issues. On the ‘circumstances change’ issue, the principle must remain that, because of the per-developer licensing, you should make your decision up-front, but if for whatever reason, and in good faith, conditions change (such as suddenly having to target a platform where LGPL is not practical), then some kind of agreement can be reached, such as by paying commercial fees for all developers historically on that project so it comes out the same as if you had opted for the commercial license originally. In addition, she didn’t think there would be a problem with community code re-use for commercial licensees provided this was mentioned during the commercial licensing process; she accepted that greater adoption is what they want, and community development inherently complicates the previous assumption that one team will be responsible for absolutely every aspect end-to-end.

So, a good conference overall. Now, I’m back to continue work on Ogre 1.7.

I’ve been pushing quite hard to get this done before I head off to Qt DevDays next week, and luckily it all came together in the last few days:

Some of the notable back-of-the-box (if there was a box) items:

• Upgrade to SpeedTree v5 – supporting all the great new features. See the SpeedTree site for more details on this release.
• More lighting options – Ambient Occlusion, Ambient Contrast, Specular Lighting, Transmission Lighting, Global Light Scalar, HDR.
• Improved LOD fading – LOD transitions are now implemented via less perceptible techniques thanks to SpeedTree v5.
• Dynamic soft self-shadowing via depth shadowmaps – (was also demonstrated on SpeedTree 4.2 in OgreSpeedTree 1.1.0)
• Improved alpha to coverage support – alpha to coverage rendering has been significantly improved and is now enabled by default (you must render with at least 2xMSAA to see the effect), resulting in significantly smoother foliage edges and smoother fade transitions.

I’m just really, really glad to have got this done. SpeedTree v5 was quite a big change to handle, but hugely worthwhile, the guys at IDV have done a great job. I made the choice from v1 to do a ‘deep’ integration (ie all objects are first-party Ogre objects, everything uses Materials and RenderQueues properly, etc), which made the transition considerably more time consuming than using the higher level pass-through interfaces, so this took some effort. I like it this way though, it means it’s a ‘real’ integration as far as I’m concerned, not just a simplistic bolt-on.

There’s still more to do, not least of which a demo that’s more interesting than just a technical performance test But at least I can tick off one of the major things on my TODO now. I’d been putting in quite a few extra hours to try to handle this, and my Qt presentation preparation, and Ogre, and consultancy, and it has taken its toll a bit – I’ve been spending more time at the desk and think that was a contributing factor to me straining my back at the gym last weekend. Hopefully that’s just temporary, I’ve been a lot better these last few months.

Hope you like the shots anyway. I know, I’m pimping them all over the place in my Twitter, here and on the Ogre site, but a guys gotta make a living, right?