CROSS-PLATFORM

GAME PROGRAMMING
LIMITED WARRANTY AND DISCLAIMER OF LIABILITY

THE CD-ROM THAT ACCOMPANIES THE BOOK MAY BE USED ON A SINGLE PC

ONLY. THE LICENSE DOES NOT PERMIT THE USE ON A NETWORK (OF ANY
KIND). YOU FURTHER AGREE THAT THIS LICENSE GRANTS PERMISSION TO USE
THE PRODUCTS CONTAINED HEREIN, BUT DOES NOT GIVE YOU RIGHT OF
OWNERSHIP TO ANY OF THE CONTENT OR PRODUCT CONTAINED ON THIS
CD-ROM. USE OF THIRD-PARTY SOFTWARE CONTAINED ON THIS CD-ROM
IS LIMITED TO AND SUBJECT TO LICENSING TERMS FOR THE RESPECTIVE
PRODUCTS.

CHARLES RIVER MEDIA, INC. (“CRM”) AND/OR ANYONE WHO HAS BEEN
INVOLVED IN THE WRITING, CREATION, OR PRODUCTION OF THE ACCOMPA-
NYING CODE (“THE SOFTWARE”) OR THE THIRD-PARTY PRODUCTS CON-
TAINED ON THE CD-ROM OR TEXTUAL MATERIAL IN THE BOOK, CANNOT AND
DO NOT WARRANT THE PERFORMANCE OR RESULTS THAT MAY BE OBTAINED
BY USING THE SOFTWARE OR CONTENTS OF THE BOOK. THE AUTHOR AND
PUBLISHER HAVE USED THEIR BEST EFFORTS TO ENSURE THE ACCURACY AND
FUNCTIONALITY OF THE TEXTUAL MATERIAL AND PROGRAMS CONTAINED
HEREIN. WE HOWEVER, MAKE NO WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, REGARDING THE PERFORMANCE OF THESE PROGRAMS OR CON-
TENTS. THE SOFTWARE IS SOLD “AS IS” WITHOUT WARRANTY (EXCEPT FOR
DEFECTIVE MATERIALS USED IN MANUFACTURING THE DISK OR DUE TO
FAULTY WORKMANSHIP).

THE AUTHOR, THE PUBLISHER, DEVELOPERS OF THIRD-PARTY SOFTWARE,

AND ANYONE INVOLVED IN THE PRODUCTION AND MANUFACTURING OF
THIS WORK SHALL NOT BE LIABLE FOR DAMAGES OF ANY KIND ARISING OUT
OF THE USE OF (OR THE INABILITY TO USE) THE PROGRAMS, SOURCE CODE, OR
TEXTUAL MATERIAL CONTAINED IN THIS PUBLICATION. THIS INCLUDES, BUT
IS NOT LIMITED TO, LOSS OF REVENUE OR PROFIT, OR OTHER INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THE PRODUCT.

THE SOLE REMEDY IN THE EVENT OF A CLAIM OF ANY KIND IS EXPRESSLY

LIMITED TO REPLACEMENT OF THE BOOK AND/OR CD-ROM, AND ONLY AT
THE DISCRETION OF CRM.

THE USE OF “IMPLIED WARRANTY” AND CERTAIN “EXCLUSIONS” VARIES FROM

STATE TO STATE, AND MAY NOT APPLY TO THE PURCHASER OF THIS PRODUCT.
 CROSS-PLATFORM
GAME PROGRAMMING

STEVEN GOODWIN

CHARLES RIVER MEDIA, INC.

Hingham, Massachusetts
Copyright 2005 by CHARLES RIVER MEDIA, INC.
All rights reserved.

No part of this publication may be reproduced in any way, stored in a retrieval system of any
type, or transmitted by any means or media, electronic or mechanical, including, but not limited
to, photocopy, recording, or scanning, without prior permission in writing from the publisher.
Publisher: Jenifer Niles
Cover Design: The Printed Image
CHARLES RIVER MEDIA, INC.
10 Downer Avenue
Hingham, Massachusetts 02043
781-740-0400
781-740-8816 (FAX)
[email protected]
www.charlesriver.com
This book is printed on acid-free paper.
Steven Goodwin. Cross-Platform Game Programming.
ISBN: 1-58450-379-3
eISBN: 1-58450-639-3
All brand names and product names mentioned in this book are trademarks or service
marks of their respective companies. Any omission or misuse (of any kind) of service marks or
trademarks should not be regarded as intent to infringe on the property of others. The publisher
recognizes and respects all marks used by companies, manufacturers, and developers as a means
to distinguish their products.
Library of Congress Cataloging-in-Publication Data
Goodwin, Steven, 1973-
Cross platform game programming / Steven Goodwin.— 1st ed.
p. cm.
Includes bibliographical references and index.
ISBN 1-58450-379-3 (pbk. with cd-rom : alk. paper)
1. Computer games—Programming. 2. Cross-platform software development. I. Title.
QA76.76.C672G66 2005
794.8’1526—dc22
2004029828
Printed in the United States of America
05 7 6 5 4 3 2 First Edition
CHARLES RIVER MEDIA titles are available for site license or bulk purchase by institutions,
user groups, corporations, etc. For additional information, please contact the Special Sales De-
partment at 781-740-0400.
Requests for replacement of a defective CD-ROM must be accompanied by the original disc,
your mailing address, telephone number, date of purchase, and purchase price. Please state the
nature of the problem, and send the information to CHARLES RIVER MEDIA, INC., 10
Downer Avenue, Hingham, Massachusetts 02043. CRM’s sole obligation to the purchaser is to
replace the disc, based on defective materials or faulty workmanship, but not on the operation
or functionality of the product.
 To my sister, Angela…

…the brainy one of the family.

This page intentionally left blank
 Contents

Dedication v
Acknowledgments xvii
Preface xix

1 Introduction 1
Background of Cross-Platform Programming 1
History 2
The Importance of Cross-Platform Development 4
Overview of Cross-Platform Components 7
The Lead Platform 9
Cross-Generation, Cross-Platform Game Programming 9
The Theoretical Process 10
The Development Process 12
Code Is Code 12
Console Limitations 14
Libraries 15
About the Book 17
Coding Style 17
Non-Disclosure Agreements 18
Notes to the Reader 18
Endnotes 19

2 Top Ten Tips 21

The Basic Issues 21

vii
viii Contents

Abstraction 22
Commonality 24
Limitations 24
Language Limitations 24
Library Limitations 27
Compiler Limitations 27
Platform Limitations 31
Modularization 33
Resource Creation Path 35
Resource Detail 35
Granularity 38
Basic Datatypes 39
Memory Management 39
Audio Code 39
Separation and Isolation 40
Obvious Isolation 40
Singletons 41
Class Structures 43
Divorcing Code 44
Separation by Purpose 46
Separation by Memory 49
Separation for the Present 49
Separation for the Future 50
Succession 52
The pImpl Idiom 53
Debugging and Profiling 53
Programming-Based Bugs 53
Compiler-Based Bugs 54
Execution-Based Bugs 55
Profiling 59
Predictability 60
 Contents ix

Randomness 60
Trigonometry 61
Input Stimuli 61
Turn-Around 62
Endnotes 65

3 Memory 67
The Specification 67
Simple Memory 71
The Issues–Datatypes 71
The Issues–A Safety File 74
The Issues–The Report 76
Our Own Memory Manager–Design 81
Hardware Properties 81
Endian 81
Alignment 85
Access 87
Software Properties 87
Fragmentation 87
The Standard Library 89
Our Own Memory Manager–Implementation 90
Conceptual Design 91
Allocating Memory 94
Garbage Collection 97
Releasing Memory 98
Debugging Memory 99
Profiling Memory Usage 102
Allocation Wrappers 102
High-Level Memory Usage 102
Application Memory Usage 104
Using Allocation Within Subsystems 115
Global versus Game 117
x Contents

Other Guidelines 118

The Stack 118
Local Variabales 120
Intelligent Buffer Usage 121
Minimize Dynamic Memory 121
Endnotes 121

4 The CPU 123

The CPU 123
Timer Resolution 124
Processor Yield 126
Programming the Clock 127
Programming Timers 130
Programming Profilers 130
Time Slicing 132
CPU Scalability 138
Lowest Common Denominator 138
Scale Back 139
Level of Detail (LOD) 139
Extra Burn 140
Parallel Processing 141
Parallel Determination 141
Parallel Distribution 143
Parallel Implementation 149
Task Scheduling 160
Avoiding the Whole Problem 162
Endnotes 163

5 Storage 165
The Four Corners of Storage 165
The Problems 166
 Contents xi

The Data Conversion Process 170

Serialization 173
Endian Issues 178
Extensibility and Future-Proofing 184
Introducing Platform-Specific Data 188
Introducing Platform-Specific Resources 196
Serializing Class Hierarchies 197
Object Creation 199
Interdependent Objects 200
Patching Pointers 201
Designing a Filesystem 205
Disc Size 208
Layout 209
Filesystem Implementation 212
Filesystem Devices 214
File Handling 220
Filesystem Shortcuts 224
Filesystem Additions 225
Handling Physical Devices 225
Asynchronous Loading 226
Synchronous Loading 231
Block Sizes and Caching 233
The General Case 236
Creating Back Doors 236
Going Around the Problem 237
Knowing the Device 237
A ZIP Warning 237
Endnotes 238

6 Debugging 241
Basic Requirements 241
Debugging Methods 242
xii Contents

Coding Style 242

Debugging Methodologies 248
Implementing Debugging Code 250
Trace Messages 251
Trace Levels 252
Handling Errors 261
Assertions 262
Memory 265
Output Targets 271
Time Delay 272
Flushes 272
Sending to Host 272
Bugs in the Compiler 272
Bugs in the Debugging Code 273
Reproduction Bugs 273
Hardware Problems 273
Screen 273
Second Sight 274
File 274
Serial Port 275
Making Data Readable 275
Multithreaded Output 276
Maintaining Consistency 278
Isolating System Calls 278
Tabulating Trigonometry 282
Random Numbers 287
Code Checking 292
Endnotes 293

7 System I/O 295

Abstracting Basics 295
The Null Driver 296
 Contents xiii

Prepared Singleton 296

Double Chance Functions 297
Input Devices 299
General Implementation 300
Input Logging 311
Gameplay Abstractions 315
The Bottom Line 318
Endnotes 319

8 The Audio System 321

High-Level Parameters 321
Playing Music 322
CD Audio 323
MP3 and Ogg Vorbis 323
MIDI 324
Customized Formats 325
Playing Sounds 326
Raw Data 326
Compressed Data 326
Metadata 327
Looped Sounds 327
Resourcing Data 328
In Memory 328
From a Stream 328
Asynchronous Loading 330
Mixer Control 330
UDE 331
The Gameplay Mixer 334
The Technology Mixer 338
The User Mixer 339
Video Playback Interaction 341
xiv Contents

Endnote 341

9 The Graphics Engine 343

History 343
Common Code 344
Techniques 346
Static Texture Changes 346
Dynamic Texture Changes 349
Translucent Textures 352
State Changes 353
Mode Changes 356
Special Cases 358
Resourcing the Data 359
Textures 359
Meshes 362
Engine Features 362
Camera 363
Viewports 364
Lights 365
The Scene 366
Abstracted Features 367
Texture Handling 368
Meshes 369
Sprites 372
Fonts and 2D Overlays 373
Abstracting Special Effects 374
Engine Effects 374
Game Effects 374
Special Effects 374
Graphics on Television 375
Text 375
Contrasting Colors 376
 Contents xv

Image Sizes 376

Balancing Colors 377
Physical Testing 377
Endnotes 378

10 Network Programming 379

Packet Programming 379
Networking Background 380
The Physical Network 382
The Conceptual Network Driver 382
The Null Network 391
Network Latency 392
Dropped Packets 393
The Two Modes 394
Cross-Network Progamming 395
Endnote 395

11 The Bits We Forget About 397

The Development Process 397
The Environment 397
Source Code 401
Presentation Issues 403
PAL and NTSC 403
Frontend Screens 405
Foreign Language Versions 406
Operating System Considerations 409
The Size of size_t 409
Code Overlays 409
Initializing the OS 410
Handling Technical Requirements 413
Title Screens 413
Attract Mode 414
xvi Contents

Reset Buttons 414

Memory Cards 415
Disc Covers 419
Artifacts of Code 420
The Consequence of STL 420
Exceptions 422
Game Configuration 424
Hacking It 424
Endnotes 425

Appendix A About the CD-ROM 427

Appendix B PlayStation 2 Glossary431

Appendix C Xbox Glossary 435

Appendix D GameCube Glossary 439

Appendix E Code Guidelines 443

Index 445
 Acknowledgments

he completion of this book is the result of many people and their inspira-

T tion, experience, ideas, and time. Writing the actual words appears insignif-
icant by comparison.
I would like to thank my readers, editors, and other assorted developers who
have provided invaluable feedback, comments, and suggestions, especially Michael
Braithwaite, Ben Crossman, Dan Evans, Mal Lansell, David Manley, Jerome Muf-
fat-Meridol, and Dave Wall.
To my friends and colleagues that have encouraged my writing: John Hearns,
Anne Mullane, Colin Murphy, Steve Porter, John Southern, and Dean Wilson.
To those with whom I’ve worked, and whose great ideas have found some form
within these words, I thank you: The development teams at Bits Studios, Computer
Artworks (R.I.P.), Criterion and Edcom, and notably Mat Cook, Dominic Giles,
Vlad Kapietsky, Nat Presson, Alan Troth, Mark Walker, and Darren Ward.
I would like to thank Jenifer Niles and all her team at Charles River Media for
this book, and for making me appear competent!
Finally, I would like to thank my close network of family and friends who know
all about me, but seem to like me anyway—especially David Eade, Ed and Margaret
Grabowski (without whom...), Justine Griffith, Phillip Hart, William Siddons,
Fiona Stewart, Maria Thomson, and all of TULS, Lonix, Gllug, 2600, and Slashdot-
London.
And, of course, I want to thank Grandma, Granddad, Shirley and Ken, Juliette
and Dean, Melanie, Mum, Dad, and my sister Angela.

xvii
This page intentionally left blank
 Preface

ith nearly every game on the market today being released si-

W multaneously on all platforms, the need for a good cross-plat-

form development strategy is crucially important. Every hour
spent reinventing the wheel is an hour wasted. Or put another way, every
hour spent writing cross-platform code constitutes three saved hours. This
means being able to write code that behaves identically on all machines.
Not similar—identical! This book covers myriad problems that exist
within every cross-platform games, and gives you the understanding and
ability needed to solve them.
This book is intended for developers working (or hoping to work) in
the games industry who need a mentor to guide them through the jungle of
abstractions, design patterns, and engine architectures that support a cross-
platform game. You’ll learn the particular rules and methods by which
code must be written, why these rules exist, and how to harness them to
create good cross-platform code.
The book is also for those looking to start crossing their project from
one platform to another, and for those building a new engine with the in-
tention of making it cross-platform from the ground up. This book will
help senior and lead programmers determine where the platform-specific
features should start and end, and the best way to achieve their cross-plat-
form goals. Gameplay programmers will develop according to these same
rules, preventing the common problems and thereby speeding their ascent
to lead and senior level.

xix
xx Preface

For those already working in the upper echelons of their company, this book
provides a solid reference of development practices and a detailed breakdown of all
the required cross-platform game components, with a comprehensive task list for
the team. You also get detailed explanations of new technologies, such as multi-
processing and threaded environments, and how they will affect the next genera-
tion of consoles.
For those using middleware, the problem is not over because every program-
mer still needs to be able to handle memory, the filesystem, and gameplay code in
a generic, cross-platform manner to make efficient use of the purchase. Who knew
that in our world the standard libraries are not standard? This book covers the
rarely discussed world of cross-platform game programming and gives you the un-
derstanding to develop your games effectively.
We begin by explaining the 10 basic tenets for development that must be ad-
hered to throughout a project for it to work, whether it involves engine or gameplay
coding. We then cover specific areas in detail, such as the abstraction of a filesys-
tem, the graphics engine, the memory manager, and how to handle different hard-
ware specifications without changing the code. Seemingly general topics (such as
debugging and UI design) take on new meaning and raise different issues when the
platform changes and the old tricks no longer work.
A plethora of new ideas and techniques need to be adopted across the spheres
of memory allocation, file handling, graphics, audio, and networking. These are all
areas of knowledge that were once deemed magic by the knowledgeable few, and
unobtainable by the rest of the populous. They are now available to all, and I hope
to teach you some new tricks in this book.
–Steven Goodwin
 1 Introduction

In This Chapter
Background of Cross-Platform Programming
Overview of Cross-Platform Components
The Development Process
About the Book
Non-Disclosure Agreements
Notes to the Reader

BACKGROUND OF CROSS-PLATFORM PROGRAMMING

Cross-platform development is the art, skill, ability, and general know-how re-
quired to write software that works on multiple platforms. “Working on multiple
platforms” means that the same code will compile, link, run, and behave identically
on whichever platform is targeted. Granted, the compiler and tools will be specific
to each machine, and the underlying Application Programming Interface (API)
may vary, but the code itself will be identical as both the game and engine should
be reusable across each platform; that is, developed once, and deployed often.
To be considered a cross-platform project (as opposed to a port), work must be
carried out concurrently on at least two different target machines using a common
code base that remains live throughout. This is a delicate skill because algorithms,
libraries, compilers, and data structures cannot be changed in an arbitrary fashion

1
2 Cross-Platform Game Programming

as a benign modification to one system could cause catastrophic problems for one
(or more) of the other platforms. This is especially true of the data structures con-
taining game assets, where the effects can range from a nuisance to code break-
down, to fluctuations in the memory footprint and large-scale project delays.
Also, a cross-platform game must act identically on these different machines
once compiled. This is the main difference between a project that can be compiled
and run on different machines, and one that is truly cross-platform. Most of the
available OpenGL® code, for example, will compile and run anywhere, but its run-
time behavior often relies on the target platform and varies according to the oper-
ating system, memory, processor speed, filesystem, byte order, and graphics
capabilities.

History
Before the current crop of games, cross-platform development only occurred
rarely. Usually, a game was written first, and then ported to other platforms. The
amount of work required varied according to the project, but was usually small.
Often, when the same development team carried out the port, a set of libraries
would be rewritten for each machine using common names and calling conven-
tions. Various portions of the game code were then changed, amended, and gener-
ally hacked around to compile or assemble on the new platform. There would be
moderate reuse of the game code, but very little reuse of the engine.
Throughout most of the 1980s, a different programmer (or team) would
rewrite the entire game whenever the game was ported to a new platform. Because
most games of this time were written in assembler, it was rare to find a programmer
expert enough in more than a couple of machine code variations to write both ver-
sions. The newness of the industry also meant that very few conversion tools were
available because these were highly specialized languages. The game engines con-
sisted of highly optimized sprite renderers and animation code that would usually
belong to the conversion programmer himself and tied into the new game with
whatever customizations were needed for that project.
As games became more complex in the 1990s, bringing in a different developer
(or team) for the new platform became a less viable option. Development cycles
were no longer measured in weeks, but months. Publishers didn’t want to wait an-
other six months for the conversions to appear because this prevented any attempt
at a short-term marketing and advertising blitz. This meant both versions of the
game had to be developed in tandem, requiring more code reuse as was demon-
strated within the game development cycles of the Commodore™ Amiga® and
Atari® ST, which shared a common processor in the Motorola® 68000. Software
houses created their own graphics library (now called engines) and developed both
 Introduction 3

products concurrently in the first cases of true cross-platform development. In this

situation, both game and engine code would get reused on each platform.
Even though technology was marching on, the industry was diverted from this
early cross-platform view because it was not distributed evenly between projects.
On one hand, the IBM® PC (and its myriad clones) encouraged highly complex
strategy games, flight simulators, and war games using high-powered Intel® chips
and hard drives for mass storage. Programmed in C and C++, these games used
multimedia drivers for graphics, sound, and networking. The structure of these dri-
vers varied between hardware, requiring an abstraction of their basic functional-
ity—a technique still used today. On the other hand, the market for standalone
consoles was growing by using smaller machines with customized chips for im-
proved graphics and sound, and by focusing its market on children and teenagers
playing platform and shooting games. These games were largely written in assem-
bler with very little code sharing because every ounce of processing power needed
to be squeezed out of the machine for each game. However, more engine code was
being reused because each game was shipped for several platforms in the same time
frame, as common libraries (with identical names, but written in different lan-
guages) again came to the forefront. Code reuse became more pronounced as the
console market grew and became license-driven with very short lead times. Every
other game, it seemed, was connected to a film release and so needed to be available
on as many machines as possible (and as quickly as possible) to maximize the rev-
enue streams. The jokes about “change the name, change the graphics, and reship”
weren’t funny, as it brought about a downturn in fortunes within the industry.
The first step back to the cross-platform path began with the Sony® PlaySta-
tion™, Nintendo® 64, and Sega® Saturn™ series of consoles, as gamers became
more adult, and console programmers rediscovered the joy of the C language. Dur-
ing this time, speed was not as vital as it had been previously. It was important cer-
tainly, but whereas programmers would previously have spent days trying to claw
back one or two processor cycles, attention now focused on other areas for many
reasons. First, when working in a high-level language, such as C, you have less op-
portunity to optimize at the low level because the assembler code is now the com-
piler’s responsibility. Second, the balance of processing moved away from the CPU
and onto the graphics chip. This meant that an extra cycle saved on the CPU did-
n’t make any difference to the speed if the game was still bound by slow graphics
processing. Third, the increase of code size and team members required a more
maintainable development environment. Maintenance-friendly programming
rarely involves assembler.
This scenario is consistent with the present day, and the desire for a maintain-
able engine takes precedence over speed or memory issues because those gains can
be made in areas other than code. In recent years, only one notable console engine
has been written entirely in assembler: Jak and Daxter™ for the PS2™. It was not
4 Cross-Platform Game Programming

cross-platform, and still used a scripting language to implement gameplay. Almost

all games are presently written in C++ (with some still chained to C code, where an
old engine is still in use), and most of these are cross-platform.

The Importance of Cross-Platform Development

Cross-platform game development is important for many people, not just pro-
grammers. For the marketing department, it means they can sell four games at
once with one budget, and don’t need to remind the public about the game with
each new platform release. One advertisement, with the line “Available on PC, PS2,
Xbox™ and GameCube™” hits all the bases. It also means marketing can answer
“Yes” to any question concerning its availability, giving a very positive message to
the retail chains.
Cross-platform development helps publishers, too. They are still holding the
game industry’s purse strings, and so need some way of recouping their costs. Hav-
ing the game available on every platform, especially at the start of a console’s life-
time, means that publishers can hedge their bet