LightSleeper

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.

Book List: Book List

Thu, 12 Jun 2008 16:32:02 GMT

Custom List: Blogs

Mon, 14 Apr 2008 17:52:39 GMT

Blogs

Custom List: Websites

Thu, 23 Aug 2007 20:23:11 GMT

Websites

Custom List: Homepage

Thu, 21 Sep 2006 16:31:25 GMT

Homepage

Tantalon.com