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.

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-Ninja¹. 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.

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:

• Ambient light: a constant amount of light received by all surfaces. It approximates the general background amount of light that’s bounced everywhere. A little like the light you get on a cloudy day; it has no obvious direction but just lights everything evenly.
• Diffuse light: a contribution from each light that depends on the distance from the light and the angle between a surface and the light. The more directly the light hits the surface, the brighter it is. A surface for whom the light only just grazes is hardly lit at all.
• Specular light: the “shiny” part of the lighting, sometimes called specular highlights. It depends on the distance from each light, and the angle between the camera, the light and the surface. It represents the light that bounces directly off the surface straight into the camera.

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

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.

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 Okas¹, which was used on many other Argonaut products.

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.

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