Some of the content is directly related to multithreading and even Intel in particular, as numerous articles deal with the ins and outs of multithreading AI-related tasks, and examples frequently make use of Intel's threaded building blocks C++ library.

For example, The Catch for Multi-threading Decision Making contains a video Q&A with Champandard addressing the notion of dedicating processor cores specifically to AI.

"It's harder to throw processing power at the problem than you realize," he offers. "It's easier to throw, let's say, many more animations and more behaviors, but you don't necessarily have a linear growth in computation when you have more assets; you will structure them in such a way that your decision-making is always not linear. If you have N behaviors, you have to make sure your decision-making is not [in] order N, but has some structure to it, so when all these behaviors need to be selected, you're going to do that in a scalable way. ...Processing power is not something you use linearly."

As well as going further in-depth into that topic with visual aids, the post also follows a practical primer called Hierarchical Logic and Multi-threaded Game AI, and links to a feature on Multi-threading a Simple Hierarchical Planner to Estimate Performance (note that that piece requires registration on the site, which is free).

The demo was run on an Intel Core I7 with all four cores, as well as four virtual threads with hyperthreading. "There's lots of ways you can do threading," said Granatir. "It's a difficult problem." He noted:

"The Smoke demo is a technical demo we put together at Intel to showcase threading in a game environment. We wanted a lot of thread interaction between a lot of common game systems, and show you could thread these in an effective manner. ...The demo has two purposes: it shows off this threading, and it shows off how you can harness the power of Intel's modern CPUs."

Speaking on the project, Werth explained:

"In development, we ran [this demo] under two different threading system. We built what we call the native thread pool system using the Windows native APIs, then we built a threading system using the same API for the Intel Threading Building Blocks, which is an open-source library that was originally produced at Intel, but we were so happy with it we opened it up to the open source community."

Because of CPUs constrained with limited computational power, most character animation is done today with a bones-and-skin method, which uses a small number of invisible control points, linked together as bones, to control the a figure. To "skin" the character, the visual portions of the figure are then bound to specific bones.

While this method provides a relatively fast way to animate characters given CPU constraints, the advent of two-core and fore-core processors is allowing for more sophisticated character animation techniques:

"With additional processing power, the bones-and-skin method can be extended for more detailed animation. More bones can be added for additional degrees of freedom. But there is no need to create additional bones unless a new joint is being modeled. Improvements are also possible by focusing on more complicated movement of the bones.

When simulating cloth computationally, the hand becomes an invisible mathematical construct and the sock is attached to that construct at key points. By expanding on this concept, a variety of soft-body characters can be created."

You can now read the full feature, which includes specific technical details and visual aids.

In addition to explaining the purpose and architecture of Smoke, the piece gives a practical example based on a demo application, showing relative performance based on scaling to various numbers of cores.

As the pair explains:

"Smoke is a model framework that maximizes the performance of the processor in a purely gaming environment. Built to take advantage of all available threads, it works equally efficiently on standard dual-core Intel Celeron processors as well as on new Intel Core i7 Processors with Intel Hyper-Threading Technology.

"Intel’s goal through this and other efforts is to help prove that multi-threaded gaming can be done effectively and is an investment in time that is worth taking."

The full article is available to read on Gamasutra; no registration is required.

Noting that "increasingly, YouTube integration is seen as a valuable feature addition to games," Höfele points to Maxis' Spore Creature Creator, which makes extensive use of YouTube integration, features its own YouTube channel, and ties its community into the site.

Since YouTube provides an API that makes this feature possible for just about any game developer, even indie game makers can offer a bonus to their users that otherwise may be prohibitive in terms of the development effort and server capacity that would be required.

Höfele includes not only code examples in his article but also a demo application with included full source code. In the feature, he addresses numerous major steps to adding YouTube integration: recording gameplay, choosing a video format, encoding screenshots, dealing with YouTube's API, and uploading the videos.

As Höfele summarizes:

"Adding YouTube upload to your game is straightforward, but requires some planning.

"Finally, an application can upload videos with YouTube's RESTful interface; a protocol based on HTTP. The demo application for this article comes with an implementation for authentication, search, and video upload requests that you can use for your own game."

As the author describes:

"We have two things that we don't know, the reflection direction and the travelled light ray distance between the track and the bike, and those are possible to compute only using raytracing... Let's try now to fill the holes using some approximations that we can easily compute on a GPU.

"If we can render planar mirrors, we can also compute the distance of each reflected object to the reflection plane. In fact it's really easy! So we do have a measure of the distance, but not the one that we want, the distance our reflected rays travels according to the rough asphalt normals, but the one it travels according to a smooth, marble-like surface. It's still something!"

The author includes a few code examples, based on previous R&D work he did on a shipped racing title, and has even posted a followup blog entry that delves deeper into his blurring algorithm.

The cites notes the growth of integrated graphics, and notes that there are various steps developers can take to squeeze unexpected performance out of such hardware:

"Integrated graphics already dominate over discrete graphics at a ratio of nearly 2:1 in terms of market segment share, and that ratio is expected to grow substantially over the next several years.

"By tuning the scalable aspects of gameplay to the resources available, game companies can effectively expand their target user base, while still providing an optimal visual experience for everyone."

The feature goes on to explain specific benefits of the Intel program, including development assistance and discounts on development hardware.

"The key thing here is that the data is not being shared across threads as much," he explains. "There definitely is data that is being shared with the rendering thread and the graphics driver thread, but between the engine and the renderer, there really isn't a whole lot of data that is being shared. In the case of Quake 4, all the dynamic meshes that are generated per frame had to be buffered and shared between the two threads, which isn't the case with Quake Wars."

In addition to the video, there are full slides available from a talk given by Kalra alongside developer Jan Paul van Waveren of Quake series creator id Software.

Referring to asset processing tools as "the ugly stepsister" of game development, West warns against ignoring their role.

He notes that, because of their simplicity, effort is often not spent to properly optimize them, which can end up eating away time later in the project.

Multithreading is a great way to make these tools more efficient, West notes. "Most PCs now have some kind of multicore and/or hyper-threading," he writes. "If your tools are written in the traditional mindset of a single processing thread, you’re wasting a significant amount of the silicon you paid for, as well as the time of the artists and level designers as they wait for their assets to be converted.

"Since the nature of asset data is generally to be large chunks of homogeneous data, such as lists of vertices and polygons, it’s generally very amenable to data level parallelization with worker threads, where the same code is run on multiple chunks of similar data concurrently, taking advantage of the cache."

Surprisingly, he even admits that "bad code" is permissible when it comes to processing tools, as long as the risks are properly weighed:

"In-house tools don’t always need to be up to the same code standards as the code you use in your commercially released games. Sometime you can get performance benefits by making certain dangerous assumptions about the data you’re processing and the hardware it will be running on.

"Instead of constantly allocating buffers as needed, try allocating a 'reasonable' chunk of memory as a general purpose buffer. If you have debugging code, make sure you can switch it off. Logging or other instrumenting functions can end up taking more time than the code they are logging. If earlier stages in the pipeline are robust enough, then (very carefully) consider removing error and bounds checking from later stages if you can see they are a significant factor.

"If you have a bunch of separate programs, consider bunching them together into one uber-tool to cut the load times. All these are bad practices, but for their limited lifetime, the risks may be outweighed by the rewards."

You can now read the full Gamasutra feature on the subject, posted as an independently authored piece within the Intel Visual Computing section, and which includes sample code (no registration required; please feel free to link to this feature from external websites).

There are two main approaches, Fosner points out. "One is the traditional way of threading for speed; you parallize things to make them faster on the GPU. You want to break your game tasks up into chunks. The other way is programming and threading for features. You take advantage of all the extra CPU power that's beyond the minimal gameplay, and take it to the point where it's increasing the user experience. What you can do is continue to add content or work while you have CPU power available. You can increase the user experience as the CPU power increases, design your game engine to be multicore aware."

In part two of the session, Fosner delves more into practical techniques:

"Games are really very challenging to thread," he admits. "If you can manage to thread your game engine successfully, you can thread anything."

After quickly recapping that original principle, Porcino moves onto evolutions of that algorithm: convex contouring ("Where marching cubes generates triangles based on face intersections, convex contouring generates polygonal shapes that enclose the convex negative space within each cell"), dual contouring ("Since vertices are placed in the interior of the cubes and not on the edges of the cubes, there is more freedom as to where the vertex can be placed"), and dual marching cubes.

Dual marching cubes was introduced in 2004. As Porcino describes:

"This method aligns vertices in the tessellation with features of the implicit function. The tessellation itself occurs on a grid that is the dual of the structured sampling grid. The result is that thin features missed, or requiring a lot of subdivision are preserved with a much sparser polygonization than that resulting from a structured grid. The method proceeds by creating an octree describing the volume to be contoured, then a dual grid of the octree is created by linking vertices at the centers of each grid cell to its topological neighbours.

"The surface is then extracted using a simple extension of marching cubes to dual grids. Since each cell in the grid is topologically equivalent to a cube, the standard marching cubes tables can be used to generate the surface interior to the cell. Since the underlying representation of the data is an octree, the resulting tessellation is much sparser than Dual Contouring or Marching Cubes."

Porcino includes visual aids that demonstrate how the dual marching cubes algorithm manages to represent geometry better than the other sampling methods, even with a lower polygon count.

Despite the cube-centric tack of the post, Porcino notes that progress is being made using tetrahedral meshes, and points to the website for Jonathan Shewchuk's UC Berkeley computer science course as a useful resource to that end.

One of Rost's focuses is lowering the barrier of entry to development with graphics hardware, a goal achieved in part by working directly with universities to get feedback and provide training. In this excerpt he discusses the importance of that angle:

"Randi Rost: Universities are where a lot of new technology gets dreamed up, where new algorithms get invented. Universities, particularly in the visual computing space, have been relatively shackled by the existing graphics hardware capabilities-where the entire rendering pipeline has been built into fixed-functionality silicon.

"This provides scant flexibility for researchers to innovate in term of rendering algorithms. Recently, within the last half-dozen years, the hardware pipeline has gotten to be more programmable, but there are still a lot of constraints.

"With our upcoming graphics architecture, built around a completely general-purpose CPU-based design, we're basically removing all the constraints for the rendering pipeline. We're telling researchers: 'Hey, here's an architecture where you can effectively do everything you want in software. There's no fixed functionality to get in your way. If you want to experiment with new rendering algorithms, with ray tracing, with hybrid rendering systems, if you want to replace the rasterization unit, if you want to have procedural geometry so that you can render spheres analytically (rather than breaking them down into polygons)-all of those things are possible.'

"It's a completely open, general, high-performance platform for highly parallel floating-point workloads, such as graphics. And, the basic programming model is simple: C++ code that targets x86 cores."

Rost goes on to discuss the opportunities this presents in hiring talent, and the importance of preparing the next generation of developers for the increasingly complex world of graphics hardware. You can read the full interview (no registration required; please feel free to link to this feature from other websites).

Top honors for best overall threaded game went to Tommy Refenes of PillowFort for his Goo! demo, which also placed in the graphics category. You can see some of the evolution of Refenes' multithreading techniques in his recent feature article.

Other top honorees include Добряк's Magic Worlds, Tandem Games' Pixel & Vega in: Crunch Time, and Яков Сумыгин's Deadly Light. The winners were narrowed down from 329 entries. All demos that placed up to fifth in their categories are available for download from Intel's site.

Open-world game environments and objects are typically spooled from the disc as players move through an area, with scene complexity often determined by the data transfer rate of spooling and the virtual speed of the player within the world.

If a world has too much complexity, then new glitches may result when data cannot be spooled fast enough as players move from one region to another. To prevent these problems, developers can restrict players' maximum speed so there is sufficient time for the world to load, and they can place limits on scene complexity and allowable variation between regions.

To allow for more complex environments, West suggest that developers take advantage of procedural content -- content generated from mathematical descriptions of underlying forms and parameters describing the specific instance of that content -- and procedural compression:

"Procedural compression is simply storing a piece of geometry as a set of procedural parameters rather than as the final model. While this is not compression in the normal sense of the word, the effects are essentially the same, only with a vastly increased (even arbitrarily large) compression ratio.

"We also trade some CPU resources, since the generation of geometry may require more CPU time than the standard spooling and decompressing of the raw data."

You can read the full technical article, which includes more information on procedural compression and solutions to the resource problems that come with the technique (no registration required, please feel free to link to this feature from other websites).

"Through image segmentation techniques," Valve's code "’simply’ tries to determine if the previous frame has been under or over exposed and a new exposure value is adjusted to compensate for problems with the previous frame(s)." Salvi notes that this method doesn't allow for reliably determining average logarithmic luminance, which in his experience has led to "an overall flat and over or under saturated feeling." So he introduces his own plan: "get rid of the exposure search through previous frames feedback and compute it the proper way!"

Salvi's method computes per-pixel logarithmic luminance and outputs that to the alpha channel; he includes a code example of the relevant math, and delves into further specific details.

As a bonus, Valve's Gary McTaggart and Chris Green, both presenters of the lectures that spurred Salvi's post, drop by in the blog's comment section to explain their reasoning behind the route they took for the Source engine's HDR implementation.