This is really more of a follow on from my previous article, Preparing for Parallelism. Some of the comments wanted more explanation, and an example of what I actually mean about the likes of incorrect data and controlling execution context.

What I explained was a tips for a component/entity system, a task based one: concurrent systems, running in parallel, and communicating effectively between each other.  Fine-grained parallelism does not apply. I also mentioned the fact that being able to accept, and properly deal with out of date ‘incorrect’ data can lead to some novel opportunities for parallelism.

Not to say the methods I employ lead to perfect parallelism and scalability, I do believe they allow for implementing a level of concurrent operation in a cost-effective manner on current hardware, without the hidden quirks that locks can have creep up on your frame profile. I include ‘lock-free algorithms’ in that, as those can cause nasty contention issues. If you disagree, please comment, as I’m really interested in hearing other opinions and experiences on the matter.

First of all, what changes are those that really make concurrent execution hard, even if you allow for reading data which is possibly a frame out of date?

You can read the full article over at AltDevBlogADay.com.

Don’t worry, just parallelize everything and have it run over all the cores.

Ouch. This is going to hurt. Invariably it does; when you end up having that really hard to find heap corruption issue, or when those odd pauses creep into the profiler when calling into that middleware. Parallel execution is tough at the best of times, and I think it is harder in gamecode where the notion of a game-frame is key. Something I have learned over the years looking at codebases is that many developers do very little groundwork in preparation for parallel operation. Laying some clear code foundations and keeping to a small set of rules can result in less pain encountered in the long term.  In this post, I’m going to share the main tips/rules I try to abide by when doing that job; something I find myself doing often to increase the prospect of allowing more parallelism.

These tips allow designing systems for parallel execution simpler, but it is still not easy street. You need deep knowledge of the systems you are working with, the data it touches, and above all understand what makes things inherently serial. Also you need to understand how you are going to achieve the parallelism; are you using multiple threads running over multiple jobs, running a large subsystem for the most part of a frame, or are you going to use the SPUs?

You can read the whole post over at altdevblogaday.com, where I am a contributor.

DESIGN PATTERNS!

Design patterns are something which have given me, and certainly many of my coworkers, a mountain of grief when it comes to getting performance from code. I can remember it being taught as some sort of rule book in University, something you can refer to when you have a certain logic issue, and then implement that pattern. Unfortunately this ideal exists now in many graduates, and therefore quite ingrained into current programming circles. In my opinion we have a bad habit: a design pattern copy-paste culture.

I’m not going to go into why some design patterns can cause havoc when you come to optimize; hell some may make it easier. It’s basically the lack of thought that now goes into implementations, meaning for example a generic pattern may be applied to a problem which really doesn’t need it. But this code is in the foundation of systems usually, the hardest part to modify given tight deadlines late on in a project.

Some may say that this runtime performance drop is a worthwhile price to pay for clean code; of course that is certainly not true in my line of work. For me the solving of a problem in a really efficient way for the hardware makes things nice, for others it’s hiding everything under a generic base, and having the source ‘look’ nice (whatever the bloody hell that means). Don’t get me wrong, bad implementations have always existed; but I think the way design patterns are being taught is not helping.

Really, this is lie #1 from Mike Actons GDC2010 “Three Big Lies in Game Development” : Software is not a platform.

One persons clean source code is someones elses nightmare, another’s ‘bad’ source being an abomination to others. The fact here though is that regardless of how the source ‘looks and feels’, the compiler can generate pretty good source code for both implementations, and can try to optimize things as much as possible – obviously to the extent which the logic of the solution allows.  The real problem here is that a solution is defined by the logic, something the compiler cannot modify.

So,

Whilst the compiler can generate ‘good’ machine code from ‘bad’ source code, it can not replace bad logic with good logic.

I think that about says it all, really. Before you go pasting that Design Pattern into your project, really think: Does this solve the problem in the best possible way for my hardware?

class Vector4 { public:  float x ALIGN(16), y, z, w;       /* insert operators, constructors, etc here */ };

One way to get it working is to union your vector float data member with the four scalar components, which at first glance seems like it should work fine, but in my experience most compilers just don’t seem to produce even semi-optimal code, so that option is completely out.

Most implementations using vmx types will offer  .SetX(float) and .GetX() methods which use correct intrinsics as to be optimal, but when migrating code over, having to separate the accesses into distinct read and write operations and handle them using different methods can be very time consuming. Sadly, there will always be source changes, but I would like to keep it to a minimum, so changing .x to be .x() would be ok, but it needs to work for both reading and writing.

One method is to have .x() return a float reference to the data at that element of the vector, like &vec[1], blah blah. When I read this though it always worries me, as the statement involves addressof, which then implies memory. The compiler may be able to optimise as to not force anything into memory, but most times it doesn’t seem to be able to. This can always be our backup plan.

What I attempted was to make use of a temporary class returned by the x() method of the vector to indirectly modify a reference to our real vmx vector. Here is the basic code (just typed out, so sorry if it doesn’t compile-first-time on a copy and paste – and sorry for the bad source formatting throughout, I need to set up some sort of WordPress plugin for that – Thanks to spoofmeat in the comments for directing me to the correct sourcecode tag!

VMXVectorClass {
  vec_float4 m128;

  template <int element>
  class dScalar {
  public:
    vec_float4& v;
    dScalar(vec_float4& _v) : v(_v) {}

    inline operator float() const { 
      return vec_extract(v,element);
    }

    inline float operator=(float f) { 
      vec_insert(f,v,element);return f;
    }
  }

  inline dScalar<0> x() { return dScalar<0>(m128); }

  inline dScalar<1> y() { return dScalar<1>(m128); }

  inline dScalar<2> z() { return dScalar<2>(m128); }

  /*the rest of the vector goes here*/

} __attribute__(aligned16, vecreturn, passinvector, etc);

I’d like feedback on what other folk have tried, and if they know of a good benchmark I could try this method on, especially interested to see if it is indeed any better than the simple float& x() version. I had a look at some of the code generated and it didn’t seem too different from .SetX and .GetX explicitly, but a run-time example to test would be best, one that mixed significant non-scalar usage of the vectors along with the accessors, to make sure things were not being forced out of registers.

An interesting side-effect from using a temporary class: if it did turn out you needed to then migrate further over to the .SetX and .GetX methods at a later date, you could use this class to identify the cases that needed .SetX by adding the deprecated attribute to the operator= method, and then just work through the warnings.

@moggy has set up the twitter account, and it also has a facebook page. The first meetup is on the 30th November at The Cumberland Bar on Cumberland Street, it is sure to be an awesome evening of fun filled drinks and gamedevvery.

See you there!

Watch it, its funny and informative. You may see a certain Colin in it for about 5 seconds, actually.  It was rated 18 when shown at the festival, so expect the usual antics!

This was my first game project, a modification for Return to Castle Wolfenstein. I was Lead User Interface, as well as a level designer. It was great fun, and ended up being a nice total conversion, even if it didn’t last too long popularity wise. We got around 20,000 downloads within 48 hours of release, and (somebody correct me if they know better), we were the first game to feature wave-based parachute spawning! It is a great feeling to see how people had fun with your own creations – one of the reasons for my interest in the games industry.

We even got reviewed in PC Gamer and PC Format, scans following.

Unfortunately the site is not online any more. It is still up on archive.org at wolftactics.com, if anyone is bored.

I stumbled upon this about two years ago. Since then it has made steady progress, and it is quite fun – even if you don’t have a wheel and pedals. Mouse control can revolve around quadrants of the screen for acceleration, breaking and steering. It may sound dull/weird here but its a nice way of controlling the car.

There are hundreds of cars and many community developed tracks out there, ranging from in development cityscapes to a fully-fledged version of the Nürburgring.

Go download it. Now!

Last year I attended the event looking for that jump into the games industry. A month or so later, I had secured a job with a games technology company specialising in one of my main interests. This year I was lucky enough to attend the event in a professional capacity.

The event begins with a free for all. Companies have stalls for showing off products and chatting with attendees. CV’s and demo reels are distributed to companies from those eager to strut their stuff. Something I noticed this year was the amount of animators and artists in attendance. This fits with games now requiring huge amount of assets in these fields as the technology develops; allowing for the intricate detail gamers demand.

I was invited to participate on the panel of two industry question and answer sessions, which were held later in the afternoon. ‘Meet the team’ was the first of these, detailing roles within the industry. One of the questions was how we entered the industry, and I quite happily praised the event – it being my own stepping stone. This was my first public speaking experience, and I was extremely nervous. Hearing my voice over the PA was strange, but as people say confidence grows, yaddy yadda, etc. The second session was on ‘Whats around the corner?’, a discussion on what the future holds for games. A lot of fuss was made over MMORPGs, which I quite honestly don’t care for in the slightest. An interesting point was made about Flash developers being in demand, and that the platform could in fact over the next few years make a leap into the mobile platforms currently dominated by Java.

In all, a great day in Dundee. STV turned up at one point and were filming various areas, but didn’t see anything on the news relating to it (I get the west of Scotland reports). They do have a short piece on their website, however.

Special thanks to Brian Baglow of scottishgames.biz who chaired the second session I was on, and made me laugh with the petition situated at his stand for this particular atrocity.