Game Engine Architecture

2012-02-12T22:24:00.000-08:00

Hi Jason!

I am Jose Antonio, I wrote you a couple of years ago to ask you some advice about how I could be a better professional. Your advice were really useful for me in the past and now I am having a lead programmer position in AiGameDev.com.

I would like improve my skills as lead programmer, which I think that takes more that the simple technical skills. I would really appreciate if you give me any advice to improve my role as lead programmer by telling me what you consider a lead programmer should do.

I really would be also interested in listen something about how I can communicate better with my team. I would like to know also if you have any recommended reading for this purpose or any book you think it can help me.

My thanks in advance and my best wishes for your next awesome project ;)

Cheers!

-----------------------------------------

Hi Jose,

Sorry I didn't get back to you sooner. I understand the difficulties in making the transition from the role of engineer to that of technical leader. Here's a great article which sums up most of what I've learned about being a good tech. lead. And I'm still learning! :)

http://www.mroodles.com/wordpress/hacking/great-mistakes-in-technical-leadership-reprint/

At Naughty Dog, our approach is to keep the interpersonal relationships open, honest, respectful, and always focused on solving the problems that we need to solve in order to ship a great game (rather than getting side-tracked by irrelevant issues). That means trying our best to check our egos at the door. We always aim to criticize IDEAS, never people. To make sure everyone on the team feels like they have a voice, and to communicate clearly that great ideas can come from anywhere within the team (not just "the top"). We encourage everyone on the team to take a leadership role -- to "own" the tasks for which they are responsible, and to act like "producers," making sure that their tasks are completed to a high level of quality every time.

I look at my role as a technical leader in much the same way that a lead alto sax player fits into a jazz band... he or she is playing in the band along with everyone else, but he or she also serves as a sort of guidepost, to help keep the entire band playing in time and on cue. That's really it -- set a good example, help to make sure everyone is communicating, remove any road blocks, and then get out of the way and trust your team to get the job done.

I hope this helps. At the end of the day, the only way to learn this stuff is to try (and fail many times!)

All the best!
J

Advice for a game engine newcomer

2012-01-05T00:34:00.000-08:00

From: Mike Breske

Hi Jason,

I am currently working as a consultant, doing a lot of work with ASP.NET web applications and business applications built with .NET C#. I'm a relatively new college graduate (applied mathematics degree), and I'm quickly learning that my passions lie outside the world business related applications. I love developing solutions using computer science and mathematics, but the domain isn't right for me.

A friend of mine shares similar sentiments, and we're both looking to work our way into the gaming industry (how many times have you heard that line?). It's my understanding that is not an easy task, as experience is the key. Our plan is to do what we can outside of work and start building games, as bad as they may turn out at first. We want as much experience as possible with the various aspects of the game development process.

To that end, we want to build our own engine. I plan on purchasing your Game Engine Architecture textbook as a core resource. Do you think building a very basic engine from the ground up, then a game using that engine, is a reasonable task for a team of two guys to handle? Do you recommend a different approach or have any other advice? I obviously don't expect you to take a keen interest in my career or anything, but it's nice to be able to solicit guidance from someone who's in a place you want to be.

I saw that you worked on the Uncharted series and I had to see if I could get in contact with you, even for some small tidbits of knowledge. Uncharted 2 changed how I view what's possible in a game, the production value was incredible. I have some serious respect for the team that put that game together.

Thank you for your time!

Mike Breske

________________________

Hi Mike,

An insightful analysis! You are quite right that breaking into the game industry requires some significant effort. And the best way to prepare for entry into the industry is to develop some game software on your own.

That said, embarking on building a game engine from the ground up is a monumental task, and may not serve your immediate purposes. I would recommend instead that you get a hold of a pre-existing engine (e.g. Unreal, Half Life Source, Cryengine, Microsoft XNA, etc.) and "mod" it to make a game. That will give you exposure to a full-fledged engine, and allow you to build something that you can show off, in much less time than it would take to build an engine and then build a game. (Companies with 50 engineers have tried this and failed, so 2 engineers will probably find it a little tricky to pull off!) And building an engine without having seen one is a bit like trying to invent a new automobile without first learning how to change the oil on your existing car.

That said, I do suggest you read my book, as another way to get the "big picture" of how a game engine typically works. That combined with some experience with an existing engine should give you a solid foundation and put you ahead of your peers. Then if you have a demo or two, you should be golden.

You needn't make a full game, by the way. Try to figure out your passion, and make a demo to explore that. You might want to demonstrate your abilities at level design -- in which case you could make a couple of way-cool multiplayer arenas. Or you might want to explore 3D graphics -- in which case you might try using Ogre3D, or raw OpenGL or DirectX, to create a rendering demo with shadows, spherical harmonics, subsurface scattering -- or whatever technology seems interesting. The list goes on. Your demo doesn't have to be huge, either. It can be small and focused, as long as it demonstrates the ability to take on a non-trivial task, solve some difficult problems, and see it through to completion. That's what most employers are looking for -- someone who can not only start the job, but finish it and do it well.

Also, I can't stress enough the importance of practicing your 3D vector math. Knowing how to think in two and three dimensions, working equations in terms of vector notation (rather than always breaking things into x,y,z components), intuitively understanding that a dot product represents a projection, being comfortable with matrices as transformations of either points and vectors or (the inverse) coordinate axes -- these are also things game employers look for. Naughty Dog tests 3D math first, and if you fail that they don't even ask you about your software engineering skills.

Best of luck! Please keep me posted on how things go.

Errata/Suggestions from Chinese translator

2012-01-05T00:19:00.001-08:00

From: Milo Yip

Hi Jason,

I am glad to tell you that, since last year, I have been translating
your book into Chinese for publishing in China. Actually this is my
first time to work on translation work.

I will send you some issues I found in these few days. And I hope I
can ask you questions when I encounter difficulties in your book.
Thanks.

____________

Hi Jason,

I have only translated till chapter 5 at the mean time. So most
suggestions in the following are in the first few chapters. Feel free
to further discuss.

Chapter 1

P.18 "... called a Brawler. This kind of fighting game can have
technical requirements more akin to those of a first-person shooter or
..."
I think "third-person games" is even more similar.

P.19 "Cruisin' USA"
It should be "Cruis'n USA"

P.23 AOL's "Neverwinter Nights" is MMORPG but Bioware's "Neverwinter
Nights" is not. It may be confusing.

P.24 "Populus"
It should be "Populous"

P.28 "OGRE 3D is a ..."
The official name is OGRE, no 3D. There are many occurance of "OGRE
3D" in the book.

P.28 "Torque" is not one of open-source engines. It should be
categorized as other commercial engine.

P.29 I think "3rd party SDKs" may be difficult to fit in the diagram,
since they can be anywhere in the architecture. For example, Physics
engiine were shown in the 3rd party SDKs but they are also in
collision & Physics box.

P.32 "... hardware transform and lighting (hardware T & L) which began
with DirectX 8.
It should be "DirectX 7".

P.39 "high dynamic range (HDR) lighting and bloom"
More precisely, only HDR tone mapping is a post-process effect. HDR
lighting occurs in the lighting process.

P.43 "WiiMote"
Nintendo's official term is "Wii Remote"

Chapter 2

P.71 "_GNUC_"
It should be "__GNUC__". It may also mention about "__GNUC_MINOR__".

P. 74 "Of these, the three we will use most are"
the four

P. 74 "General Tab"
Officially should be "General Property Page". Also the same in other
sections as well.

P.74 "Configuration Propertoes/C++"
It should be "C/C++"

P. 74 "Output directory ... that the compiler/linker ultimately outputs"
Strictly speaking should be linker only.

P. 76 "$VCInstallDir). The directory in which Visual Studio's standard
C library is currently installed.
I think it should be pointed to the Visual C++ installation directory.
And there are tools, headers and binaries for VC under that directory.

P.76 "General Tab/Include Directories"
"Additional Include Directories"

P.76 "General Tab/Debug Information"
"Debug Information Format"

P.79 "However, you cannot debug more than one program at a time."
This is not true. http://msdn.microsoft.com/en-us/library/a404w14b(v=VS.90).aspx

P.79 "Hitting F5 ... will run the .exe built by the start-up project"
This may not be precise. As VC runs the "Command" property in the
Debugging Property Page of the start-up project, and the default value
is $(RemotePath). But this can be any executable or dump file.

P.79 "Break point"
I think the term should be a single word "breakpoint".
http://en.wikipedia.org/wiki/Breakpoint

P.81 "You can cast variables from one type to another... For example,
... as a floating-point value."
I think this example is not good because without the explicit cast
(float), C/C++ will implicitly cast myIntegerVariable to float for the
multiplication with another float. My suggestion is "(float)a/b" to
show the floating point ratio between two integer variables.

P.81 "...inspect the rotation angle of any quaternion from within the debugger."
Is "from" an extra word?

P.99 "To represent a signed integer in 32 bits ... "
This paragraph may mention the term "sign-and-magnitude method".

Chapter 3

P.106 "This is because games are usually developed on a PC or Linux."
Should be better "Windows on Linux" or just "PC".

P.119 "...and later returned to the pool for use by other programs by
calling free()."
"Other programs" seems inaccurate for most OS today. malloc() and
free() are concerning the heap of a process. They should not affect
"other programs".

P.119 "In C++, the global new and delete ... to and from the heap."
More precisely, C++ terminology use free store instead of heap.
http://www.gotw.ca/gotw/009.htm

P.132 "Structured exception handling (SEH) is a very powerful feature of C++".
SEH is a feature of Win32. C++ standard uses the term "exception handling".

Chapter 4

P. 162 the final position of the jet's left wingtip in model space is ..."
It should be "world" space.

Chapter 5

P.210 "On the PS3, should be 128-bit aligned for maximum DMA
throughput, meaning they can only end in the bytes 0x00 or 0x80."
If the address can only end in the bytes 0x00 or 0x80, then it should
be 128-"byte" aligned.

P.213 "...support single- and double-buffered allocators."
The title and the other text use "single-frame allocator". I suggest
to use the consistent term "single-frame allocator".

P.223 "That is, the linker never splits up a compiled translation unit
(.obj file) ..."
In VC2008, it supports function level linking, which can splits up a
compiled translation unit.

P.223 So, following ... to avoid D-cache misses"
It should be "I-cache".

P.224 "Priority queue. ... A priority queue is typically implemented
as a binary search tree (e.g. std::priority_queue).
Priority queue is more often implemented as heap data structure.
http://en.wikipedia.org/wiki/Priority_queue#Usual_implementation
It should not be "thought of a list that stays sorted at all times",
because it only permits dequeue for the maximum/minimum element, but
not traversing the content.

P.227 "If a divided-and-conquer approach is used, as in a binary
search, ..., only log_2 n elements will actually be visited by the
algorithm on average..."
It should be "on the worst case" instead of "on average".

P.248 "The UTF-16 standard ... Each character takes up exactly 16 bits."
"UTF-16 ... produces a variable-length result of either one or two
16-bit code units per code point." http://en.wikipedia.org/wiki/UTF-16

P.249 "Under Microsoft Windows, the data type wchar_t is used to
represent a single "wide" UTF-16 character (WCS)"
There are several issues in this sentence. First wchar_t is a standard
C++ type, it is unrelated to Windows (OS). Second, the character set
used in wchar_t is undefined in C++.
http://en.wikipedia.org/wiki/Wide_character

Chapter 10

P. 421 "... DXT ... the basic idea is to break the texture into 2x2
blocks of pixels"
It should be 4x4

P.427 "The ambient term ... is a gross approximation of the amount of
indirect bounced light present in the scene"
Ambient light may not be only indirect lights but the light arrive at
the surface at almost all directions. It is common to use ambient term
to approximate skylight.

P. 428
k_A, k_D, k_S normally should be a vector (RGB color), and use bold
face as C_i.

P.442 "The basic idea is to break a triangle ... MSAA does not require
a doububle-width frame buffer."
The section is not very precise. It only need to run fragment shader
on multiple subsample fragments at the edge of polygons. Pixels that
are completely inside a polygon only run fragment shader once per
pixel.
Also, it does not mention that MSAA require 4x (or more according to
the level of MSAA) memory for depth and stencil buffer.

P.443 "The depth buffer ... typically contains 16- or 24-bit floating
point depth information..."
Typically depth buffer is in integer format. Direct3D 9 has only
32-bit floating point depth buffer, others are integer formats.

P.443 "When a fragment's color is written into the frame buffer, it depth..."
"its depth"

P.447 "Both FxComposer and Unreal Engine 3 provide powerful graphical
shading languages."
FxComposer doesn't. It only provides traditional text-based shading language.

P. 461 "For each frustum plane, we move the plane inward a distance
equal to the radius, ... inside the frustum"
It should move the plane "outward" by the distance equal to the
radius. If all inward tests are true, then the sphere "may be" inside
the frustum.
For details, see "Real-time Rendering 3rd Edition". Actually only need
to evaluate the plane equation of the center of sphere and then
compare to r for culling purpose.

P.480 "In traditional triangle-rasterization-based rendering, all
lighting and shading calculations are performed on the triangle
fragments in view space."
More precisely, lighting is often performed in world, view or tangent space.

P. 481 "A typical G-buffer might contain ... depth, surface normal in
clip space"
I think more often they are stored in view or world space. Normal in
clip space are difficult to do lighting computation.

P. 482 "... including vignette (slight blur around the edge of screen)..."
Vignette often means reduction of brightness and saturation at the
edge of screen.

P.484 sky rendering
I think, if the sky is rendered before other objects, then z-test and
z-write should be turned off to reduce bandwidth.
But for current gen hardware, I think sky should be better rendered
last with z-test on and z-write off, so it reduce the pixel shading
overhead at the occluded sky area.

Chapter 11

P. 523 the 2nd equation
w_ij should be w_i, and K_i should be K_j_i.

Chapter 12

P630. "... known as mechanics. This is the study of how forces affect
the behavior of objects. In a game engine, we are particularly
concerned with dynamics of objects -- how they move over time"
There are several issues. Mechanics is a big branch in physics, its
subfields include kinematics, dynamics, quantum mechanics, etc.
Second, kinematics is study of motion of objects (without concerning
about force), while dynamics is concerning about how force affect the
motion of objects. Some simple games only need kinematics (e.g. Pong)

P.631 "Hence the physics system attems to provide realistic collision
responses ... interpenetrating."
With continuous collision detection (CCD), it is possible to provide
collision responses without penetration.

P. 692 "For example, the vertices of a static triangle mesh ... during
rendering"
I think this example may not be appropriate. It does not save
per-vertex matrix multiplication as normally a vertex position need to
transform with view-projection matrix anyway.

Errata

2012-01-05T00:15:00.000-08:00

Hello,

I recently purchased a copy of your book. After having read through
about half of the book so far I wanted to send you some comments. I
thought about posting this in a review on Amazon, but rather than
diminsh your otherwise excellent book I thought it better to simply
write you instead and perhaps this information can be included in a
future printing, or published on your website as errata. Because to
be honest the book is really good otherwise and I think that despite
the following issues it deserves an excellent review.

Anyway My comments are related to the information you provide on
exception handling in chapter 3. For starters, you should be careful
about using the term "SEH" because technically SEH is very specific to
the Windows platform and is a native OS-level system service. C++
exception handling, on the other hand, is a *completely* different
implementation of an exception handling mechanism, which may or may
not be implemented using SEH by the compiler. Obviously if your code
is being compiled for any platform other than Windows, then the
compiler is obviously not using SEH. In the book I believe you are
actually referring to C++ exception handling.

Secondly, you mention on page 132 that "SEH (sic) adds a lot of
overhead to the program. Every stack frame must be augmented to
contain additional information required by the stack unwinding
process. Also, the stack unwind is usually very slow -- on the order
of two to three times more expensive than simply returning from the
function. Also, if even one function in your program (or a library
that your program links with) uses SEH, your entire program must use
SEH. The compiler can't know which functions might be above you on
the call stack when you throw an exception."

This is entire paragraph is almost completely wrong. The only stack
frames that are augmented at all are ones that contain a catch block.
To demonstrate proof of this, consider the following small program.

#include <iostream>
#include <exception>

void test1();
void test2();
void test3();

void __declspec(noinline) test1()
{
test2();
}

void __declspec(noinline) test2()
{
try { test3(); }
catch(const std::exception& e)
{
std::cout << "Got an exception in test2" << std::endl;
}
}

void __declspec(noinline) test3()
{
throw std::runtime_error("Error");
}

int _tmain(int argc, _TCHAR* argv[])
{
test1();
return 0;
}

Now let's take a look at the assembly language generated by the
compiler. The following is simply the above code repeated but with
assembly inlined at each sequence point. It's not necessary to give
the assembly anything more than a cursory glance just to see how much
code the compiler is generating in each function.

void __declspec(noinline) test1()
{
test2();
004010C0 jmp test2 (4010D0h)
}

void __declspec(noinline) test2()
{
004010D0 push ebp
004010D1 mov ebp,esp
004010D3 push 0FFFFFFFFh
004010D5 push offset __ehhandler$?test2@@YAXXZ (401E90h)
004010DA mov eax,dword ptr fs:[00000000h]
004010E0 push eax
004010E1 mov dword ptr fs:[0],esp
004010E8 sub esp,8
004010EB push ebx
004010EC push esi
004010ED push edi
004010EE mov dword ptr [ebp-10h],esp
try { test3(); }
004010F1 mov dword ptr [ebp-4],0
004010F8 call test3 (401140h)
catch(const std::exception& e)
{
std::cout << "Got an exception in test2" << std::endl;
004010FD mov eax,dword ptr [__imp_std::endl (402038h)]
00401102 mov ecx,dword ptr [__imp_std::cout (402054h)]
00401108 push eax
00401109 push offset string "Got an exception in test2" (40215Ch)
0040110E push ecx
0040110F call std::operator<<<std::char_traits<char> > (401330h)
00401114 add esp,8
00401117 mov ecx,eax
00401119 call dword ptr
[__imp_std::basic_ostream<char,std::char_traits<char> >::operator<<
(40204Ch)]
}
0040111F mov eax,offset $LN7 (401125h)
00401124 ret
}
00401125 mov ecx,dword ptr [ebp-0Ch]
00401128 pop edi
00401129 pop esi
0040112A mov dword ptr fs:[0],ecx
00401131 pop ebx
00401132 mov esp,ebp
00401134 pop ebp
00401135 ret

void __declspec(noinline) test3()
{
00401140 push ebp
00401141 mov ebp,esp
00401143 and esp,0FFFFFFF8h
00401146 push 0FFFFFFFFh
00401148 push offset __ehhandler$?test3@@YAXXZ (401E82h)
0040114D mov eax,dword ptr fs:[00000000h]
00401153 push eax
00401154 mov dword ptr fs:[0],esp
0040115B sub esp,4Ch
throw std::runtime_error("Error");
0040115E push offset string "Error" (402178h)
00401163 lea ecx,[esp+8]
00401167 call dword ptr
[__imp_std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::basic_string<char,std::char_traits<char>,std::allocator<char> >
(40203Ch)]
0040116D lea ecx,[esp+20h]
00401171 mov dword ptr [esp+54h],0
00401179 call dword ptr [__imp_std::exception::exception
(4020E4h)]
0040117F lea eax,[esp+4]
00401183 mov byte ptr [esp+54h],1
00401188 push eax
00401189 lea ecx,[esp+30h]
0040118D mov dword ptr [esp+24h],offset
std::runtime_error::`vftable' (4021A0h)
00401195 call dword ptr
[__imp_std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::basic_string<char,std::char_traits<char>,std::allocator<char> >
(402040h)]
0040119B push offset __TI2?AVruntime_error@std@@ (402410h)
004011A0 lea ecx,[esp+24h]
004011A4 push ecx
004011A5 mov byte ptr [esp+5Ch],0
004011AA call _CxxThrowException (401E00h)
$LN10:
004011AF int 3
}

int _tmain(int argc, _TCHAR* argv[])
{
test1();
004011B0 call test1 (4010C0h)
return 0;
004011B5 xor eax,eax
}

Note that in neither main nor in test1() is there any code having to
do with exception handling. The reason this works is that it's true
that the compiler does not know what functions will be on the
callstack at the time the exception is thrown, but it *does* know what
functions *might* try to handle exceptions. So in each of these
functions, it generates code to modify the exception handling chain.
What really happens when the stack unwinds is that it starts walking
through the stack frames and the exception handling chain in parallel.
If a stack frame is found has no entry at all in the chain, or it has
one or more entries that don't match the current exception, it simply
calls all destructors for constructed objects and then moves up the
stack until it finds one or the program terminates. But there is no
extra code generated in any of these functions. These destructors
would have had to have been called anyway even if the function
terminated normally.

That's my biggest comment. My final comment is in the early chapters
when you're discussing visual studio and different types of builds:
debug, release, production, and hybrid. At one point you mention that
systems like gnu make make it easy to define certain options on a
per-translation unit basis, but that this is very difficult in Visual
Studio. In fact it's very easy! Right click a cpp file in the
solution explorer, click properties, and bam. Any settings you make
in that window are applied only to that translation unit. You can
change any setting that you could normally change on a per-project
basis, as long as it is not a linker setting. Preprocessor,
optimization, etc are all changable on a per-translation unit basis
though.

Aside from these comments, however, the book is definitely a
refreshing addition to the sometimes dilluted market for game engine
books. Too many books try to cash in on the game craze and while it's
clear the authors have experience, the books are not rigorous enough
to leave one satisfied. I like the encyclopedic approach taken in
this book, and I'd definitely be interested in seeing an additional
volume at some point in the future.

Regards,
Zachary Turner

Dual Quaternions

2012-01-05T00:10:00.001-08:00

Hello,

I've been reading through Game Engine Architecture, and must commend you on an excellent book. I'm a lead-programmer with just over 10 years experience making games, so I'm not directly in the target audience, but I've still found it a very interesting read. I just wish it had existed a few years earlier!

Anyway, the section on Dual Quaternions was something that interested me - I hadn't heard of them before, and the possibility of representing rotation, translation and scale in 8 floating point numbers sounded useful - to good to be true really! However, having skimmed through the cited .pdf file, I can find no mention of them representing scale, and this resource http://isg.cs.tcd.ie/kavanl/papers/sdq-tog08.pdf suggests also that they cannot represent scale. Quote:

"Dual quaternions cannot represent non-rigid transformations, such as scale and shear. This means that dual quaternion skinning, unlike linear blend skinning, is restricted only to rotating and/or translating joints."

Anyway, thought I'd mention it. If I've misunderstood them and scale is possible, then apologies. If not, then perhaps a section for corrections on the website would be useful.

Kind Regards,

Andy Weinkove.

____________

Hi Andy,

You are quite right, that is an error. Dual quats represent a combined rotation and translation... basically a "screw motion" and are incapable of describing any kind of scaling transform.

Cheers,
J

Advice on Learning Assembler

2012-01-05T00:09:00.000-08:00

From: Thomas Amundsen

Hi Jason,

I was introduced to your book “Game Engine Architecture” through CSCI 522: Game Engine Development at USC. First, I’d like to say that it is a GREAT book, and can’t thank you enough for writing it!

The biggest question I had after working through the some of the chapters and then reading your blog is, how do you go about learning assembler? I majored in computer science during my undergrad, so I spent about half of a semester learning assembler for some fake architecture. But that didn’t transfer over to the real world, and whenever I see the disassembly in Visual Studio, I have no idea what’s going on. So, I think it would help me a lot to learn this stuff. Do you have any book recommendations, or other general recommendations?

Thanks so much!

- Tom

____________________

Hi Tom,

The best way to learn assembler is to pick a CPU that you have access to (the Intel Pentium or P6 family are probably the most accessible, since they live in most PCs and the latest Macs as well). Then pick up a book on the Intel P6 ISA (instruction setarchitecture), and try coding something!

One way (a not very friendly way, mind you) is to grab the actual Intel docs and pour through them. You could start here:
http://download.intel.com/design/PentiumII/manuals/24400101.pdf
and then move on to the manuals that describe the actual instructions etc.

But really that gives you too much detail. What you want is to learn the basic concepts of registers, aritmetic/logic units (ALU), and assembly instructions... then start learning the basic instructions and what they do. I don't know of a book offhand that teaches this, but here are a few ideas I found on Amazon:

http://www.amazon.com/Introduction-Assembly-Language-Programming-Processors/dp/0387206361/ref=sr_1_1?ie=UTF8&qid=1296888434&sr=8-1

http://www.amazon.com/Assembly-Language-Intel-Based-Computers-5th/dp/0132383101/ref=sr_1_2?ie=UTF8&qid=1296888491&sr=8-2

http://www.amazon.com/Introduction-Assembly-Language-Computer-Architecture/dp/0763772232/ref=sr_1_3?ie=UTF8&qid=1296888515&sr=8-3

You could also go old-school and learn the way I did, by reading about a much older... and therefore much simpler... CPU. For example, the 6502 -- the CPU in the old Apple // computers. It is very simple, and therefore a great way to learn the concepts without getting bogged down in details and modern optimizations. Here's one:

http://www.amazon.com/Assembly-Language-Programming-Lance-Leventhal/dp/007881216X/ref=sr_1_1?s=books&ie=UTF8&qid=1296888579&sr=1-1

Give that a whirl and let me know how it goes.

Rendering Performance

2012-01-05T00:06:00.000-08:00

From: Manuel Fernandez

Hello,

My name is manny, and I'm a big fan of your book. I think it's great how all the main parts of a game engine interact with each other. Most of the time you can probably find good resources online that teach you how to do one thing or the other, but bringing things together to make a game engine is a topic all on its own. I think you book does a great job at detailing all the different parts of a game engine and how they work together.

I bought your book after I read an article in gamasutra about it, i thought it would be useful. I have a Quake 3 BSP file loader which works on both Direct X and Open gl. I'm pretty proud of it because it implements Quake 3's PVS and AABB to frustum culling, and bezier patches. What surprises me is that when i get out of the BSP comfort zone, like rendering from outside the bsp, or simply rendering the whole virtual world, it's a pretty big hit in performance. I'm pretty sure game engine's like UDK, or source can handle drawing a quake 3 level without a problem. I guess my question is what makes industry strength game engines perform so much better than average? I think it's more than just smart culling, or better thread management.

Thank you for your time.

______________________________

Hi Manny, I'm sorry I didn't get back to you sooner, but your email fell thru the cracks.

I'm not a deep rendering guru, more of a generalist. But here are a few ways in which industrial strength rendering engines attain their high performance:

1. Rendering data is often packed into (relatively) small and contiguous data packets, to improve cache coherency. The real key here is to eliminate all pointer chasing during rendering. This means duplicating data, but it is worth it. We did this at Naughty Dog in order to optimize our rendering of dynamic objects (i.e. everything that is not static background geometry) and it yielded immense improvements. So as a (contrived) example, instead of a MeshInstance struct that contains a pointer to a material, which in turn contains pointers to lighting data etc. we would now have a RenderableInstance struct that contains all the data that you would have found by following down all the pointers (and ONLY the data that is actually needed for rendering). (Or maybe it would be multiple arrays of structs, each one containing one type of data... but the key is to avoid the use of pointers to refer to data that lives elsewhere in memory.) These structs aren't tiny, but at least we can iterate thru them in one linear swoop, and gain the benefits of precacheing the memory as we go. Any time you jump around in memory you're going to flush your L1/L2 cache and hurt your performance.

2. Pre-sorting to reduce render state changes is a great idea. That includes which vertex and index buffers you're rendering from (i.e. which mesh), which vertex and fragment/pixel shader programs are loaded, your render constants (transformation matrices, lighting vectors, animation matrix palette, etc.), which texture units you're rendering from, and all the other "render state" of the GPU. Most high-performance rendering engines divide the geometry up into two big categories: opaque and translucent. For opaque, you sort to minimize render state changes as I said: set up the render state for a particular "bin" and then render everything in that bin, then change state, and go again. For translucent, you typically have to sort the geometry in back-to-front order so it looks right. So you lose the benefits of sorting by render state changes. You do it after the opaque stuff, and try to limit how much translucent geometry you render.

3. Z pre-pass can be a savior, especially for GPU hardware on which fill rate (pixel shade, blend and store rate) is limited (like the PS3). I think I describe it in the book, but the basic idea is to put the GPU into a special z-write-only mode, then render the scene with the simplest possible pixel shader (since only the depth/z matters anyway). This is very fast. Then you render the scene again, this time with real pixel shaders enabled (much slower), but without writing to the z-buffer... onlyreading the depth values you deposited before. The GPU is pretty good at early-ing out on fragments whose z values are larger than what's already in the z buffer, so you don't pay the cost of shading them.

4. Eliminate the middle man. DirectX and OpenGL are actually wrappers around a lower-level "raw" GPU hardware protocol called a command list. This is basically the stream of data that the GPU actually consumes, in order to know what to render, what render state changes to make, etc. On the PS3, Sony provides a library called libgcm that allows games to build up their own GPU command lists directly, rather than going through the OpenGL layer. This is really the only way to render fast on the PS3. And actually, Naughty Dog's rendering team wrote an optimized interface, similar to libgcm, but even faster, and customized to the specific compressed data formats that we use... That's what Uncharted uses to render. So the lesson here is: if you have access to a library like libgcm (or want to reverse-engineer one!!!), that can be the best way to wring the last ounces of performance out of your rendering engine.

That said, the only way to be sure about performance is to code it and profile it. So once you have a basic mesh rendering working, you can try optimizing it by (a) keeping all the render data in one or more contiguous arrays -- i.e. eliminate pointer-chasing in your render loop, and (b) sort by render state changes for maximum thruput. Then profile it, and tweak from there.

I hope this helps a little.

From Tokyo

2012-01-05T00:05:00.000-08:00

From: Joseph Conley

Hi Jason,

I'm also a programmer in the game industry and I've recently come across your book. I recently started a new job in Tokyo at Namco Bandai Games (I had previously worked at Activision Blizzard's Vicarious Visions studio(boy that's a mouthful)), and a number of people here recommended your book, and work bought me a copy that I hope to read soon, it looks very interesting and informative.

On an interesting note, the reason why my coworkers here have your book is because they are actually the ones reviewing the translation work for Softbank, the publisher of the book here. I guess they are hoping to wrap that up asap, as the book is due out in this country November 30th I believe.

I have also been a huge fan of the Uncharted Series, and I attended the panel "Game Design with the Dogs" at PAX East earlier this year where Richard Lemarchand, Jacob Minkoff, and Justin Richmond lead us through a demonstration of creating a level in Uncharted 2. The narrative in that game and the way that everything is designed with considerations to narrative in mind is just amazing. I would love to work on a game like that some day.

The technical achievements are just as impressive if not more so, and I have to commend you on you and your teams' work. As I mentioned to Jacob when I talked with him after the panel, I work in the same industry as you and I still have no idea how you make such an awesome game. Maybe your book will help me understand :-)

Thanks for all that you do, I'm eagerly anticipating Uncharted 3.
Joseph Conley

____________________________

Hi Joseph,

Thank you so much for all the kind words! I'll be sure to forward your compliments on to the whole team. I'm very pleased to hear that you're reading my book -- if you have questions, feel free to ask!
By the way, I checked out your blog. I've always wanted to travel to Japan... spent some time in Chennai, India and Hong Kong, but never Tokyo (at least not yet). Your ray tracer appears to have been a success, too -- some nice renders -- what a great project! Anyhow, best luck! Learn lots and have fun on the other side of the world!

All the best,
J

___________________________

Hey Jason,

I wanted to let you know that I am about halfway through your book now (finishing chapter 8), and I'm really enjoying it. Even though I've worked in the industry for about 2.5 years now, I feel like I have learned a whole lot, and that you have helped fill in a lot of gaps in my knowledge of game engines. And even the parts that I have learned before in various classes spread out over years of college or in previous work experience have been aggregated together and presented in a format that is exactly aimed at the sort of work I do, and for that reason it's incredibly useful. I'm really looking forward to the sections on rendering and animation.

Also, while I have been reading, I've been keeping a log of any questions, suggestions, or typos I notice, and I'll send a link to share that google document with you, as I will continue to update it as I read. If you want, I can also ask the technical supervisors for the Japanese version to send me any odd points they noticed, and I can add that to the document as well.

By the way, are you going to GDC next month in San Francisco? Me and my coworker at Namco Bandai Games (and one of the technical supervisors for the Japanese version of GEA) Kazuhisa Minato will be going, and if you're there we'd love to get together and chat about Game Engine Architecture. Also, I saw that Uncharted 3 was announced, and will have support for stereoscopic televisions, which is something else we could discuss, as the game we are working on ("Dead Storm Pirates 3D" for arcades) also is stereoscopic.

Well good luck with Uncharted 3!

___________________________

Hi Joseph,

Thanks for the compliments, and for taking the time to accumulate notes. I know I'll find them invaluable as I start work on the second edition (which I plan to begin sometime soon).

I just got a copy of the Japanese version of GEA, and I must say I'm thoroughly impressed! The folks that translated it clearly spent a lot of time and effort on it. I appreciate your help in keeping me informed.

Sadly, I'm not attending GDC this year. I would very much like to meet you and Minato-san. Hopefully we'll be able to hook up at another industry event, such as E3 or the like. And certainly, if either of you find yourselves in Los Angeles, drop me a line and I'll hook you up with a tour of Naughty Dog.

Cheers and many thanks again,
J

Course Materials

2012-01-04T23:58:00.000-08:00

From: Farshad Kheiri

Dear Dr. Gregory,

I like to develop a course based on your interesting book "Game engine Architecture" for a community college. I was wondering if you can provide me some materials for the class. We like to put our course based on your book. I really appreciate your help in this regard.

Kind regards,

Farshad

_____________________

Hi Farshad,

Well, I'm not a PhD, although it's fun to see Dr. in front of my name! I'm pleased to hear you're using my book with your new course. The book's website, http://www.gameenginebook.com, provides some course syllabi, lab assignment outlines, and some 3D math problems. I hope this helps. If you have other questions, feel free to ask!

Cheers,
J

Getting Hired

2012-01-04T23:55:00.000-08:00

From: Anurag Patnaik

Hi Jason,

I recently discovered your book about game engine architecture at a friend's place and really liked it. Got a copy for myself from Amazon. Hoping to be able to use this along with my course curriculum soon.

I got admitted into Cornell university this year under their Grad school. I was hoping you could give me some pointers about what skills are expected within the industry so that I could spend my year at school actually learning something that would help me get into games. Other than C++, I have heard that knowing your way around Lisp and maybe Python are some useful skills. Is there anything in particular that you think would be useful for a grad like me who is trying to make it into game design ?

I hope I am not intruding .. but any advice from Naughty dog is worth a shot :)

Regards,

Anurag

_________________________

Hi Anurag,

I'm pleased you are finding the book helpful. Pretty much everything you need to know to break into the games industry as a programmer is in the book. 3D math is super important, so definitely focus on solving 3D problems, working with vectors, matrices and quaternions. A little calculus doesn't hurt either!

On the programming side, I strongly believe that learning multiple languages helps you to be a great programmer. I like the Lisp variants, not because they are particularly useful in industry (except at Naughty Dog!), but because they really opened my mind to a completely different way of thinking about computer science. I also recommend Python and C# (both are used extensively in the industry). Oh, and to stay ahead of the crowd, read a bit about Haskell, Ocaml and/or F# -- functional languages are probably the way of the future, given the move toward parallel computing hardware. On that note, familiarizing yourself with parallel programming practices will prove super useful in the years to come.

You should also learn a little assembly language... the PowerPC ISA (instruction set architecture) is a great one to learn nowadays, given that this is the ISA used by Xbox360, PS3 PPU and PS3 SPUs, with minor variations. Again, understanding assembly gives you insights into how higher-level languages like C, C++ or even Lisp actually work under the hood.

One final note of advice: Try to learn by doing, not just reading. Do 3D math problems on paper, then try to implement the solution in C++ or the language of your choice. Make some small tech demos and mini games. The more you do, the more you'll be prepared to wow them at the job interview.

Best luck!

______________________

Hi Jason,

I am extremely sorry for such a delayed reply. I was in the middle of moving to Cornell when I had previously mailed you and upon my arrival in Ithaca, your reply was conveniently placed in my Spam Folder !

Thank you so much for such a detailed response. I am really happy to say that I do have a lot of bases covered here. I am actually building a game as a design project this semester, hopefully using my own C++ engine ! That should be an interesting experience. I have also started to tinker around with Python and am cursing myself for not having discovered this wonderful language earlier. Rounding up this semester would be a healthy project in AI and a course in Computer Graphics which I am hoping would help me understand 3D math better. I had no idea about functional languages, thank you so much for pointing me to this new paradigm.

Again, thank you so much for taking the time to write back such a prompt and detailed answer to my queries. I really cannot thank you enough. Your feedback has been of immense help.

Sincerely yours,

Anurag Patnaik

_____________________

My pleasure! Best luck, and keep in touch.

Course Projects

2012-01-04T23:51:00.000-08:00

From: Jeremy Walker

Hello Mr. Gregory,

I"m currently a grad student at Appalachian State University and I was wondering if I could ask you a few questions. This fall six graduate students seeking their Masters in Computer Science (including me) will be taking an independent study on what we are calling The Design and Implementation of Game Making. I'm contacting you because we decided to use your Game Engine Architecture book as our semester's text book. We are planning on using the new Unreal Development Kit that is out now.

All of the students taking this class have had 4+ years of programming experience though none have done anything with Game Development. We made up the class with the goal of getting a basic understanding of the game making process (from storyboard to actually playing something) and we wanted to learn this cool new Unreal Kit while we were at it. By the end of the semester we would like to actually have a functioning game though it may not be the prettiest thing you've ever seen. Also we were wanting to get a feel for the team aspect of game making. In all our courses so far we've never worked in a team larger than 2 so a team of 6 sounds kind of exciting to me. It would be great if we could have a real team where someone was a "specialist" at one aspect of the game making process, like 3d rendering or gameplay logic, but as of now no one is a specialist at anything. We're all newbies when it comes to game making, though I'm sure we've all wasted many hours playing them.

So I guess my question is, Do you have any suggestions or advice on where or how we should start? I've looked over your syllabi on your site already. Could we condense that into one semester somehow? Or are we reaching too high? I just want to know if you have any pointers on how we should go about this.

Thanks!

_____________________________________________

Hi Jeremy,

I'm very pleased to hear that you're considering using my book as your course text. Your plan of having the students build a game using the UDK is a great one, similar in many respects to what I did in my course.

A 6-person team shouldn't be too hard to manage. (I've done this kind of project with as many as 20 students...) That said, I always liked making sub-teams of no more than 2 or 3 people. (I recall my days as a student -- it was almost impossible to get 4 or more people to agree on a time and place to meet to work on our projects!) So you'd be best off dividing the work into three major categories with sub-teams of 2 each. Perhaps one team could focus on the player mechanics and camera, one team on enemies/AI, and the third on level design/layout and visuals. Or whatever makes sense for your specific project.

I'd also recommend approaching your design like the layers of an onion. Focus on the most basic, core and crucial functionality first. If and only if you make good progress on that, then proceed to the next layer of polish and less-important features, and so on. That way, by the end of the semester, you'll have the highest chance of arriving at something that actually works and has all the core features you need. (At Naughty Dog, we're big on getting something functional, but not pretty, up on screen as quickly as possible. This keeps us focused on what's important, and informs us of what is and is not working as early in the process as possible.)

Best luck, and do keep me posted on how it goes.

Memory Alignment Question

2012-01-04T09:17:00.000-08:00

From: Justin Lam

Hi Jason,

Thank you for writing such a wonderful book, I throughly enjoyed Game
Engine Architecture.

I was wondering if you can clarify something for me. I'm trying to understand the code for allocating aligned memory on pages 212-213. The part that I'm having trouble understanding is how you store the adjustment value. You mentioned that the smallest adjustment value is
1 byte, how then can you subtract 4 bytes from the alignedAddress. Wouldn't this put your pointer pass the rawAddress and you're overwriting some memory that is not yours? Can you clarify or elaborate how this works?

Your response is greatly appreciated.

Thanks,
Justin

____________________________________________

Hi Justin,

Thanks for the kind words about the book!

Re your question: you first allocate a block of raw memory (that is not necessarily aligned) that is larger than the requested block size. The number of additional bytes is equal to the requested alignment in bytes. When you get the raw block back, you advance the pointer until it is aligned (by at least one byte, and by at most the number of bytes in the requested alignment). That way, you always have at least one additional byte in which to store the adjustment value.

For example, let's say the requested alignment is 4 bytes, and the requested size is 64 bytes. We'd actually allocate 64+4=68 bytes. If the raw address we get back is already aligned to a 4-byte boundary (e.g. 0x2000), then we advance the pointer by a full 4 bytes, store our adjustment value in the byte just prior to that (0x2003), and then return the adjusted pointer (0x2004). But if the raw address is not already aligned (e.g. worst case 0x2003), then we would adjust the pointer until it is aligned (0x2004) which would still give us one byte (0x2003) in which to store the adjustment.

J

Small Typo

2012-01-04T09:07:00.001-08:00

From: Kip Warner

Hey Jason,

Small typo on page 164. The bottom right entry in the matrix M_c->p
should be 1, not zero.

More Typos

2012-01-04T09:04:00.001-08:00

From: Gayan Ediriweera

Really just typos this time.

p. 437, between the two matrices
"...in the range [0,1] rather thanin the range [-1,1]...", should be
"...in the range [0,1] rather than in the range [-1,1]..."

p. 823, second last line
"A follow camera alos includes advanced...", should be
"A follow camera also includes advanced..."

Regards
Gayan

Matrix Typo

2012-01-04T08:54:00.001-08:00

From: Gayan Ediriweera

Hey Jason,

I think I spotted a mistake in the book. On p. 434, the end of the first paragraph reads:

"...in a manner analogous to that used to construct a model-to-view matrix:"

I think that should be "model-to-world" matrix.

Also, thanks for putting together such a brilliant book! It's great for getting a high level understanding of every aspect of game engine tech, and the way it's laid out makes it really easy to follow.

Regards
Gayan

Torque Engine

2012-01-04T08:53:00.000-08:00

From: Felipe Otamendi

You list the Torque engine under Open Source Engines section of your book
(1.5.17) when it's not actually open source. You have to buy it to get
the source.

Cheers,

Felipe.

________________________________

Good point, I'll add that to my list of errata to post.
Thanks!

Aligned Allocator Bug

2012-01-04T08:52:00.000-08:00

From: Dave Asbell

Hey Jason,
I am reading your book and I think there is a bug in the aligned allocator. Shouldn't the code be casting the alignedAddress to a U8 instead of a U32 and subtracting 1 byte instead of 4? I believe this would write the offset into the byte preceding the aligned address instead of the word. Similarly shouldn't the free routine be using a 1 byte offset as well? Perhaps I am missing something. In any event I love the book and look forward to finishing it.

_________________________________________

You are quite right; the code was written originally with 4-byte offsets, but I changed it (very sloppily!) to use 1-byte offsets without double-checking it. It's one of the errata I plan to post on the book's site when I get some free time.

Glad you're enjoying it! Do send along any other errata you notice.

Cheers,
J

Measuring Performance

2012-01-02T01:18:00.000-08:00

From: Kechi Cheng

Date: 7/6/2010

Hi,

I am reader of Game Engine Architecture. But I feel confused in chapter 7.5.4.3 that talk about 32-Bit Floating-Point Clocks.

You say the time deltas in floating point format, measured in unit of second. But I don’t understand why you multiply the duration of

CPU Cycles by CPU’s clock frequency. I just think the duration of CPU Cycles should be divided by CPU’s clock frequency. I try to use

WIN32 API to test the result, and the test code like:

// Just test

LARGE_INTEGER dwTest;

QueryPerformanceFrequency(&dwTest);

LARGE_INTEGER dwTest1;

QueryPerformanceCounter(&dwTest1);

Sleep(1000);

LARGE_INTEGER dwTest2;

QueryPerformanceCounter(&dwTest2);

float fHiTimer = (float) (dwTest2.QuadPart - dwTest1.QuadPart) / (float) dwTest.QuadPart;

// Just test

The result is correct, so could you tell me why you multiply by CPU’s clock frequency?

Thanks

Kechi Cheng.

______________________________________________

You are correct, that's a typographical error. A duration measured in cycles divided by frequency in cycles/second (or multiplied by the inverse frequency, in seconds/cycle) will equal seconds.

Cheers,
J