On the surface, consoles look a lot like any other platform. The first Xbox was nearly identical to a mid-range gaming PC of the era—even down to its size. The PS3, Wii, and Xbox 360 behave a lot like the computer on your desk. They download software updates, run applications, allow you to play media, access the Internet, and a lot more. In some cases (such as with XNA or the Net Yaroze or less legitimately with homebrew), it’s possible for users to run their own applications on them.
Don’t be fooled. Deep down, a console like the 360 has a lot more in common with an NES than it does with your desktop. Consoles build off of 30 years of hard-won game development knowledge. They may have operating systems and mass storage instead of on-cartridge hardware and satellite modems, but they resemble consumer PCs as much as an Ariel Atom resembles a Honda Accord.
This chapter will cover the key differences between console performance tuning and the PC-oriented optimization techniques we have discussed up until now. Fundamentally, the same basic techniques of profiling, identifying the bottleneck, and tuning still apply. But consoles let you get a lot closer to the hardware and build code that takes better advantage of what the hardware can do.
A quick disclaimer: The console world is highly NDA’ed, and as a result we cannot give code samples, performance numbers, or development information beyond what is publicly available. All of the performance tests and optimization techniques from the rest of this book still apply, of course. But you will have to run tests with your own development hardware to get real-world numbers, and read and review the documentation from the console vendor in order to learn the details of what its hardware is capable of.
What are the defining characteristics of consoles as far as performance goes?
Low-level hardware access: On the NES, you had direct access to the rasterization chips. On a 360, you have direct access to the internal data structures on which the GPU operates. Abstraction layers that are mandatory when you have to support 10 different hardware manufacturers become superfluous on a console.
Fast bus: Consoles routinely achieve memory transfer rates far in excess of PC games. When you have limited hardware, the best way to maximize it is to push as much data through it as possible.
Fast memory: Memory is expensive, and when you are only running a single app, lots of memory isn’t a big win. Consoles tend toward small amounts of fast memory so they can get the most out of it (see “fast bus”).
Specialized hardware: The NES had specialized processing via chips on the cartridge. The PS3 has Cell processors. The Xbox 360 has an extended Altivec instruction set. The Super Nintendo had a custom audio synthesis chip. Consoles wouldn’t be consoles without specialized hardware.
Homogeneous: Every console has the same capabilities and hardware. You don’t have to worry about supporting 10 different driver versions or eight different GPU vendors. There is one GPU, one set of drivers, and while there may be updates, a major part of the console promise is that it will run all games correctly even if the internals are updated.
Contractual quality: Console vendors are the gatekeepers. Only software they approve gets out to the market. The value proposition of a console is as much due to its quality standards as its underlying hardware. As a result, console vendors require you to meet certain quality and performance standards before they will allow you to ship your game.
All of these factors combine to make console development a unique beast. Naturally, if you are a good PC developer, it will not take too long to pick everything up. But you have to be willing to rethink your assumptions and start from zero if you want to really learn the system and get maximum performance.
While many assumptions change on consoles, a lot stays just the same as it does everywhere else. You might want to review the first four chapters of this book, but let us stress a few things. First, there is no substitute for careful profiling before you start any optimization. For every clever PC performance hack, there are 10 more on consoles. Focus on the big problems first.
Second, do your homework. Consoles come with a lot of performance-oriented documentation explaining all their cool features. Use this as a starting point to see what is possible, but do your own tests to make sure that real-world wins match the theoretical claims. The guys doing this performance work are smart, but you can never tell for sure until you try it in your own situation. Documentation can be outdated, wrong, or just inapplicable to your situation.
Finally, keep your eye on the goals of the project. Figure out your performance budget early on—both in the context of what the game needs as well as what the console vendor requires—and make sure you stick to it.
You can walk on the razor’s edge of performance when you do console development. While there will be some limits, they are a great deal more generous than you get on PC development. You can rely on using 100% of a console’s capabilities, instead of having to cater to the lowest common denominator as you must in the PC market.
Because you have low-level access, you can also cut corners in ways that aren’t an option on the PC. Console games have historically done all sorts of strange things, like keeping memory images on disk, and loading them, pointers and all, in a single IO request, or running important bits of game logic on sound controllers, or using spare space in system data structures to get a few extra bytes of RAM.
This is probably the biggest difference between PC and console development. By making everything permissible, modest hardware can achieve as much or more than much more capable systems. All it takes are the skill and insight to squeeze out the last bit of performance from a fixed target.
Do your research and use everything you can.
Consoles give you low-level access to the hardware. As a side effect of this, while they have limited OS and driver APIs, they are typically cut down compared to consumer offerings. Many features are removed entirely. Other features are simplified to fit the console’s focus or to enhance performance.
Every consumer system runs a complex operating system designed to shield programs from each other and protect the hardware and user. Software may be poorly written or malicious, and as a result a lot of error checking must be done so that the system continues to function correctly. Even well-written software has to share resources, adding layers of virtualization and indirection to common operations.
On early consoles, there was no OS. The NES, for instance, booted and directly executed code without any intermediate layers at all. Since only Nintendo could manufacture the cartridges that held the games, the physical interface acted as DRM to prevent untrusted code from running. In addition, since the hardware didn’t preserve state across resets, it was very difficult for games to do any permanent damage even if they did do something unexpected.
On modern consoles, there is a lot of complex software that runs to give the user a pleasant shell experience. In addition, there is an OS that runs underneath the game to provide useful services. DRM is also a big concern, since games can be downloaded off the Internet or loaded from other media. Optical discs make it a little challenging to make your own copies of games, but disc burners are cheap, so the OS and console hardware always have to validate that games are trusted and allowed to run.
However, unlike a desktop, the OS is tuned to run one application—your game—with maximum performance. Typically, this means that extraneous OS services are removed, and often the game is run with elevated privileges so that fewer security context switches are required. The scheduler is tweaked for the single-app scenario.
Virtual memory is usually the first feature to go. While it can save a lot of trouble when multitasking on limited RAM, in a single application system like a console, it gives added complexity whose only benefit is enabling a very slow failure mode. It’s better for games to monitor their own memory usage and cap their allocations so they fit into physical RAM.
Often where there are multiple APIs with similar functionality, the console manufacturer will choose one—usually the lowest level—and drop the others. In addition, only common usage patterns may be supported. Nonessential or infrequently used modes are often dropped.
In order to meet security or feature requirements, the console APIs may have added complexity. For instance, there are often strict requirements about what network services a console may access, so additional handshaking steps may be enforced by the OS. Audio may be required to support a variety of output scenarios (headphones, Dolby, THX, 2, 2.1, 5.1, 7.1, etc.) and therefore may only accept the richest format and down convert. Mass storage access may involve mandatory validation to prevent security risks from user-modified data. Or it may be removed entirely and access only allowed through strict APIs tailored for individual situations, like save games.
Functionality that normally happens behind the scenes is often much closer to the surface in a console. For instance, with a fixed amount of memory and limited processes, heap management doesn’t really need to be in the OS at all—it can give you all the available memory and off you go. The distinction between OS and user code also becomes weaker. Some consoles run game code in the same kernel ring as the OS, which greatly reduces the cost of context switches.
Some things—like functionality that would normally be in the graphics driver—will be provided as normal user code that you compile into your application. This is great because, if that code becomes a bottleneck, you can really tune it to do exactly what you need for good performance. Compare this with waiting for a new driver update from a vendor!
The effect of these changes is to make console development lean and mean. Focused, fast APIs lead to focused, fast games. Sometimes, you have to give up a few niceties, but the trade-offs are worth it in terms of stability and performance.
In The Dip, Seth Godin talks about the idea that things often get worse before they get better. The dip in an endeavor is how much worse things can get before they improve. An important part of planning is to figure out how deep the dip is—if it’s too deep, you won’t be able to make it across to the point where things are good again.
Really taking advantage of a console can take a lot of R&D. This is the dip you have to contend with when you are looking at implementing a video codec or a physics library or a sound engine or another complex piece of functionality on a console. If you have 18 months to ship your game, can you afford to spend 12 months writing an optimized character animation system? It will probably be really good when it is done, but if it is harder than you expect or it takes longer than planned, your game is in real trouble—never mind that you would be losing that much extra time to spend on gameplay or graphics.
Today’s consoles are very complex. Sony does not expect people to fully take advantage of the PS3 for years to come, despite it having been on the market for some time now. The games at the end of the PS2’s lifecycle are nearly unrecognizable as being on the same hardware as the launch titles.
In general, if you have the budget, using middleware is a good choice. Especially on consoles, the gulf between a naïve implementation and a really good one can be vast. You will want to do your due diligence, of course.
In fact, good middleware is so essential that many console vendors develop middleware and libraries for common scenarios and give it away as part of the development kit. For instance, the D3DX library that comes with a 360 is enough to implement a basic game unaided. But this is not going to solve the same problem that, say, Havok does.
More and more middleware is available under open source licenses. For instance, Bullet is a good physics library that has optimized kernels for Cell and other specialized console features. It even receives development time from Sony researchers.
You do not want to fritter away your game’s budget on third-party software, but a few strategic investments might save months of intense development, debugging, and optimization work.
One of the best parts of console development is that the support, compared to PC development, is really good. The console manufacturers really wants you to succeed because they receive a royalty on each copy of your game that is sold, as opposed to PC development, where the connection is more tenuous between sales of game and sales of OS/hardware.
Typically, a certain amount of support will be stipulated as part of the development contract. In addition, console manufacturers are usually very interested in fixing bugs in their APIs and core system code. Between those two factors, you are already way ahead of the game compared to, say, developing an OS X game.
Obviously, developing your game is ultimately your own responsibility. But watching some presentations and reading the library of documentation that comes with the SDK will help quite a bit, as will lurking on the mailing lists and forums that are available for console developers on your platform.
Consoles are all about consistent, reliable play experiences. If there were 10 variants of the NES, each with different capabilities, Nintendo would not be a household name today. A big part of the process of developing a console game is conforming to the standards for that console.
When you sign a contract with a console vendor, the company will typically specify certain technical requirements that you must meet in order to ship a title on its console. This can range from minimum frame rate to network usage restrictions to the size, color, and appearance of menu UI buttons to how translated text for localizations must be encoded. These are enforced by the QA process, and represent a big part of the value of a console game—that it is tested, that it does run correctly, and that it meets performance requirements.
Make sure that you understand these constraints fully, and that you budget time and engineering resources to meet them. Sometimes they can be onerous, but it is worth it to deliver a great product. From an optimization perspective, they should fit into your budgeting as hard constraints.
Consoles have limited resources, but these resources are fast. In particular, RAM and bus speeds are very high. This leads to some interesting possibilities.
For instance, on the typical consumer system, it is slow to read VRAM. Since consoles have extremely fast RAM<—>VRAM access, this opens up a wide variety of techniques that are too costly elsewhere, such as heavy texture streaming or frequent readbacks from the framebuffer. We will discuss some of these in the GPU section that follows.
Consoles often have more involved memory hierarchies. This adds some labor for the programmer but can lead to huge performance wins. For instance, the PS3 uses the Cell architecture, which provides each Cell processor with a small amount of chip-local, very fast memory. Designing algorithms that leverage this memory result in major speedups. Similarly, the 360 includes a small amount of very fast RAM that is used for rendering, separate from the normal VRAM (http://en.wikipedia.org/wiki/Xenos_(graphics_chip)).
GPUs have all kinds of interesting low-level features, but they cannot be exposed via a higher level graphics API because they are wildly incompatible with how other cards or even the API itself work. Most console GPUs let you manipulate video memory directly, including the internal structures that the GPU uses for rendering. This can be a huge time-saver because you can stream data directly from disk into VRAM, in exactly the format needed for rendering. You can directly do what would otherwise require a lot of gyrations.
The memory interconnects on consoles are reliably fast, too. On a PC, a graphics card might be on one of several different busses with order-of-magnitude variations in speed. Since many applications may be using the card at the same time, performance can suffer due to factors entirely outside your control.
On a console, you know exactly how many MB/sec you can transfer, and it will be the same on every version of that console in the world. Immediate fast access to VRAM leads to some interesting possibilities. On the PS2, it was possible to read back from the framebuffer and do deferred shading on the CPU. This was very useful because of the very limited GPU capabilities on that console.
More recent consoles have significantly better GPU capabilities, reducing the appeal of this technique, but it’s certainly still feasible (http://research.scea.com/ps3_deferred_shading.pdf) for some consoles. For an algorithm like SVT (http://www.silverspaceship.com/src/svt/) or tone mapping that involves reading back data from the framebuffer, fast busses lead to significant performance gains.
Console GPUs often expose interesting special features, like custom texture formats or specialized shader instructions. Find these and take advantage of them.
There is a certain level of performance tuning that is counter-productive on consumer hardware. Consumer hardware will vary by quite a bit, so you cannot make assumptions that are too specific. Assuming a fixed cache size or specific timings is unwise. Spending a lot of time tweaking your algorithms for performance on a single CPU or GPU is a waste after a certain threshold because it will cost you performance on other varying hardware.
But consoles are, by definition, fixed hardware platforms. So you can actually dig down and really get extremely specific. There is still some variation just between different product batches and different revisions of the console, but this is usually manageable, and in addition, big changes will generally be planned and documented (for example, the vendor might reserve the right to completely change the optical drive in future revisions, requiring you to use only established interfaces).
Consoles originally targeted CRT televisions, which ran at one of two fixed resolutions. With the advent of HD, this became more variable—now there are a dozen possible target resolutions with the option of upscaling/not, interlaced/progressive, etc. ranging from 640 × 480 to 1,920 × 1,080. Nevertheless, consoles will typically focus on a fixed target. For instance, most Xbox 360 content will target 1,280 × 720 with upscaling to 1,920 × 1,080, while Wii content will run at 640 × 480.
The vendor will generally require a certain minimum frame rate on the game. These two parameters can help you limit the resources that you need for simulation and rendering. You can do a lot of preprocessing in order to cap texture size to the maximum size that will ever be needed.
As the game gets closer to being done, you can do things like tightly limit resource usage with hard caps. With consoles, there are no variations of the system to scale up/down for, so you can precisely budget your resources and use everything available to you.
Consoles are their own specialized world, so it only makes sense that they have their own special tools. Most console tools require a special version of the console hardware known as a development kit that has extra capabilities to make it easier to develop, debug, and measure.
Because the hardware is more open to the developer on a console, the profiling capabilities are generally much more powerful than the equivalent tools on consumer hardware. PIX was originally an Xbox 360 tool, and on its native environment it is a much richer tool than on the desktop. While most consoles don’t have a developer experience that is quite as polished as PIX, they all include utilities for analysis and tuning of rendering and other activities.
The compilers for consoles are customized. At the low end, they might just be a build of GCC that exposes certain intrinsics and hardware features. At the high end, Microsoft developed a whole new compiler for the 360, and there are several vendors who maintain compilers for PS3.
Many of these cutting-edge developments trickle back into the PC space, but it’s definitely worth your while to review the tools available on your console.
Consoles are homogeneous devices with specialized capabilities targeted at a fixed gaming experience. Because of this, it is possible to tune your game to the very limit of its performance. Consoles expose a great deal more power to the game developer, since they are not constrained by PC concerns like compatibility or upgradability.
The legal and technological issues around consoles present a unique set of challenges and advantages. If you are a long-time PC developer, approach them with an open mind. Regardless of your experience level, always profile, optimize, benchmark, and repeat in order to focus your time on what’s worth optimizing. The same basic rules apply to console optimization, even though there is a great deal more freedom in how you get your performance.