Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Sponsored Feature: Scaling Ambient Animations for Improved Game Experience
View All     RSS
October 20, 2020
arrowPress Releases
October 20, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Sponsored Feature: Scaling Ambient Animations for Improved Game Experience

September 17, 2009 Article Start Previous Page 3 of 3

Figure 6 shows how things look once the update is parallelized.

Since the Adjust step is already parallel, the demo calls updateAnimation directly for each entity after it adjusts the animation. Previously, Adjust happened after the update, effectively moving the adjustments to the next frame.

In the threaded case, Adjust needs to be called prior to updateAnimation, or there will be nothing to update and the call will return early. Because there are so many animated objects, the difference between these two approaches results in the same net effect, so the order of the Adjust and update is of no concern.

When first implemented, this change crashed the demo for two reasons:

  • The demo accessed OGRE and DirectX from multiple threads.
  • OGRE does not support multiple readers of a hardware buffer.

While exploring solutions to these problems, we discovered that OgreConfig.h contains a pre-processor macro called OGRE_THREAD_SUPPORT. If OGRE_THREAD_SUPPORT is defined, OGRE supports multi-threaded access and also initializes DirectX in multi-thread mode (the DX device is created with the D3DCREATE_MULTITHREADEDflag). Defining this macro resolved the first issue.

Resolving the second issue required more insight. In Horsepower, all of the horses are based on the same mesh. The data for the mesh are loaded only once for all of the horses. To animate the horses, each entity has to access this shared mesh data.

Because DirectX supports multiple readers and OGRE does not, OgreHardwareBuffer needed to be modified to support this functionality. The OgreHardwareBuffer changes can be viewed in the source code's OgreHardwareBuffer.h file (in the path code\extern\Ogre1_9\OgreMain\include). Those two changes to OGRE were sufficient to enable threaded animation in the demo.

Horsepower uses a unique performance metric: horse count. On any system, with a locked frame rate of 30 fps, the number of horses displayed will indicate the relative performance of the system at hand. On an Intel Core i7 processor with eight-thread capability, the data shown in Figure 7 was captured.

Possible future work on the Horsepower demo includes:

  • Instanced horses -- Horsepower currently shares the same mesh data, but each object is its own entity with its own animation vertices; performance could be improved with instancing.
  • An optimized level of detail (LOD) system -- LOD was removed because of performance reasons; work can be done for further performance optimization and higher level of detail with LOD optimization.
  • Possibly turning it into a herding game -- The framework already has "fear" programmed into the demo (from its Smoke roots). Have the horses fear the camera and create a pen into which the horses are herded.

The possibilities are endless, and with the source code free for use, anyone can try anything out!

Horsepower's primary goal is to show a fair, perceptible difference in effects through the use of threaded animation. We hope this example will encourage developers to make use of the extra compute power on multi-core CPUs in real PC games.

Article Start Previous Page 3 of 3

Related Jobs

innogames — Hamburg, Germany

Mobile Software Developer (C++) - Video Game: Forge of Empires
Johnson County Community College
Johnson County Community College — Overland Park, Kansas, United States

Assistant Professor, Game Development
Insomniac Games
Insomniac Games — Burbank, California, United States

Lead Gameplay Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States

Lead Engine Programmer

Loading Comments

loader image