Some Assembly Required

This is the week when all of Santa’s Elves who work in game-making-places all over the world take a hopefully well deserved break, so no game development post today. Instead, here’s some nice audio books and podcasts that I’ve enjoyed on my commutes in the past year. Happy Holidays!

• Escape Pod’s short-fiction podcast has not one but two Christmas specials.
• X Minus One, The Lifeboat Mutiny. 50s-era science fiction radio play: two prospectors find themselves in possession of a lifeboat that’s more than it seems. Worth listening to for the Drone National Anthem alone!
• G.K. Chesterton’s  The Wisdom Of Father Brown is available as a public-domain audio book from LibriVox, read by Martin Clifton. I found this collection of short stories about the eponymous priest-turned-private-detective to be fine treadmill listening.
• WNYC’s science documentary special Radio Lab is always a singular pleasure.
• And Subterranean Press was kind enough to produce a free audio book of Charlie Stross’ Trunk and Disorderly, a humorous adventure in a style that defies description (the closest anyone’s come is “Heinlein meets Wodehouse in space with a woolly mammoth”).

I’ll be back next week with some thoughts on replacing floating-point conditionals with branchless math.

In Paul Pedriana’s article on Electronic Arts’ custom STL I came across this Very Good Sentence (well, okay, pair of sentences):

Game applications cannot leak memory. If an application leaks even a small amount of memory, it eventually dies.

I say preach it, brother. I can think of a couple of titles where memory leaks actually hurt a game’s sales. In fact I’ve been known to blame reckless use of new for the death of entire studios. malloc() — there’s no evil too great to lay at its feet.

Paul’s sentence comes in the context of a group of justifications for EA building its own Standard Template Library, which are so concisely spot-on that I’ll reproduce them here. Call them Paul’s Commandments:

Continue reading ‘Sentences That Should Be Carved Into Foreheads’ »

Doesn’t Windows’ built-in dialog for editing environment variables just suck? The one you get when you right-click “My Computer” and go to properties→advanced, I mean. It looks like a holdover from Windows 3.1 — a tiny, unresizable window that shows you at most part of five environment variables, and an “edit” button that leads to a similarly cramped and unresizable pair of forms which are never big enough.

Whenever I need to edit my %PATH% (which is often) I find myself copying the whole thing out of the Windows dialog, pasting it into Notepad, editing it there, and then copying-and-pasting back into the Windows dialog.

Enter the freeware Rapid Environment Editor, a sweet little tool that is infinitely better than the Windows builtin for editing %PATH% and all your other envvars without pain. Long semicolon-seperated environment variables are displayed as drop-down trees (like my PATH below), and it even highlights broken folders with red text!

It’s a quick 800kb download and the best thing to happen to me today.

I recently upgraded the firmware on my home wireless router to Tomato, which has very configurable network quality-of-service settings so that the router knows that some traffic is more time-sensitive than others and that it should take priority when my Internet connection starts to fill up. This is so that I can download a Steam game and browse the web on my laptop while my girlfriend plays Team Fortress 2 on her PC without my causing her game to become laggy and unresponsive.

Surprisingly, when I looked around the ‘net for the appropriate settings to use, I didn’t find very much useful information. The first thing I tried was to simply prioritize all TCP and UDP traffic on every port Source uses (27000-27050), but this meant that Steam game downloads were prioritized at the same level as TF2 game client traffic, which turned out to be bad because it meant that her gameplay bogged down whenever I downloaded an update from Steam (or even if she had a download running in the background on her own computer. )

Fortunately it’s possible to differentiate traffic a little more finely than that: the present generation of Source games all use UDP to communicate with the server, while the Steam client uses TCP for downloads. This page on the Steam support website describes which ports get used for what purpose, and after a little experimentation (and maybe a trip or two into the L4D source code) I finally determined that these settings seem to work best for me:

If you’re having trouble with TF2 or Left4Dead behaving poorly on your network, you might want to try checking your own router’s QoS settings and maybe setting them similarly.

One more thing to remember about home router QoS is that you’re only prioritizing the traffic that you uplink to the internet; it can’t prioritize the traffic that you’ve already received from your ISP (but since downlink speeds are usually so much bigger than uplink speeds this usually isn’t an issue).

Also, for QoS to work properly you need to have an accurate estimate of your total upload speed. This is because all your traffic priorities are expressed as percentages of total bandwidth (eg “Low” priority traffic is guaranteed only 3% of your link while “High” gets, say, 50%), so a low upload speed estimate would cap all your connections too low, and a too-high one would allocate too much bandwidth to low priorities. High end routers such as the D-Link DGL-4300 measure your upload bandwidth automatically, but some firmwares (such as Tomato and DD-WRT) require you to measure your upload speed manually and then enter it into the control panel. You can measure your upload speed at speedtest or Speakeasy (and it’s best to enter a speed that’s 90% of your measured speed, to leave room for packet overhead).

Some routers also support Level 7 filtering, which prioritizes IP connections based on the application-level data inside them rather than simply their source and destination ports. It looks like there are filters for many games, including TF2, but looking at their implementation I suspect simple port-based QoS may work better.

In the realm of “things I really wish I had paid more attention to while we were crunching on Left 4 Dead“, I’ve recently been going through the talks from last June’s Gamefest. There is a lot of really great stuff in there, and I’ve only skimmed through a few of them so far, but among those few the standouts are:

• Xbox 360 Compiler and PgoLite Update: where Bruce Dawson describes the pure awesome that has been poured into the XDK’s CPU performance-analysis tools, such as the Continuous Capture mode for PIX that lets you determine what caused a perf spike after it happens. (Yes, a perf tool can be said to contain pure awesome, for definitions of awesome encompassing branch prediction.) He also presents a lock-free pipe implementation added to the XDK libraries for interthread communication.
• New CPU Features in the XDK: where Dawson continues his reign of awesome in a discussion of improvements to the 360 compiler. He covers faster asserts in array bounds-checking, an improvement to the __fsel intrinsic (the ?: operator isn’t so useless after all), caveats on certain VMX branching operations, and a better way to do SIMD constants. There’s also a bunch of improvements to the 360 compiler itself including better load-hit-store avoidance, better inline assembly, and a more useful /QXSTALLS pipeline simulator (which makes the compiler emit a nerd-readable assembly file for each .CPP with all your performance issues highlighted).
• At Least We Aren’t Doing That: Real Life Performance Pitfalls: Allan Murphy lays out the fifteen most common performance screwups that the Microsoft support team sees. Each of them has been something I’ve gnashed my teeth over in the past ten years myself, and more than one is something game programmers been dealing with since the days of the PS2 (so really we should know better by now).

I’m still working my way through these docs and planning to put together a précis on them for the devs at Valve, so hopefully I’ll be able to post that here along with some of my own thoughts on the topics as well. Half the things in “At Least We Aren’t Doing That” are certainly issues I’ve been known to get into long lunchtime rants over!

Some other interesting documents on my vast and teetering to-read pile are Gustavo Duarte’s articles on PC internals like x86 memory translation, Christer Ericson’s old GDC2003 talk on memory optimization, and Ulrich Drepper’s definitive but dense What Every Programmer Should Know About Memory. The last one in particular I’m reviewing as a background citation to some notes I’m writing myself on console data caches (because I’d rather have something online and free to link to rather than send everyone to the bookstore to for a copy of Computer Organization And Design): it has a lot of good stuff in it, though much of it is specific to Linux running on x86 CPUs and very different from the way game consoles work. In particular, passages such as this one may bring a chuckle to PS3/Cell developers:

A computer can have a small amount of high-speed SRAM in addition to the large amount of DRAM. One possible implementation would be to dedicate a certain area of the address space of the processor as containing the SRAM and the rest the DRAM. The task of the operating system would then be to optimally distribute data to make use of the SRAM…. While this is a possible implementation it is not viable … this approach would require each process to administer in software the allocation of this memory region…. So instead of putting the SRAM under the control of the OS or user, it becomes a resource which is transparently used and administered by the processors.

The transparent, all-knowing processor indeed.