Systematic Gaming

July 2, 2009

Asset Management – Processing

Filed under: asset management, game programming — Tags: , , — systematicgaming @ 4:21 am

Last time we looked into the lowest levels of asset management, which can be handled by referencing counting and intelligent loading.  With the next level, the processing layer, we look at how we prepare assets for our runtime.  This is an important step and where a lot of optimization occurs.  We can break the processing layer down into a few distinct stages:

  • Asset referencing
  • Building (or baking)
  • Packing



January 31, 2009

Game-Tool Communication

Filed under: game programming, workflow — Tags: , , — systematicgaming @ 12:20 am

Modern games are extremely content heavy – most of the people on a game team are part of the art or design departments.  The larger a the team get the greater the portion of content producers becomes, and the trend will only continue.

So what does this have to do with game systems programming?

The more content you game has the better your tools have to be.  The best tools are robust, efficient and as seamless as possible.  The key to a seamless workflow is close integration with your tools and game engine.

There are basically two ways to accomplish this:

  • Direct integration of the game engine with the tool
  • Remote integration via a communication layer


December 23, 2008

Patterns in Performance: Cache Pressure

Filed under: game programming, optimization — Tags: , — systematicgaming @ 3:16 am

I’ve been mentioning memory and the cache a lot, because proper cache utilization really is a critical to good performance. This time we’ll look at cache pressure – a term that refers to overworking the memory cache with too many or wasteful memory accesses.  Basically putting pressure on the memory cache means you’re wasting time accessing more memory than you need to.  The main cause is inefficient data access, often by using data structures that are too large, or too sparse reducing any benefit from memory locality.


October 23, 2008

Game Optimization 101

Filed under: game programming, optimization — Tags: , , — systematicgaming @ 6:23 am

In this article we’ll look at the process of optimization.  There’s no single way to optimize a game, but there are optimization methodologies to follow, which will help us prioritize our optimization strategy.

In previous articles we looked at how we can profile parts of our game.  At this point we only know how long sections of our game code are taking.  We haven’t looked into how to use this information to make our game faster.  We need to know how to target the slow parts of our game.

The process of optimization is two parts methodology, one part knowledge and one part intuition.  We’ll start with a simple process and show how it can help us optimize effectively.


October 12, 2008

Game Profiling 102

Filed under: game programming, profiling — Tags: , — systematicgaming @ 1:41 am

In the last article we implemented a simple stopwatch, but didn’t really do much with our timing data other than print it out.  Simply printing out our timing isn’t very helpful either, first of all you can’t always see standard output on a console, and secondly it’s a pretty awkward way to collect our data, we can do much better.

Our goal this time is to design a system that allows us to profile out entire game and display the results in realtime.   We’re not going for detailed performance data, just a high level picture of our game’s performance.  The key goals are:

  • Collect data from each major subsystem
  • Present our profiling data to the user in an understandable format
  • Keep a multi-frame history of our data to detect performance spikes


September 30, 2008

Game Profiling 101

Filed under: game programming, profiling — Tags: , — systematicgaming @ 8:21 am

On this blog I keep mentioning efficiency, resource usage and optimization as key requirement for any well designed game system.  When discussing memory I put a large emphasis on tracking and profiling memory usage.

This time we’ll look at the various ways we can profile our game. We’ll also look at how to instrument our game for custom profiling, focusing on CPU usage.


September 18, 2008

Load Times: Layouts and More

Filed under: file management, game programming — Tags: , — systematicgaming @ 11:41 pm

We know that seek time is a major problem with optical media, so we’ll need to reduce it as much as possible to achieve our fast load times. There’s really only so much we can do to solve the problem

  • Seek less by reading less files
  • Seek less by organizing our files better

We’ve seen how to reduce the number of files read by using packfiles, which also helped by seek times a little bit.  Since seek times are related to the physical distance and direction a drive head has to move, we’ll look at how to reduce seek times by arranging files on disc to minimize their distance.

We’ll also wrap up this series on load times with some tips and tricks to get that last bit of optimization.


September 16, 2008

Load Times: Packfiles

Filed under: file management, game programming — Tags: , — systematicgaming @ 5:27 am

A packfile is simply a single file containing one or more other files. They’re very useful for load times, and can be used in a number of ways. We can put files that get loaded together into a single packfile and load them at once, such as putting the data for a single level into a single packfile and loading in a single read. We can also put our entire filesystem into one or more packfiles, which lets us handle compression cleanly as well as making distribution easier.

So what do we need to do to create a packfile? No much:

  • File name and path, usually relative to a specific root directory
  • File size and compressed size

In this article now we’ll look at how to implement a packfile system.


September 11, 2008

Load Times: Compression

Filed under: game programming, memory management — Tags: , — systematicgaming @ 11:49 am

We’ve gone over what happens when we read files, and came up with some ways to reduce stalls between our game and the OS and hardware. We designed a file manager that allows us to read files asynchronously and remove all the wait time. What next?

Well the simplest way to reduce load times is to load less data. If we simply compress our data we’ll reduce load times a lot. General compression algorithms can often get a 50% or more reduction in file size, which translates directly into reduced load time.


September 8, 2008

Load Times: Asynchronous Loading

Filed under: file management, game programming — Tags: , — systematicgaming @ 5:26 am

We looked at how files are read earlier, and saw how much time is wasted by waiting for file operations to finish. So the only real solution is to not wait for operations to complete. This is called asynchronous reading, where the file operation happens in parallel with our game, controlled by the OS.

Asynchronous file loading requires more structure and organization than normal file reading, so we’ll need to create a file manager to provide portable asynchronous loading. We will need to change how we handle file data inside out game to support this functionality. But it’s worth it because it gives us a huge win in load times, and in the end gives us a more robust game engine as a bonus.


September 1, 2008

Load Times: Reading Files

Filed under: file management, game programming — Tags: , — systematicgaming @ 1:23 am

Load times are a bane of console games, every game has load screens and nobody likes staring at them. Some games try to hide load times under cut-scenes or flashy effects. The elevator scenes in Mass Effect are a clever trick and are better than a “Loading” icon, but still get repetitive and players do feel like they’re standing still. Really the only solution is to make the load time as short as possible.

With console games content getting larger and larger and disc speeds not keeping pace, load times are aren’t getting any shorter. To get the shortest load times possible we need to handle file loading intelligently.

August 29, 2008

Functional Gaming: Writing a game in OCaml

Filed under: game programming, ocaml — Tags: , , — systematicgaming @ 2:25 am

If you’re following the latest trends in multi-threading you may have seen some renewed interest in functional programming.

When you bring up functional programming you’ll often get one of two opinions:

  • It’s the silver bullet of parallelism, and will allow automatic parallelizing of code, and also is easier to read, write and creates less bugs.
  • I remember those from university, they made my head hurt and ears bleed. Nobody uses those type of languages in the real world.

I find you’ll get more of the second responses, because really, who codes in functional languages outside of university?

Of course I’m biased since I generally hang out with other game programmers. If you program for consoles you do it in C or C++, since there aren’t any other compliers provided. So nobody I know uses functional programming on a daily basis.

That said, I’m intrigued by the possibilities offered by functional programming. I can see how they can parallelize well, and they allow you to write some clean mathematical code. To form a more informed opinion I decided to start exploring the world of functional programming.


August 26, 2008

Memory Management: Summary

Filed under: game programming, memory management — Tags: , — systematicgaming @ 2:59 am

This series hasn’t been much more than a quick over of the memory management issues facing console game development. Hopefully it’s been informative, but keep in mind it’s only an introduction and was fairly light on many of the nitty-gritty implementations details.

To wrap up this series here’s a few quick topics that deserve mentioning, as well as some links to some suggested reading.


August 25, 2008

Memory Management: Budgets, Tracking and Profiling

Filed under: game programming, memory management — Tags: , — systematicgaming @ 2:16 am

The last few entries in this series mostly focused on memory allocation. However allocation is only one part of memory management. To create a complete memory management system we need to do a lot more than allocate and free blocks of memory. We need to look at memory as a system wide resource. This involves

  • budgeting memory for the various game sub-systems
  • tracking memory use, to ensure budgets are honoured and memory doesn’t leak
  • profiling memory use to look for worst case spots in or program and trend memory usage over time

We’ll look into how we can enhance the allocation interface we’ve designed to help accomplish these goals. As well, we’ll see how these features aid us in managing memory system-wide.


August 19, 2008

Memory Management: Design

Filed under: game programming, memory management — Tags: , , — systematicgaming @ 12:29 pm

We’ve reviewed the different types of memory in part one and looked at issues specific to consoles in part two. Now we’re ready to start designing our own memory manager. Lets review our requirements:

  • Our memory manager must be fast and efficient. We don’t want to waste CPU cycles or extra bytes of RAM managing memory.
  • We need to allow memory to be allocated with arbitrary alignment.
  • We need to support managing multiple physical memory heaps as well as the ability to support both internal and external heap managers.

These are the main requirements we have above and beyond the basic functionality of allocating and releasing memory.


August 15, 2008

Memory Management: Consoles

Filed under: game programming, memory management — Tags: , , — systematicgaming @ 9:23 am

In part one we described the main types of memory. This time we’ll take a look at the memory management issues specific to consoles, or issues that are at least more prevalent in console game programming. The key differences between your regular PC and consoles are:

  • No virtual memory, which means once you’re out of memory, you’re out of memory. No swap file is going to save you on a console. Also, this makes memory fragmentation a serious concern.
  • Multiple physical memory types. On the PC you have RAM and video RAM, but you have a video driver that manages it for you, not so on consoles.
  • Memory alignment is also a problem on consoles. The x86 CPU is very forgiving. However console CPUs are generally stricter. Alignment is also very important for performance.

Now let’s take a look at these issues and others in more detail.


August 7, 2008

Memory Management: Overview of Memory

Filed under: game programming, memory management — Tags: , , — systematicgaming @ 2:19 pm

Before we can really delve into the design of a memory management system we need to have a solid understanding of memory. In this post we’ll go over different types of memory and look at how they are used in your average program. We’ll also take a look at the main issues faced with each memory type, such as lifetime, scope and problems such as fragmentation.

Disclaimer: You’ll see some code samples in the following article, they’re in pseudo-C, not compilable or even compliant. They’re included for illustration and discussion purposes.


August 5, 2008

Memory Management: Introduction

Filed under: game programming, memory management — Tags: , , — systematicgaming @ 2:16 pm

Memory management is a large part of systems programming for games. Especially on consoles where memory is a limited resource.

The main problem with memory is that there’s never enough. Modern consoles (like the Xbox 360 and PS3) have about 512MB of memory. This might seem like a lot compared to the 32MB of the PS2, but really isn’t that great compared to a PC, or the requirements of modern games. Additionally, consoles don’t generally support virtual memory, a feature of PCs which let the operating system use the hard disk as additional RAM when needed. The end result is that console games have many extra constraints and must take over the burden of managing their own memory more closely than normal PC applications.

Over the next few posts we will examine the basic memory management issues faced with console programming. In the process we will examine the goals and design of a modern game memory management system. The focus will be on how we manage memory within the complexities of a modern game development environment and how to make the best use of the limited resources of consoles.

Part One: Overview of Memory – A look at different memory types and how they are handled by compilers and applications.

Part Two: Consoles – What’s so special about consoles? We’ll look at special considerations needed for console games.

Part Three: Design – We’ll create a high level design of a memory allocation system.

Part Four: Budgets, Tracking and Profiling – So we can allocate memory, what else do we need?

Part Five: Summary – Wrapping up the series, we’ll also go over some more advanced topics for future consideration.

Systems Programming

Filed under: game programming — Tags: — systematicgaming @ 1:31 pm

Systems programming is a little written about area of game programming. One goal of this blog is to expose the world to game system programming. Along the way we’ll explore the problem domains faced by a game system programmer. System programming involves everything from multi-platform development, concurrency, memory management, file systems, profiling and optimization and many other domains.

Each and every game has its share of system programmers. Whether an official title or role, it’s work that must be done. From compliers to platform restrictions much time and effort is dedicated to systems programming. In between we’ll explore all aspects of game systems programming focusing on the issues, design and implementation of various sub-systems of the modern game engine.

The focus of his blog will be designing and devloping game systems for consoles such as the 360, PS3 and Wii. Hopefully along the way you’ll understand and appreciate the effort that goes into designing a game system.

Blog at