SWAT: the last few bits

This is the last post in my series on how SWAT: Global Strike Team was made. See the first article for more information on these posts.

In this post I’m going to blast through the remaining parts of the code. I was less involved with these so apologies for the vagueness; it’s been quite a while since I’ve thought about them.

Collision System

A collision system’s job is to determine quickly and effectively when dynamic objects intersect the scenery and each other and prevents you being able to walk through walls and so on. Importantly for a game like SWAT, our collision system also allowed us to trace rays through the scene and work out what they hit — used in the dynamic shadow calculation as well as to work out where all the bullets end up hitting.

Filed under: Games
Posted at 19:05:00 BST on 16th April 2010.

Rendering in SWAT: PlayStation 2

Last time I went into considerable detail about how Okre’s Xbox renderer worked. In this post I’m going to explain how we got Okre running on PlayStation 2.

The PS2 was a powerful but limited machine. Its speed at rendering to the screen was unsurpassed at the time, but the blending it could do was very limited indeed. Where the Xbox could sample up to four textures and blend them arbitrarily with each other and the current screen contents, the PS2 could only sample a single texture, and either add or alpha blend with the screen. In terms of per-vertex calculations, the PlayStation 2 had a general purpose processor (called VU1) to process vertices, compared to the Xbox’s vertex shader which had a limited instruction set.

As mentioned in the introduction, we were able to leverage Argonaut’s existing PlayStation 2 technology, notably the code that ran Lego Bionicles and I-Ninja1. This meant the most complicated parts had already been written — notably the clipper which was a masterpiece of assembler by Carl Graham (co-designer of the SuperFX chip). The Xbox clipped geometry in hardware whereas the PS2 had to use software clipping, and would crash horribly if got it wrong and let it draw too far off the sides of the screen.

Filed under: Games
Posted at 09:15:00 BST on 31st March 2010.

Rendering in SWAT: Xbox

In this post I’ll talk a bit about how SWAT: Global Strike Team’s rendering system worked. For more of an overview and the other posts in this series, see the introduction. SWAT’s renderer was born and bred on the Xbox, so first I’m going to explain how our Xbox renderer worked. I’ll save how we crowbarred this onto a PlayStation 2 for the next post.

Xbox rendering pipeline

Okre used a pretty standard lighting model (called Phong shading), where light is considered to come from three sources:

Okre’s overall lighting and texture for a single point on in space was, roughly:

Filed under: Games
Posted at 22:15:00 GMT on 21st March 2010.

SWAT's lighting system

This is part three of my game development posts, following on from my post on the artwork in SWAT.

One of the most novel aspects of Okre was its treatment of lighting. We wanted to take full advantage of all the cool pixel and vertex shader technology at our disposal on Xbox, so per-pixel lighting was a given. Additionally, from a game point of view we wanted to be able to let the player shoot out the lights to plunge the enemies into darkness, so that was another consideration. Finally, we wanted a proper shadowing solution that didn’t rely on the texture-based solution of the time — lightmaps, as used in Quake and so on. We didn’t think we could store all the lightmaps for a single level in memory, as our levels were outdoor and rather sprawling.

With that in mind, we considered generating the static scenery shadows geometrically. Nik worked his magic and came up with a solution. In a lengthy, offline process:

  1. For every light in the game, find all the scenery triangles that face the light and are within that light’s range.
  2. For each triangle, calculate the shadow volume that it casts. Clip all other triangles against this volume, and discard the parts that are inside it.
  3. Process and store this set of triangles as another piece of geometry, creating triangle strips and so on.
  4. This data will be used to draw the geometry lit by this light, where each light’s contribution to the scene is added on one after another. This is described in detail in my next post.
Filed under: Games
Posted at 07:55:00 GMT on 11th March 2010.

Game Development: SWAT's artwork

A continuation of my posts on SWAT, extending on last month’s post.

During the early stages of development of the Xbox engine, another project started up and we decided to share the rendering technology. That project was called “Orchid”, and we named the engine we shared “Okre” for “Orchid and Kleaners Rendering Engine.” Of course, a much cooler name would have been “Kore”, but by the time we realised that it was too late!

The graphics coder on that project was Nik Hemmings (with whom many years later I started ProFactor). His input was critical in the development of Okre and he was single-handedly responsible for the shared animation system Okas1, which was used on many other Argonaut products.

Filed under: Games
Posted at 20:50:00 GMT on 2nd March 2010.

Game Development: SWAT

It’s been a long while since I’ve wrote anything worthwhile on this blog. After chatting with some workmates about life in the games industry it occurred to me that one of the more interesting things I could post about is some of the things I got up to back in the day.

Image of SWAT: Global Strike Team - an outdoor scene

One of my favourite games to work on was SWAT: Global Strike Team. It was released on both Xbox and Playstation 2, and got an average 69 (PS2/Xbox) on MetaCritic — not the best score, but not embarrassing. Over the next few posts I’m going to go over how we came up with the idea and how that changed as the project went on, what tools we built and used to make it, and as much as I can remember from the programming point of view. I was one of the graphics coders, so my memory is somewhat skewed in the graphics direction, but I’ll try and cover everything.

Important Note

Filed under: Games
Posted at 10:05:00 GMT on 26th February 2010.

About Matt Godbolt

Matt Godbolt is a C++ developer working in Chicago for Aquatic. Follow him on Mastodon.