There are other chewy bits, such as: “The USC experience is that 100% of its students interviewed for programming positions are given three-to-four-hour-long programming tests, with almost all companies administering the tests in C++.”

Also, this: “The game industry will also tell you that it wants the first four programming classes in C++, not Java, according to M.M. McGill and my own private communications with directors of human resources in major game-development companies.”

One final morsel: “Many game companies say they will not interview or hire someone whose first programming language is Java.”

Wow, that last one’s harsh, especially since my experience with two teenage sons (one in high school, the other a freshman computer science major) is that Java is the norm for the first “real” language taught (I don’t count Scheme as a real, “you’ll get paid programming in it” type of language). I don’t think I’d rule someone out for knowing Java first, though having gone from C++ to Java and then back, the transition from Java to C++ is like being thrown out of the promised land: you suddenly again spend half your time messing with memory in one form or another. C# and Java are darn productive in that way. And, no, for me at least, those auto-pointer classes in C++ never quite seem to work—they need a different sort of discipline I don’t appear to have. I also love that my first Java program, from 1997, still works on the web; some of my C++ programs from back then won’t run on Vista or Windows 7 because the WinG DLLs are not a part of those operating systems (thanks, Microsoft).

Nonetheless, the article’s right: at Autodesk we’ve dabbled with Java and C#, I’ve seen Python used for UI control around the fringes of a program, but the heart of client-side graphical programs is almost always C++ (or isn’t, with regrets and cancellation often soon following—been there myself, though Java was only a little bit to blame, to be fair). Also, XNA, which uses C#, does not have a 64 bit version. In addition, Microsoft’s managed code support usually lags behind the “real” DirectX, i.e., the one for C++.

Looking around, I did find an open-source project, SlimDX, that does support 64-bit assemblies for interfacing with DirectX. Interestingly, they claim one AAA game title shipped using SlimDX, but no mention of which. So I asked. They’re keeping the information confidential, which is fine, but the other comment sounds about right: “The large majority of professional commercial PC/console games are still developed in C++ because of the sheer amount of legacy code the studios developing those games have that is already in C++ (and because of the generally poor support from major console vendors for languages other than C or C++, which contributes to lock-in).”

Long and short: it’s C++, baby.

I’ll list these roughly from the more basic to those for budding programmers and indies. That said, I think some languages, e.g. Processing, are easier to get into than the UI-driven systems, but some understanding of programming is needed. I’ve also ignored some famous examples like Logo, as it feels a bit crusty and limited to me. But, that’s me—let me know if you have a great counterexample.

Game Maker: My experience with this one is trying it with my younger son, and later Cornell using it in a 20 hour digital game design workshop for high-school students. It’s much more about games than graphics, graphical elements are 2D sprites and backdrops. Most of the focus is on events and constraints, as you might guess. Very UI oriented, no programming language involved per se – the UI controls are essentially a programming language of a sort. I have The Game Maker’s Apprentice, which is good in that it gets the person involved quickly, but bad in that little understanding gets transmitted early on (“now set this UI control to do this, now load that file there, now hit ‘run’; if it doesn’t run, walk through all the instructions carefully again”). From Amazon reviews, the book Getting Started in Game Maker might be better. There’s lots of example games and web support. Cost: free Lite version and trial Pro version, cost for Pro version (which you want) is $20.

Multimedia Fusion 2: this is an expanded and rebranded version of the company’s “Games Factory 2” product that includes all its functionality. It looks similar to Game Maker, but targeted for a somewhat more professional audience (and at a higher cost) overall. That said, there is a book for it, Game Creation for Teens. Cost: free trial download from 2008, lowest street price I saw for Multimedia Fusion 2 was $83.

Flash: Adobe’s popular animation & game programming system, famously unsupported by the iPad. Back some years ago the local science center used Macromedia Flash to teach grade-school kids about basic Flash animation. Now Adobe Flash Professional CS4 is used to create Flash. From what little I’ve read, the interface is daunting, but it’s actually pretty easy for beginners to get going. Animation is something that can be done purely with graphical tools, Actionscript 3 is a language for serious interactive applications. There’s of course a huge number of books, forums, and other online support. Cost: as low as $200.

Flixel: I’ve heard this mentioned twice as a worthwhile development resource for Flash. It provides some useful base classes in Actionscript 3 for making games, along with tutorials, a forum, etc. Cost: free.

Pygame: This is the first of a few language-oriented resources. Pygame is a bunch of modules to help in writing games in Python. One friend said he got a simple game running in less than two hours from download (but that’s him…), another acquaintance wasn’t so wild about it as he hit its limitations. 2D oriented, though there’s a few 3D experiments. This sounds like a pretty good, and super-cheap (free!), way to introduce kids to programming. I recall an article in CACM or IEEE Computer a year or so ago about Python, and it made an excellent point: Python is one of those great languages that is made for people who have never programmed before. Like Perl, it provides the ability to program and get something done quick without a lot of clutter, and so is a better candidate for the first programming language taught, not Java. Let the programmer have fun getting things done, then teach them about more elaborate computer science concepts and why these are useful. Python is pretty easy to learn: Andrew Glassner has a great introductory page – in a few hours you’ll know the basics. But I digress… Anyway, Pygame has lots of users, many of the projects are open source, there’s even a second edition of a free professionally-produced book about Pygame. Cost: free.

Processing: OK, if you’re sick of hearing about game programming resources, here you go. This is a little language suited for making cool 2D images. Key basic graphics concepts—transforms, curves, image manipulation—are encapsulated. Basic interaction is also a snap. It has a 3D component, but that part is fairly weak. I’ve played with it, it’s fun. Not meant for games; nonetheless, it’s possible. Much online support, and there are two popular books, here and here (the second has lots of additional material online). Cost: free.

Blitz Basic: I’ve heard of this one from a few people but have no direct experience. Definitely about programming, it uses BASIC, but enhanced with functions and types. It looks pretty full-featured, e.g. there’s joystick and networking support. BlitzPlus is the Windows 2D version, BlitzMax also runs on Macs and Linux, Blitz3D adds 3D support: camera, lighting, texturing (including bumps), CLOD terrain, etc. There’s an SDK for interfacing the 3D engine with C++, C#, etc.  Manuals are online, and there looks to be a healthy user community. There’s a German version of the website. Cost: free trials of all, prices range from $60 to $100 per product, with more for add-ons.

XNA: This is something of the 800-pound gorilla for programming-related graphics education. As an example, some teen programmers in the Cornell workshop were using XNA as the next step beyond Game Maker. A Microsoft initiative, it’s partially aimed at students and hobbyists. The base language is C# (Java on steroids, if you haven’t used it). There are lots of element and audiences for XNA, Wikipedia also covers the area well. There are many XNA resource sites and books out there (though I was sad to see Ziggyware is no more). Cost: free for the most part, depending on what you’re doing.

Ogre: Begun about a decade ago, this is from all reports a pretty nice graphics engine. It supports a huge number of effects and areas (I know developers who have consulted the codebase for ideas). There are lots of add-on libraries. It’s great for deep-down serious graphics education; Ogre is entirely open source (MIT license), so everything can be examined. Cost: free, and free licensing.

Unity: You’ve now definitely entered the Indie game developer zone. A 3D games development system I’ve heard mentioned by others as a way of learning. Multiplatform, now including the iPhone. Cost: free base version and trial of Pro version, which costs $1499; other pricing for iPhone version. There’s a book. Licensing for Indies has become free.

UDK: The Unreal Development Kit is the most popular game engine used for game development. Cost: free to download full version, 530 Mb of fun. Licensing cost: if you have to ask, you can’t afford it.

Torque: Torque is the second most popular development platform for game creators. For Torque, two versions exist, 2D and 3D. Three books are available on this engine. Cost: $250 for 2D, $1000 for 3D version, but educational pricing can be arranged.

Whew! OK, what did I forget? (Make sure to read the comments—some excellent additions there.)

Update 2/6/2010: Kodu, from Microsoft. For grade schoolers, it uses a visual language. Surprisingly, it’s in 3D, with a funky chiclet terrain system. Another interesting graphics programming tool is NodeBox 2, now in beta. It uses a node graph-based approached, see some examples here.

First, two new graphics books have come to my attention: Essentials of Interactive Computer Graphics and Computer Facial Animation, Second Edition. The first is an introductory textbook for teaching, well, just that. Real-Time Rendering was never meant as an introduction to the field of interactive graphics, we’ve always seen it as the book to hit after you know the basics. The Essentials book is squarely focused on these basics, and is more event-oriented and application-driven: GUIs and MFC, instancing and scene graphs, the transformation pipeline. It’s truly aimed at computer graphics in general, not 3D lit scenes. Shading is barely mentioned, for example. The book comes with a CD of software libraries developed in the latter half of the book. See the book’s website for much more information and supplemental materials (e.g. Powerpoint slidesets for teaching from the book!).

Computer Facial Animation is an area I know little about. Which makes this book intriguing to page through -how much there is to know! The first few chapters are dedicated to anatomy and early ways of recording facial expressions. The rest covers all sorts of areas: speech synchronization, hair modeling, face tracking, muscle simulation, skin textures, even photographic lighting techniques. This is one I’ll leave on my desk and hope to pick up at lunch now and again (along with those other books on my desk that beg to be read, like Color Imaging - I need more lunches).

Which reminds me of this nice talk by Kevin Bjorke: Beautiful Women of the Future. The first half is more aesthetic with some interesting fact nuggets, the last half is a worthwhile overview of interactive skin and hair rendering techniques.

It’s worth noting that there are many computer graphics books excerpted on Google Books. Our portal page, item #6, lists a few good ones.

Game Developer Magazine’s Front-Line Award Winners have been announced. Our book was nominated, but to be honest I’m not terribly upset it didn’t win (our second edition won it before); instead, a new book on (video)game design got the honors in the book category, The Art of Game Design. The rest of the award winners are (almost) no doubt deserving, but the winner list provides little new information. It’s the usual suspects: Photoshop CS3, Havok, Torque, Visual Studio 2008 (really? I’d go with Visual Assist X, which adds a bunch of useful bits to VS 2008 to make it more usable). I haven’t seen the Game Developer article itself, which should be more interesting to see the list of runner-ups.

Update: it’s a day later, and the Front Line awards article is available online. Good deal!

I just noticed that Jeremy Birn has been having lighting contests for synthetic scenes. Meant more for the mental ray users of the world, I like it just because there are some nice models to load up in my test applications.

We mentioned SIGGRAPH Asia before; see the papers collection here and some GPU-specific presentations here.

A fair bit going on in the blogosphere:

• Christer Ericson has an article on optimizing particle system display. I hadn’t considered some of these techniques before.
• Bill Mill has a worthwhile rant on publishing code along with research results. This often isn’t done, because there’s little benefit to the author. Some researchers will do it anyway, for various reasons (altruism, fame, etc.), but I wish the research system was structured to require such code. It’s certainly encouraged for the journal of graphics tools, for example, but even then the frequency is not that high.
• Wolfgang Engel has lots of posts about programming for the iPhone & Touch; I was more interested in his comments about caching shadow maps.

Everyone should know about the Steam Hardware Survey. The cool thing is that they recently started adding a history for some stats and, dare I dream it?, pie charts to the site. Much easier to grok at a glance.

Tutorials galore:

• SphereGames has some basic tutorials on LUA, texture management, skydomes and heightmap rendering.
• Ziggyware has XNA tutorials on point sprites, clipmaps, HDR, Photoshop blend modes in HLSL, and multithreading, to name a few.
• Gamedev.net has tutorials on dynamic scene graphs and on XNA vertex element systems.
• Microsoft describes Shader Model 5.0. I’ve heard rumblings that the extra baggage for materials vs. lights may not be all that relevant for game developers. As a CAD developer, I look forward to it (in a decade or so, when all our applications users have moved to SM 5.0).

Need a huge (or medium, or small), free texture of the whole earth? Go here.

Google’s knol project collects short articles on various topics. Here’s a reasonable sample: a short history of theories of vision. To be honest, though, the site overall seems a bit of a dumping ground. This sort of lameness is proof why editorial supervision (either a single person or a wiki community) is a good thing.

DirectX 10 corrects a long-standing “feature” of previous versions of DirectX: the half-pixel offset. OpenGL’s always had it right (and there really is a right answer, as far as I’m concerned). I was happy to find this full explanation of the DirectX 9 problem on Microsoft’s website.

Our book had a little review in the February 2009 issue of PC-Gamer, by Logan Decker, executive editor, on page 80. I liked the first sentence: “I don’t know why I didn’t immediately set fire to this reference for graphics professionals the moment I saw all the equations. But I actually read it, and if you skip the math bits as I did, you’ll get brilliantly lucid explanations of concepts like vertex morphing and variance shadow mapping—as well as a new respect for the incredible craftsmanship that goes into today’s PC games.”

This one’s made the rounds, but just in case: the Mona Lisa with 50 semi-transparent polygons, evolved (sort-of). Here’s a little eye candy (two links). Plus, panoramas galore.

Finally, guard your dreams.

Direct3D is, of course, the API used by most Windows games, but its importance extends beyond Windows. Direct3D features guide the development of graphics hardware in general, so these features are bound to show up in future consoles, as well as in OpenGL.

The announcement that Direct3D 11 would not be tied to the next version of Windows (as many had feared), and would be available on Windows Vista was very significant to Windows developers, many of whom complained about the tying of Direct3D 10 to Windows Vista. Direct3D 11 will also be available on Direct3D 9, 10, and 10.1 level graphics hardware (although the new features will not be available there, with the exception of some multithreading enhancements).

The fact that the Direct3D 11 API is a strict superset of the 10/10.1 API is also cause for relief among game developers. From Direct3D 9 to 10, the API went through extensive changes. These changes were mostly long-overdue cleanups and improvements, but they left developers supporting two very different APIs if they wanted to support the many customers using Windows XP and also expose the new Direct3D 10 hardware features.

This is the first part of a multi-part post which will summarize the essential facts about Direct3D 11, as known from the Gamefest slides. Eventually, the slides should show up on the XNA Presentations page.

Full disclosure of Direct3D 11 should occur later this year – the November 2008 DirectX SDK release will feature a preview version of the API, including full documentation and code samples.

This week, at Gamefest, Microsoft announced that these “homebrew” games could now be sold to Xbox 360 owners in general. Interestingly, the games will not be selected by Microsoft themselves (although I am sure they will do some gatekeeping) but by the community (similarly to the selection of posts at Digg or Slashdot).

If you are a game or graphics hobbyist who is intrigued by the idea of creating games to sell to almost 12 million Xbox 360 owners, then check out Microsoft’s XNA Creators Club website.