LightSleeper: Blog

Here Be Dragons

Tue, 02 Sep 2008 16:34:15 GMT

At Gamefest in July I gave a talk entitled "Here Be Dragons: C++ Undefined Behavior." As expected, the presentation drew many raised eyebrows and some strong reactions, which was exactly the point. Undefined behavior in C++ is bad news, and should be avoided at all costs. However, it's surprising how many instances of undefined behavior can crop up in average C++ code. You can download the PowerPoint presentation and the audio transcript here, and listen to it at your leisure.

In fact, you can download most of the presentations given at Gamefest this year. The full list is available at http://xnagamefest.com/presentations.htm. Enjoy!

C++0x: The Dawning of a New Standard

Thu, 28 Aug 2008 17:33:12 GMT

The DevX site has some great articles about the impending update to the C++ Standard, likely to issue in draft form later this year. From a game developer standpoint, the feature that is most exciting is rvalue references, which has the promise to change what today are copy operations into "perfect forwarding" operations. This will drastically improve the speed of STL containers, for instance. You can read what Bjarne has to say about about rvalue references here.

Gamefest 2008 Preview

Thu, 17 Jul 2008 18:41:56 GMT

Gamefest 2008 (Seattle edition) is only a few days away: July 22-23. Gamefest comes to London on August 6th, and to Tokyo on September 4th.

Expect some exciting announcements from the keynote on Tuesday morning, July 22nd.

Some new/enhanced things this year:

The conference has expanded from one to two floors at the Seattle Convention Center.
Many Microsoft game technology teams will have booths at the expo; this is a unique opportunity to meet directly with the folks creating technology you rely upon.
There are some "virtual" tracks this year, collections of talks that span the normal tracks. For instance, there's a virtual track for some of the exciting new features that we announced at E3.

Hope to see you there!

My Favorite C++ Feature

Thu, 10 Jul 2008 23:41:08 GMT

What's your favorite C++ feature? There are many to choose from. Encapsulation and polymorphism. Library features like iterators and algorithms. Templates and generic programming.

My favorite feature: destructors.

Destructors and C++ go together like peanut butter and jelly. I do my best work in destructors. So does much of the standard C++ library. Think about it for a moment. Our friend stl::vector would be a very poor container without a destructor. And tr1::shared_ptr would not be much use at all.

When I review code, I often find that the addition of a class or two with the right destructors can turn unreadable code into sublime code.

Here's food for thought: the proper use of destructors and owned pointers (using shared_ptr or something similar) can eliminate resource leaks completely. A worthy goal indeed.

Fine Gems

Thu, 12 Jun 2008 16:42:17 GMT

An exciting new package arrived on my doorstep this week: a copy of Best of Game Programming Gems, edited by my friend Mark DeLoura. I've contributed many gems to this series over the years, and I edited the networking and multiplayer section in Game Programming Gems 4. The new Best Of volume includes four of my gems. Mark did a good job on choosing the best ones:

Custom STL Allocators
Utilizing Multicore Processors with OpenMP
Secure Sockets
Bit Packing: A Network Compression Technique

There are dozens of other great gems covering math, physics, AI, graphics, networking and audio. Check it out!

Const input parameters and typedefs

Thu, 05 Jun 2008 17:28:52 GMT

In good API design, one specifies unchangeable data that's passed by pointer as const:

void foo( const Stuff* pConstantStuff );

The compiler will guarantee that the "Stuff" pointed to by pConstantStuff is not modified by foo(). This is goodness. Microsoft APIs have a habit of using typedefs for structures, ala:

void foo( const STUFF* pConstantStuff );

In fact, some people even use typedefs for pointers to structures:

typedef Stuff* PSTUFF;

And they write the API like this:

void foo( const PSTUFF pConstantStuff ); // Evil; this does not do what you expect!

That last version is not code you ever want to write! What it seems to promise is not what it actually promises. The compiler interprets it as:

void foo( Stuff* const pConstantStuff ); // weird but technically correct

This version guarantees that the pointer itself cannot be changed by the function. However, the contents of pConstantStuff are no longer constant. The code can change the contents and the compiler will happily oblige! There are two solutions. Solution one is to create a const version of the typedef and use it where appropriate. Here's how winnt.h does it for strings:

typedef char *LPSTR;

typedef const char* LPCSTR;

The preferable solution is to avoid typedefs for pointer types and use const directly whenever you need it. Use const whenever you possibly can. In return, you get readable code that clearly expresses the intent -- and the compiler properly enforces the intent.

BoostCon 2008

Thu, 29 May 2008 16:22:05 GMT

I spent the week of May 5-9 in Aspen, Colorado attending BoostCon. BoostCon is all about Boost, a collection of free portable C++ source code libraries.

This is the second year of the conference. There were about 80 attendees, including C++ luminaries, Standards Committee members, Boost library authors and Boost library power users. The reason I attended is because the conference includes discussions on hardcore C++ usage plus future language and library features. Many of the Boost libraries (there are about 80) are already in the draft of the next version of the C++ Standard, and much of the work that happens in Boost libraries leads to new language features and new library components. Being at BoostCon is a bit like travelling to the future of C++.

Conference Takeaways

C++0x (the next version of the C++ Standard) takes big steps toward improving the efficiency of code -- a big win for game developers.
C++0x has a lot of new features. Most of the new features are not language features, but new standard libraries. Most of the language features are designed for library writers.
You can find the current working draft of C++0X (May 2008) at http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2606.pdf. Lots of goodness to sink your teeth into.
Concepts, one of the most significant potential language features, is not in the draft. However, it is still being considered for inclusion.
Borland has re-energized its C++ effort and is working on a C++0x compiler.
Meta languages continue to be a surprising mini-topic. Observed C++ meta-languages from this year included:
- template metaprogramming (of course)
- boost::format language
- regex regular expression language
- boost::spirit simple grammar parser
- boost::parameter function definitions

Here's one of my favorite new features of C++0x. I hate writing code like this:

for( std::vector<Stuff>::iterator i = v.begin(); i != v.end(); ++i ) // C++ today

Wouldn't it be nice if the compiler just knew what i was. It has to be the return type of v.begin(), right? C++0x allows you to avoid all that crazy typing:

for( auto i = v.begin(); i != v.end(); ++i ) // C++ in the future

That gives you a tantalizing glimpse of one of the many new features we have to look forward to in C++.

Gamefest 2008 is Coming

Thu, 01 May 2008 17:07:12 GMT

Put it on your calendar: July 22-23 in Seattle. Gamefest is coming! If you've been to Gamefest in the past, you already know it's the ultimate place to get the latest and greatest information on creating games for Microsoft platforms like Xbox 360 and Windows Vista. If you work on games and you haven't been to Gamefest, you're missing something really special. I've already seen some of the proposed talk abstracts, and you can expect some amazing content from excellent speakers.

www.xnagamefest.com

I Hate to Wait

Fri, 18 Apr 2008 20:07:18 GMT

I admit to a certain fondness for first person shooters. I got hooked on Half-Life, but it was the Halo series that really put me over the edge. I particularly enjoy multiplayer fragfests. Most session-based games these days follow a model where you search for a particular session and either join an existing one or start your own. Either way, players are left waiting for the game to start when the session fills up with a certain number of players.

Players hate to wait, so it's always a good idea to reduce or eliminate wait times. The wait times for sessions can be described fairly simply:

WaitTime = GameModes * SessionTime * Players/Session / PlayersOnline

Wait times rise when:

there are many game modes (deathmatch, capture the flag, etc.)
the average session time is long
the average number of players per session is high
there are fewer players in the overall pool of available players

Wait times decrease when:

there are fewer game modes
the average session time is short
the average number of players per session is low
there are many players in the overall pool of available players

Games that group players by skill (Halo 2 and Halo 3 are examples) add another factor. The more skill groups you have, the longer the wait times.

These factors are mostly in your control as a game designer and developer. If you want to reduce wait times there are multiple knobs to tweak. If you add a new multiplayer game mode, be aware that it will impact session wait times. Keeping sessions short is a great way to minimize waits. There are other ways, too. For instance, allow players to do something while they're waiting: chat, practice their skills, or watch something interesting. Of course, the most important thing you can do is ensure your game is great, because that will improve the overall pool of available players :).

When It Rains

Sat, 29 Mar 2008 00:23:01 GMT

One of the finest engineers I know, Bruce Dawson, pointed out a fatal flaw in my GDC 2008 string code. Even more devastating, it's not a subtle flaw. This one was staring me right in the face and I didn't even see it. Recall the code:

char* s = "abcdef";

char u[] = "def";

u[0] = 'x'; // danger, NOT!

According to the C++ Standard, string literals can overlap in memory, so the "def" string could overlap with the "abcdef" portion. That much is still true. However, the "u" string is a copy of "def", not a pointer into it. When you declare a string with angle brackets, you have a character array, not a string pointer. You can modify the "u" string to your heart's content and it will never ever modify "s". That's because "u" is a character array, not a pointer.

Here's a revision:

char* sz = "abcdef";

char* uz = "def";

char vz[] = "ef";

assert( (uz < sz) && (uz > sz+6) ); // invalid assumption

sz[n] = 'x'; // undefined behavior

uz[n] = 'x'; // undefined behavior
vz]n] = 'x'; // perfectly reasonable, as long as n < 2

Now we have two string pointers that point at literals. The "def" portion could overlap with the end of the "abcdef" portion in memory, so it's not safe to assume that the pointer uz does not point somewhere within the sz range. Modifying the literal is still not allowed, even though we've declared non-const pointers (2.13.4/2 says "the effect of attempting to modify a string literal is undefined"). Finally, the character array vz contains a copy of "ef" and we can modify vz safely.

As I said when I was giving the talk, C++ is a complicated language. It's up to all of to continue educating each other about the nuances. Sometimes explaining your bonehead mistakes is the best way to continue the education process.

GDC 2008 Slides

Wed, 27 Feb 2008 19:06:39 GMT

I've had a lot of requests for my GDC presentation from last Thursday. Although I've made the slides available to the good people at CMP for posting on gdconf.com, they aren't available yet. You can find a copy on my personal website by pointing your browser at http://www.tantalon.com/pete.htm.

A couple people mentioned an error in my talk. I showed some code like this:

char* s = "abcdef";

char u[] = "bcd";

u[0] = 'x'; // danger

According to the C++ Standard the string "bcd" could overlap with the string "abcdef". That's incorrect, because "bcd" must end with the null character. I've adjusted my slides to show something accurate:

char* s = "abcdef";

char u[] = "def";

u[0] = 'x'; // danger

Now "def" could indeed overlap with "abcdef" and changing "def" could change the "abcdef" string. Big takeaway: don't modify string literals.

GDC 2008 Recommendations

Fri, 15 Feb 2008 17:14:07 GMT

GDC is next week. It's an event I always look forward to: a chance to see old friends that I've worked with over the years, a chance to hear what's top of mind for game developers, an opportunity to see new technology and hear from some great speakers. Here's a few of the talks that I'll be trying to see:

Ray Kurzweil's keynote

Design Reboot

Standing the Test of Time (Sid Meier!)

Structure vs. Style

Any of the Halo3 presentations, particularly Matchmaking in Halo 3

Dynamic Performance Profiling of C++ Code

The Art and Technology Behind BioShock's Special FX

Taming the Mob: Creating believable crowds in Assassin's Creed

Expect some tasty announcements at the Microsoft XNA keynote.

I also have a feeling this talk will be pretty cool -- if a tad scary: Thrills and Chills: Undefined Behavior in C++.

Hope to see you there!

Underscores and Identifiers

Fri, 01 Feb 2008 17:08:23 GMT

In preparation for my upcoming GDC presentation in San Francisco, I've been reading lots of Standards documents, both C99 and C++03. Fun stuff. I was reminded of some important guidelines for C++ identifiers. Identifiers include macro names, variable names and function names. Consider the following code:

// TreeImpl.h

#ifdef TreeImpl__H

#include <map>

class _TreeImpl

{

private:

Tree* _pTree;

// etc.

}

#endif // TreeImpl__H

Looks innocuous enough. But there's bad mojo hiding here. Here's what the C++ Standard says (17.4.3.1.2): "Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter is reserved to the implementation" and "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace."

In other words, the identifiers TreeImpl__H (double underscore), _TreeImpl and _pTree (leading underscores) are hidden bombs just waiting to explode. Should some future version of <map> include the following macro:

#define _pTree (_p->_tree_item->getTreePtr())

all hell will break lose. Programmers commonly look at implementation code, particularly Standard C++ header files, see the use of leading underscores and double underscores, and assume they are perfectly legitimate. Don't fall into this trap. Unless you write compilers and standard libraries, follow these rules to avoid tears:

Never use double underscores in C/C++ code.
Never use leading underscores in C/C++ code.

Update your coding conventions appropriately.

Shared_ptr swap, and more

Thu, 17 Jan 2008 20:05:49 GMT

One of the benefits of working at a big technology company is the ability to attend talks presented by smart people. Yesterday I went to hear Stephan T. Lavavej, aptly known within the halls of Microsoft as STL. STL works on Visual Studio C++ libraries, including the C++ Standard Template Libraries (STL). His talk was on one of my favorite TR1 topics, shared_ptr.

I've been using shared_ptr for a while, and have spent some time understanding Boost's implementation, so most of the presentation was just a refreshing review. However, some things were quite illuminating. I'll talk about two illuminations, one technical and one philosophical.

The technical item I learned was about swapping shared_ptr. Consider a canonical swap of shared_ptr:

shared_ptr<int> a( new int(1) ); // suppose we have two shared pointers

shared_ptr<int> b( new int(2) );

{ // now we swap them

   shared_ptr<int> temp = a; // refcount of int(1) ++

   a = b;                    // refcount of int(1) --, refcount of int(2) ++

   b = temp;                 // refcount of int(2) --, refcount of int(1) ++

}                            // refcount of int(1) --

In the course of performing the swap, reference counts are modified six times. Because shared_ptr is threadsafe, refcount operations must be performed atomically, probably using some form of interlocked operations, which adds to the expense. Additionally, most (if not all) shared_ptr implementations store their refcounts in some area internally allocated by shared_ptr, so accessing the reference counts themselves required dereferencing pointers -- six times. All we wanted to accomplish is swap two pointers, but there was a lot of needless overhead. The solution? Use shared_ptr::swap() instead:

a.swap( b ); // at least as fast as above, and considerably faster if you have a decent TR1 implementation

In VC9 TR1, shared_ptr::swap() does just what it needs to do and no more. The refcounts are never touched. Only the pointers are swapped. The VC9 TR1 version of free swap (e.g. swap( a, b )) is similarly optimized. Sweet.

The philosophical item I absorbed was just why shared_ptr completes the resource management picture for C++. Consider what we have without TR1. We have destructors, a deterministic resource release mechanism. We have: scope lifetime ("between the braces"), data member lifetime and container element lifetime, all of which are deterministic. And we have dynamic resources, which do not have a deterministic lifetime, but depend on us programmers to get it right. Therein lies the fatal flaw. Avoiding dynamic resource leaks, double deletions and so forth is Really Hard. That's the problem shared_ptr solves, and it solves it extremely well. In the face of exceptions, in the face of early exit from functions, and even in the face of code that is modified over time, shared_ptr Just Works. I used to think of shared_ptrs as just a good way to copy around heavy-weight objects. Now I think of shared_ptrs as the default owner for any dynamic resource.

GCAP Slides

Thu, 10 Jan 2008 17:18:30 GMT

I've had many requests for the slides that I presented at the Game Connect: Asia Pacific talks in November. Ask and ye shall receive. All of my presentations were based on information given at Gamefest 2007. Links below. Enjoy!

Multicore Programming, Two Years Later

A technical talk on what we've learned about effective multicore programming on Xbox 360.

Effective Game Programming for Windows Vista

The lowdown on programming for Vista, 64-bit Windows, D3D10 and Games for Windows -- LIVE.

This was a combination of five different talks from Gamefest:

Just Make Windows Work

Why Your Windows Game Won't Run in 2,147,352,576 Bytes

Windows to Reality: Getting the Most Out of Direct3D 10 Graphics in Your Games

Are Your Games "Games for Windows" Ready?

Bringing the Best of Xbox LIVE to Windows

A Baker's Dozen: 13 Tools and Technologies for Your Next Game

The latest tech in the Xbox 360 XDK and DirectX SDK and why you should consider using them for your next project.

TR1 coming to Visual Studio

Thu, 20 Dec 2007 16:57:54 GMT

I've blogged about TR1 before, and spoken about it, too. It's one of the coolest new C++ libraries. The smart pointers alone are worth their weight in gold. Some good news was recently announced: TR1 is coming to Visual Studio 2008. Here are some details:

The TR1 library is expected to ship in the first quarter of 2008, with a beta sometime early in the New Year.
The Microsoft TR1 implementation will contain everything described in the TR1 spec except sections 5.2 (mathematical special functions) and 8 (C compatibility).
The Visual Studio debugger will be able to visualize TR1 types just like with the STL. Way cool.
Mucho optimization work has gone into the implementation to ensure that Visual C++ STL and TR1 play nice. For example, containers of TR1 types will be more efficient because they understand each other's implementation details.

If you've put off looking at TR1 because it's not provided out of the box with Visual Studio, that excuse will no longer fly. Check it out!

Sixth graders: the next gen of game devs

Thu, 13 Dec 2007 18:30:51 GMT

Last Friday I spoke with three different local sixth grade classes about making games. It's always a kick to connect with some younger gaming consumers. Here are some notes I've compiled should you ever find yourself talking to two dozen 11-year-olds about your job as a game developer:

Sixth graders haven't thought about frame rates. When asked about how often a new frame needs to be displayed in order to get the feeling of motion, the answers went as high as 1,000,000 times per second.
Sixth graders are observant. We evaluated a game screenshot and identified "things that the game had to figure out" in order to generate the frame. The list was long: character animation, collisions, dust (particle effects), vehicles (physics), projectiles/weapon-fire, water effects, lighting, shadows, music, sound fx, and cloth. When we were done we had covered just about everything that might happen in a typical game loop. The things they didn't think about (because they're not obvious from a screenshot) were input and networking.
Sixth graders aren't afraid to ask tough questions: why does my Xbox 360 have three red lights? when is Microsoft going to make a new console? how are you going to compete with Wii? why does game <X> always stutter or freeze?
Sixth graders have lots of good ideas: you should make a trivia game that uses Xbox LIVE; you should make Xbox 360 smaller so I can take it to my friend's house; you should partner up with Nintendo so you can use Wiimote on Xbox 360; you should make Xbox 360 cheaper so my parents will buy me one for Christmas.

If you ever get the chance to talk with future game programmers at your local school, do it. All you need is a couple of good trailers to set the stage, some screen shots that you can discuss in detail, and a willingness to answer some pretty off-the-wall questions.

Console Cage Match

Thu, 29 Nov 2007 23:03:03 GMT

Not long ago somebody pointed me at a blog entry entitled PS3 misconceptions and spin, which basically says it's hard to make games for PS3. I'm not going to comment on the content itself (nor on the inflammatory blog comments). I work on game technology at Microsoft and am inherently biased. Anyway, the article could just as well have been written about any game console. The console game development business is tough no matter what hardware you target.

The whole thing reminded me that consoles are successful for a variety of reasons. Just because a console has great performance compared to its competitors doesn't mean it will be successful. Wii is doing just fine, thank you. And just because it's difficult to create games on a console doesn't mean the console won't be successful, either. Witness PS2.

At GDC 2007, Don Daglow gave an illuminating talk on what really makes game consoles successful. His key criteria to winning the console war:

Price parity (consumers feeling like they get good value for their money)
Critical mass of good games
Reliability
Faith the hard core gamer

Don made sure to point out that there were many differences in the console war we're experiencing today, mostly around social gameplay (MMOs, multiplayer, voice chat, innovative controllers, casual games and so forth), and the social gameplay aspect might also factor into the "winner" as well. Notice that neither "ease of programming" or "hardware performance" were in Don's criteria list. As Arsenio liked to say, "Things that make you go Hmmmm...."

Aussie Game Studio Enthusiasts

Wed, 07 Nov 2007 16:56:01 GMT

As part of my trip next week, I'll also be spending time at some informal enthusiast meet-ups in Sydney and Melbourne. Here are the details:

Sydney Event: http://xnasydneypeteisensee.events.live.com/default.aspx

· Date: Nov 14^th 2007 @ 6:30PM

· Location: Microsoft Sydney Office

Melbourne Event: http://xnamelbournepeteisensee.events.live.com/default.aspx

· Date: Nov 16^th 2007 @ 6:30PM

· Location: Microsoft Melbourne Office

I'll give a brief preview of what you can expect in the new version of XNA Game Studio and the XNA Framework, and be available to answer questions about your own Game Studio projects. Hope you can join me...

Game Connect Asia Pacific 2007

Tue, 06 Nov 2007 01:32:30 GMT

Next week I'll be spending a week down under. I'm giving talks at the Game Connect Asia Pacific conference in Melbourne, so if you're in the area, be sure to stop by!

Talk list

Multicore Programming, Two Years Later: A detailed technical talk on what we've learned about effective multicore programming on Xbox 360.

Effective Game Programming for Windows Vista: The lowdown on programming for Vista, 64-bit Windows, D3D10 and Games for Windows -- LIVE.

A Baker's Dozen: 13 Tools and Technologies for Your Next Game: The latest tech in the Xbox 360 XDK and DirectX SDK and why you should consider using them for your next project.

Gamefest 2007 Talks Posted

Tue, 16 Oct 2007 16:47:21 GMT

Gamefest content is now available online: http://www.xnagamefest.com

Due to some audio snafus, not all the talks include the audio recordings. Those responsible have been soundly thrashed (pun intended). Enjoy!

Randomness, binary numbers and floating-point arithmetic meet Mr. Benford

Thu, 20 Sep 2007 18:54:22 GMT

Suppose you're looking for sources of random numbers. You choose numbers from a newspaper. How random will the numbers be? Answer: not very. This surprising result is called Benford's Law. This law says that real-world numbers (measurements, populations, stock prices and so forth) are distributed logarithmically. More specifically, the leading digit of a given real-world value is 1 about 30% of the time (instead of 10% of the time, as you might expect), and leading digit is 9 less than than 5% of the time (again, not the expected 10%).

There are many fascinating things about Benford's Law. For instance, even though the law was discovered in the late 1800s, it was only proven only 10 years ago. More interestingly, the IRS uses Benford's Law to detect fraudulent tax returns.

Eric Lippert makes the case in his blog that Benford's Law means that binary numbers are actually the best way the do accurate floating-point math calculations on real-world numbers.

I find the intersection between mathematics and the real-world to be absolutely fascinating.

Chickie Baby

Thu, 13 Sep 2007 16:36:15 GMT

There are many constants at Microsoft. Offices moves are one of my least favorite. After nearly seven years at Microsoft, I've only moved once, a badge of honor I wear proudly. I know many people who've moved more than seven times in seven years. But all good things must come to an end. My team is moving -- not far, just from the second floor to the first floor of the same building. Why? Don't get me started.

The good thing about moves is that it forces me to clean up. I hate moving anything that I don't need to. As I was going through old folders yesterday, I ran across something from my Peopleware days. Peopleware was my first official job out of college. I was one of two programmers, so I did just about everything, from customer support to testing to managing the company network to writing lots and lots of code. During my last year there, I wrote a document describing all of our best practices. The programming team had grown to six people by then, and I was the senior programmer -- despite being only 25 years old. Here's a snippet from that document:

The Chicken

The rubber chicken (affectionately known as "Chickie Baby") is the development team's light-hearted way of saying "you screwed up." Normally, somebody on the team will voluntarily claim the chicken when they have made a mistake. However, you can also receive the chicken if another team member discovers that you made a mistake.

The cool thing about the chicken is that you have to explain your mistake to everybody else when the chicken lands in your in-box. Mistakes become a way to share information so that other team members can avoid your specific mistake in the future. This way, you not only learn from the mistake, but everybody else on the team learns from it, too.

The chicken is just one other way the development team helps each other avoid mistakes, which in turn leads to better products.

I've seen lots of takes on Chickie Baby over the years, such as a stuffed alligator, as well as an actual toilet that was given to programmers that broke the build. Whatever lighthearted form it takes, your team's Chickie Baby is a great way of sharing information, particularly between gurus and the newest members of your team. If you don't have a Chickie Baby, today's a great day to find one.

Unordered Associative Containers Part II

Thu, 30 Aug 2007 21:38:17 GMT

A few months ago I talked about hash tables, known in TR1 as unordered associative containers, and hinted that's what really interesting about them is how they work under the covers. Of course, neither TR1 or the C++ Standard describe how to implement containers. These documents only describe how the containers must behave.

When I analyzed unordered associative containers (UACs), I looked at one specific implementation, the Dinkumware version. The requirements on UACs are simple. Insertion must be average time complexity O(1) and worst-case complexity O(n). Search performance must be the same: constant time on average, and linear in the worst case. This is the true distinction of hash tables. Unlike associative containers, which have O(log n) complexity for insertion and find, UACs can do much better: constant time insertion/find. The drawback of UACs is that performance can degrade to worse than log n: linear.

Hash tables work by hashing elements into buckets. The perfect hash table has one element per bucket. A good hash table has a handful of elements in each and every bucket.

The Dinkumware implementation of UACs is simple but clever. Elements T are stored in a single std::list<T>. Buckets each contain a single iterator that points somewhere into the list. Hence, buckets is defined as vector of iterators, a std::vector< std::list<T>::iterator >. When a new element is added to the UAC, it is hashed to determine its bucket. If the bucket is empty, the element itself is added to the list and the bucket iterator is changed to "point" to the element in the list. If the bucket already points into the list, the element is inserted into the list. The clever part of the implementation is the use of a single std::list data structure to represent the "mini-lists" of each bucket. There's a picture on slide 20 here that gives you a visualization. Unfortunately the PDF doesn't animate, but you'll get the general idea. Notice that int elements 2 and 7 both hashed to the same bucket. The bucket points to the 2, which is followed by the 7. The next element in the list is 4, but because the iterator to element 4 is in the next non-empty bucket, we know that 7 is the last element in the bucket. The Dinkumware implementation uses this little trick to avoid having a unique list per bucket. The single list represents all the bucket lists.

I haven't had the chance to look at other implementations, but I'm sure it would prove a very interesting exercise.

Performance Intuition

Thu, 23 Aug 2007 20:02:03 GMT

Recently I had a conversation with Scott Meyers about performance issues. One of the topics that came up was how our performance intuition often sucks eggs. There are so many factors that change, yet our basic assumptions remain the same. For example, there are still mainstream game programmers who try to avoid floating-point math because their performance intuition says "floating-point math is slow." This performance intuition is usually backed up with past evidence that indicated floating-math was indeed slow. However, this intuition fails to take into account that the floating-math was slow on:

a particularly platform

with a particular compiler or virtual machine

using a particular algorithm

on a particular operating system

or using a particular library.

Any one of these things could change our performance intuition of floating-math, but if we haven't measured the change, our intuition is unlikely to shift. As performance engineers we all understand the need to measure, but as Scott pointed out, who really has the time to measure each potential performance issue on each platform/compiler/VM/library/OS/library?

There's no easy answer to this problem. Part of my role at Microsoft is to help answer questions about performance on various platforms/compilers/libraries, but even that level of education only goes so far. As I like to say in my presentations, it's up to all of us to change the world. When you make a new discovery about performance, educate your team. Get the word out. We can only make true progress collectively.

Bjarne Reviews the Last 15 Years of C++

Thu, 09 Aug 2007 22:50:04 GMT

I love C++. There's no other way to say it. C++ permeates the world of software. C++ technology permeates our lives. C++ is one of the most amazing inventions of all time, and yet the vast majority of the world doesn't even know about it. That's a shame.

Bjarne Stroustrup, the inventor of C++, is still a very active participant in the C++ community and standardization process. I recently read one of his latest papers where he examines how C++ has evolved over the past 15 years. He debunks a lot of myths and provides a surprisingly objective viewpoint of where C++ has succeeded and where it has failed. A fun one-evening read.

Gamefest 2007 is Coming

Fri, 13 Jul 2007 23:58:12 GMT

Game developers from around the world will be converging in Seattle again this August 13-14, 2007 for Gamefest, Microsoft's premier conference on game development. This year there are two full days of talks, spread among 9 different tracks and featuring some of the best technical presenters in the world. I'm very involved in Gamefest again this year, and we just have an amazing lineup of talks.

Here are some of the programming presentations that you're likely to find me checking out this year:

Profiling Tools and Techniques: New Guidelines for Finding Where Your Time is Going. Bruce Dawson is not only an amazing performance engineer, but he loves to share his knowledge, and he gives the best technical talks on the planet. A must-attend.

VMX Optimization: Taking It Up a Level. "Taking It to the Next Level" is the conference theme. If you do Xbox 360 CPU programming and really want to optimize the hell out your game, Ian Lewis' talk is just what the doctor ordered.

Static Code Analysis on Game Code. Marwan Jubran is one of the true experts at Microsoft when it comes to code analysis. You'll definitely learn some exciting things about Visual Studio in this talk that will really improve the quality of your game code.

From the Trenches: Xbox 360 Development War Stories. Kutta Srinivasan has worked directly on some of the most killer games on Xbox 360, and his expertise is sure to be informative and useful.

TCR Failures, Taxes, or Death: Which One Can You Prevent? Darin Metzler knows a thing or two about TCRs, having worked in many roles on the certification team, and having a great understanding about game development. Plus he's one of the most cheerful testers I've ever met.

Ndrstndg Prseptul Adyo Cmprshn Scott Selfon and Ian Lewis have come up with the best title of the conference, and one sure to be full of meaty technical audio details, good anecdotes and perhaps a bit of fun, too.

Adding Creamy Nougat and a Crisp Candy Coating to the Network: XRNM and QNet Vance O'Neill is the quintessential network programmer, if there is such a thing. It's not often you hear directly from the programmer that actually designed and coded the technology -- here's your chance.

The Costs of Managed Code: The Avoidable and the Unavoidable Rico Mariani is a performance expert who's known not only throughout Microsoft but throughout the whole programming community. A great speaker, too. Even if you're not writing managed code you'll learn something interesting.

Windows to Reality: Getting the Most out of Direct3D 10 Graphics in Your Games Shanon Drone understands D3D10 better than just about anybody on the planet, and he's ported a number of significant game engines to D3D10, so his insight should be particularly relevant.

The full list of talks is posted at http://www.xnagamefest.com/talk_abstracts.htm and you can register for the conference here: http://www.xnagamefest.com/register_now.htm. It's only $450 if you register before July 19th, an amazing value for the quality of the content and the quality of the speakers. See you there!

Game Networking: Back to the Basics

Thu, 28 Jun 2007 23:09:38 GMT

I wrote some comments on game networking last November, but we're still seeing games with the same issues, so I'm going to add a few more recommendations.

In comparison to other technologies, basic sockets programming hasn't changed much over the past 10 years. 10 years ago, game programmers were writing Direct3D 3.0 code. Today they're writing D3D10 code. Playstation was the latest console 10 years ago. Today it's Xbox 360 and PS3. The Winsock of 10 years ago, however, is the same as the Winsock today, and the same techniques still apply:

Avoid small payloads. The packet overhead kills your bandwidth.
Don't send data too often. The best networked games send packets 10-20 times per second.
Prefer UDP over TCP. The overhead of UDP is smaller, plus UDP doesn't automatically resend dropped packets like TCP.
Assume that it could take seconds for packets to arrive at their destination and build your engine accordingly. The Internet does not have the same characteristics as a local network.
Don't assume your packets will arrive at their destination. The Internet is a crazy place.
Consider some form of secure packet authentication scheme. Hackers love to modify packets. Some platforms provide this feature automatically (Xbox) or provide it in library form. For games, it's usually worth the effort to protect your packet data.
Consider some form of packet encryption. Even if packets are authenticated (can't be changed), hackers can still cheat just be looking at packet data and dropping specific packets on the floor.

Building a good networking engine is hard, and it's not glamorous work, either. But your game players will definitely notice if you've spent the time to do it right.

Herb Sutter on C++0X and Performance

Mon, 25 Jun 2007 21:50:22 GMT

In my previous post I talked about BoostCon and gave a bit of insight into C++0X. Herb Sutter recently posted links to some other interesting talks about C++0X that you might enjoy. You can find those here.

Herb also talked about new C++0X features in his blog about the last Standards Committee meeting.

Finally, Herb recently gave a talk about hardware architecture and what it means for programmers. You can find a copy of that talk here. If you're writing games for Xbox 360 or PS3, much of this talk is old news. If you're writing games for the PC, you may be surprised at some of the key takeaways. I'll list a few:

The root of all hardware complexity is latency. Modern processors reserve a huge amount of die area for systems that compensate for latency. Understanding these systems is the key to maximizing performance.
On modern architectures, math is fast. In fact, it's almost always faster than fetching data from RAM. This fact alone should cause you to think twice about old optimization techniques like early-outs and pre-computed tables.
On modern architectures, floating-point math is often as fast or faster than integer math. Don't automatically assume it's slower.
Keeping data in the L1 and L2 cache are hyper-critical for maximizing performance. It's always been critical for performance, but it's even more important now than ever before.

Good stuff, and very relevant to game programming.

BoostCon

Thu, 17 May 2007 23:59:06 GMT

This week I've been at BoostCon, a C++ conference focused on the Boost libraries, TR1, TR2 and C++0X. The weather here in Aspen, Colorado has been fantastic. I was expecting cool temperatures (Aspen is at 8,000 feet elevation), but it's been sunny and in the 70s every day. The conference organizers wisely gave us 2+ hour lunch breaks every day, so I've had the chance to explore downtown, go hiking, and mostly keep up with work email, too. Aspen's a pretty hip place -- an unlikely combination of old mining town mixed with modern ski resort plus a dash of Beverly Hills thrown in for good measure. It surely has more excellent shops and restaurants per capita than anywhere else on earth.

A few things have struck me about the conference. First, there are a lot of really talented C++ developers who are expanded and extending the language in amazing directions. Second, one of the unstated themes of the conference is C++ metaprogramming. Scott Meyers talked about how many meta languages there are in C++. Here are a few: printf formatting (one of the most cryptic, surely), template metaprogramming, iostream input and output, lambda functions, and coming soon in C++0X, concepts. Third, game developers have some exciting things to look forward to in C++0X.

C++0X is the code name for the next version of the C++ Standard. The hope of the C++ Standards Committee (many of whom are at the conference) is that the next version will be in place by the end of the decade -- hence the 0X, hopefully meaning '09. The running joke is that 0X may turn out to mean 0A or 0B, but we'll see. At least two things in C++0X are extremely compelling for game programmers: rvalue references and concepts.

Rvalue references are a new type of reference. The advantage of rvalue references is that in many cases they allow objects to be moved rather than copied. As Andrei Alexandrescu has said, "creating, copying around, and destroying temporary objects is the favorite indoor sport of your C++ compiler." This copying behavior causes huge bottlenecks in games. We tend to work around that behavior in all sorts of unnatural ways: copy-on-write objects, smart pointers, and so forth. With rvalue references, the problem Just Goes Away. With C++0X, the STL will be updated to support rvalue references and move constructors. Howard Hinnant, the designer of rvalue references, showed example code using the STL that ran 7X faster with C++0X. Yes, 7X faster. That's the kind of optimization I like to see.

Concepts are a new, well, concept in C++. They allow you to state requirements for template code that are validated at compile time rather than at template instantiation. Today, using any type of template code is an exercise in frustration for most programmers. Errors give little indication of whether the problem lies in the template itself or in the programmer's use of the template. Concepts change the whole equation, allowing template code to be fully validated by the compiler. I predict that concepts will finally allow the average programmer to use template libraries with ease, gaining all the performance advantages of templates without all the pain.

I can't wait for C++0X.

Unordered Associative Containers

Thu, 10 May 2007 23:53:51 GMT

Last time I introduced what will likely be adopted into the next version of the C++ Standard, a new type of container called unordered associative containers. By parsing the name of this new container type, you can determine a lot of useful information. First of all, these containers, unlike sets and maps, are unordered. Traversing these containers results in an unordered list of elements. If you want an ordered list, you need to use set/map or vector+sort or some other solution.

Secondly, these containers are associative. That means elements can be compared in a meaningful way. However, unlike set/map, which require the programmer to supply a "less-than" form of element relationship, unordered associative containers require a "equivalent" form of element relationship (operator ==() ).

Finally, these are true STL containers. They support iteration and the other basic concepts of what it means to be an STL container. For example, they support functions like empty(), begin() and end().

Declaring an unordered associative container is easy. Here's an example:

std::str1::unordered_set< int > us;

You add items to this container in the same way that you might add items into a standard set:

us.insert( 42 );
us.insert( 1005 );
us.insert( 3 );

And you can find an item just like you'd expect, too:

if( us.find( 42 ) != us.end() )
// element found

What's really interesting about unordered associative containers is what's going on under the covers. Tune in next time...

STL Lookups

Thu, 05 Apr 2007 20:29:57 GMT

If you want fast lookups using STL, you currently have two choices:

1) Use a sorted container, like [multi]set or [multi]map and the find() member function

2) Use a non-sorted container, sort it (using std::sort() or similar function), and search using std::binary_search() (or lower_bound() et al)

Both of these options provide log N search performance, which is nothing to sniff at. But there's a potentially much faster option: hash tables. Hash tables can provide constant-time lookup performance in the best case. The tradeoff is that worst case performance is linear. Unfortunately, the STL doesn't provide hash tables. This makes me sad.

Hash tables were originally proposed for the C++ Standard over 10 years ago, but weren't adopted, primarily because the proposed interface was still too new and unproven.

Some vendors have provided non-standard solutions, but with TR1, there's a new option, very likely to be adopted into the new version of C++ Standard within the next couple of years. That new option has an exciting new name. Wait for it ...

Unordered associative containers

OK, maybe not so exciting. What is exciting is that now there's a third option for doing fast lookups. These containers have lots of interesting dials and levers -- more so than sets or maps -- that allow you to tweak the size/space tradeoff for maximum performance. This makes me happy. More next time.

GDC 2007 Talk Posted

Thu, 29 Mar 2007 17:37:45 GMT

You can now find a copy of my GDC 2007 presentation at https://www.cmpevents.com/sessions/GD/S3720i1.pdf. Enjoy!

Getting Started with TR1

Thu, 29 Mar 2007 17:04:03 GMT

My topic at GDC was Technical Report 1 (TR1), an "informative document" that includes new C++ library features that are highly likely to become a part of the next C++ Standard. You can download versions of TR1 from the following places:

www.dinkumware.com

www.boost.org

gcc.gnu.org

www.metrowerks.com

Using TR1 is easy. Just include the header file that contains the feature you want, qualify the namespace by using std::tr1, and away you go. Here's a quick example:

#include <array> // new fixed-size array container

std::tr1::array< int, 4 > a; // fully qualified name; note size is template param

// more common usage

using namespace std::tr1;

array< int, 4 > a = { 1,2,3,4 }; // cool -- you can even initialize using standard array initialization

If you've ever been frustrated that you couldn't use C-style arrays in a similar fashion as other C++ containers, tr1:array is the container for you. Now you can do things like sort:

std::sort( a.begin(), a.end() );

and size extraction:

for( int i = 0; i < a.size(); ++i )

just as if the array was any old STL container. Naturally tr1::array performance is the same as for C-style arrays. For example, a[x] produces the exactly the same code when 'a' is a tr1::array as when 'a' is an old-fashioned C-array.

However, TR1 arrays aren't true containers. For instance, they can't grow (no resize or reserve or push_back). And swaps of arrays (array.swap()) are not constant time operations like they are for vector, deque, list and so forth -- array swaps are linear.

Nevertheless, I'll be using TR1-style arrays much more than C-style arrays in my own code. All the benefits far outweigh the minor drawbacks.

That Which We Call a Rose

Wed, 21 Mar 2007 22:32:37 GMT

I've worked at Microsoft for over six years. In that time, I've always worked on the same team. However, the team has had a number of different names. Recently, we adopted our third name. Here's the breakdown...

Xbox Advanced Technology Group: The name when I joined, the team consisted of senior engineers helping Xbox developers get the most out of the platform. Mike Abrash was the most famous person on the team, but he was one of many rockstar developers.

Microsoft Game Technology Group: We took on this name when we took on a new role -- supporting both Xbox 360 and Windows game developers. By now the team had grown to two dozen engineers, including the industry-renowned front line developer support team.

XNA Developer Connection: Same job, new name. These days I manage the entire team, and what an amazing team it is. We support all Microsoft gaming platforms in ways big and small. XNA has come to encompass everything that Microsoft developers to game developers. That includes technology like XNA Game Studio Express, but it also includes the Xbox 360 XDK, the DirectX SDK, developer support, and events like Gamefest, along with advanced research into new game development techniques in areas like graphics, audio, and LIVE.

For short, the new team name is XDC. What a great job! I'm in XDC.

Tuning STL in debug mode

Wed, 14 Mar 2007 22:46:39 GMT

I enjoyed another great GDC last week. I must say that San Francisco is a better location than San Jose. There's so much more to do and so many better places to eat. Here are three that I enjoyed: Maya, Ponzu and Puccini and Pinetti.

I believe this was GDC number eleven or twelve for me, and my ninth as a presenter. I still get that same little thrill about first setting foot in the registration area and looking forward to the days ahead. I'll cover some of the content from my talk in my next few entries.

For now, just one quick note, based on a question I got after my presentation.

Q: We use STL. While it performs just fine in release mode, debug mode runs abominably slow. Do you know of any way to address this?

A: Assuming you're using Visual Studio 2005, you can turn certain features of STL debugging on or off. For instance, you can turn off iterator debugging by setting _HAS_ITERATOR_DEBUGGING to zero. More info here.

Game Developer Conference 2007

Tue, 20 Feb 2007 16:47:47 GMT

I'll be at GDC again this year. This is my tenth or eleventh year as an attendee and my ninth year as a speaker. My talk is on C++ (naturally), specifically TR1, an extension to the Standard C++ library with some very cool new features that are relevant to game programming. Here's the abstract:

TR1 is Technical Report 1, a specification of new extensions proposed for the C++ Standard Library. If you're a game developer, there's lots of yummy goodness in TR1, including super-fast hashed containers and smart pointers. Once you throw in other tasty morsels like function objects, type traits and random number generation, TR1 is pretty hard to ignore. This talk covers the aspects of TR1 most relevant to game programming, providing examples and performance analysis.

You'll find me in Room 2007 in the West Hall of the Moscone Center in San Fran on March 7th at 9am (ouch!). Hope to see you there...