Intel Software Network articles Feed http://software.intel.com/en-us/articles/game-development/type/tutorials/ en-us Adaptive Transparency
aoit_left_small.jpg aoit_right_small.jpg

Transparency is a fundamental open problem in real-time rendering due to the difficulty of compositing in the right order an arbitrary number of transparent layers. The current situation in real-time applications is exemplified by the left image, where numerous objects are incorrectly composited when rendered with alpha-blending, the most popular algorithm for rendering transparent geometry. On the other hand, as shown by the right image, our algorithm can correctly composite all transparent layers while maintaining performance levels typical of real-time applications.



]]> http://software.intel.com/en-us/articles/adaptive-transparency/ Sat, 05 Feb 2011 00:00:00 -0800 http://software.intel.com/en-us/articles/adaptive-transparency/#comments http://software.intel.com/en-us/articles/adaptive-transparency/ Visual Computing Code & Downloads Game Development Sandy Bridge Samples Suite

Sandy Bridge Code Samples and Articles

Find content to speed up your game development on 2nd Gen Intel® Core Processor family (codenamed Sandy Bridge).
SNB_DevGuide_xsmall.jpg Intel® Integrated Graphics Performance Developer's Guide for Intel® HD Graphics on the Sandy Bridge microarchitecture is a document that provides development hints and tips to ensure that your customers will have a great experience playing your games and running other interactive 3D graphics applications on Intel Processor Graphics. This document details software development practices using the latest generation of Intel processor graphics, Intel® HD Graphics, as well as two previous generations of the Intel® Graphics Media Accelerator with a focus on performance analysis using Microsoft DirectX*.
ShadowExplorer_xsmall.jpg Shadow Explorer Shadow Explorer is a sample application, with source code, that allows developers to work with several shadowing techniques, examine the performance versus quality tradeoffs of each one, and discover which is best suited for their game. In this first version of Shadow Explorer, we include four algorithms for evaluation: simple shadow maps, percentage closer shadow maps, variance shadow maps and exponential variance shadow maps.
cloth_xsmall.jpg AVX Cloth is a tech sample that demonstrates use of 8 wide floating point SIMD processing with 256 bit AVX. The sample has many active cloth pieces simulating as it showcases a SOA implementation of an iterative position projection (distance constraint based) solver.
OnloadedShadows_xsmall.jpg Onloaded Shadows is a technique by which shadow maps can be calculated asynchronously on the CPU. By using cascades, the shadow map for objects near the camera are calculated every frame on the GPU, but the shadow maps for objects in the second cascade and beyond are calculated less often on the CPU. This allows for better work balancing across the CPU and GPU.
GPUDetect_xsmall.jpg GPU Detect is a short sample demonstrates a way to detect the primary graphics hardware present in a system, and to initialize a game’s default fidelity presets based on the found graphics device using a simple API. The code and accompanying data is meant to be used as a guideline, and should be adapted to the game’s specific needs.
SampleTweaker_xsmall.jpgSample Tweaker is a paper that shows how we successfully optimized an existing graphics demo, named Ocean Fog, for our latest processors with Intel® Integrated Graphics. We achieved a 4x boost in performance (40 FPS to 160 FPS) with very little to no fidelity loss by applying techniques such as reducing texture sizes and lowering precision. These optimization techniques are not revolutionary by any means, but knowing when to apply them can be a bit more involved. To help us identify where we might be able to optimize, we used Intel’s graphics profiler, called Intel® Graphics Performance Analyzers or Intel® GPA for short.



Related Content:

 
]]> http://software.intel.com/en-us/articles/sandy-bridge-samples/ Wed, 08 Dec 2010 00:00:00 -0800 http://software.intel.com/en-us/articles/sandy-bridge-samples/#comments http://software.intel.com/en-us/articles/sandy-bridge-samples/ Visual Computing Code & Downloads Game Development Fireflies - Scalable Ambient Effects

Scalable Ambient Effects (Fireflies)

Fireflies is a tech sample demonstrating a scalable ambient effect. In this sample, the ambient effect is a swarm of fireflies that scatter and reform into a walking character. Using Intel TBB, the firefly flight trajectory calculations performed per frame are distributed across multiple threads. By changing the number of simulated fireflies programmatically the ambient effect can be scaled to better match the performance of the platform it is running on.
Fireflies_screenshot1_web.jpg
Fireflies_screenshot2_web.jpg
Fireflies_screenshot3_web.jpg

Fireflies flock to form a walking character

Fireflies scatter and flock

The sample can run in multithreaded as well as serial mode to better see the performance benefit of multithreading an ambient effect.


What is it? System Requirements Additional Code Samples
  1. CPU: Dual core or better (Intel® Core™ i5 or better suggested)
  2. GFX: DX9c capable graphics card
  3. OS: Microsoft Windows Vista* or Microsoft Windows 7*
  4. MEM: 2 GB of RAM or better
  5. Software:
    1. DirectX SDK (June 2010 release or later)
    2. Build with Microsoft Visual Studio 2008* w/SP1 or Visual Studio 2010*

* Other names and brands may be claimed as the property of others.


Intel Visual Adrenaline
Developer Community
Intel® Software Partner Program
Game On
Showcase


]]> http://software.intel.com/en-us/articles/fireflies/ Fri, 05 Nov 2010 00:00:00 -0700 http://software.intel.com/en-us/articles/fireflies/#comments http://software.intel.com/en-us/articles/fireflies/ Parallel Programming Tools Visual Computing Intel® Graphics Performance Analyzers (Intel® GPA) Code & Downloads Game Development Extending STL for Games by Neil Gower
neilg@vertexblast.com

Download Article

Download Extending STL for Games [PDF 405KB]

Introduction

Despite widespread usage of the Standard Template Library (STL) in the C++ development community, some game programmers still shy away from it. The STL's use of templates and generic programming style can be off-putting to developers used to working with low-level code and within the limits of previous generations of hardware. The state of current compilers and STL implementations has advanced considerably, as have the capabilities of modern game platforms. Nonetheless, to fully experience the benefits of the STL, it is necessary to know not only how to use it, but also how to customize and extend it to meet the particular needs of game development projects.

To help you become familiar with the STL, we will take a look under the hood of several core STL components by extending them to solve game-specific problems. This article assumes you are familiar with C++ and have at least a basic knowledge of STL. [Josuttis99] is an excellent introduction and reference for readers who want brush up on the STL before diving into customization.


Background

STL Overview

We'll be focusing on four of the core components of the STL: function objects, containers, iterators, and algorithms.


Figure 1. A layered view of the STL.

These components build on each other in layers. Containers aggregate objects, and are typically selected for their ability to manage storage (e.g. vector's contiguous memory guarantee) or to index data (e.g. map's efficient random access). Alongside containers are function objects, and layered on top are iterators. Function objects (also called functors) are classes used to represent individual functions. They are the object-oriented equivalent to function pointers. Similarly, iterators can be thought of as object-oriented pointers, providing a generic means of accessing the contents of containers. An object-oriented design book like [Gamma94] can provide more details about iterators in general.

Iterators and functors are combined to build generic algorithms, which are template functions that implement common programming patterns, such as "apply this function to each element in this range". Briefly, generic algorithms operate on a collection of objects using iterators, and are usually customized using one or more functors.


The Generic Approach
In the process of learning C++, generic techniques usually follow after object-oriented techniques, which can give the impression that the generic programming is just advanced object-oriented programming. Generic programming is actually quite a different paradigm from the standard object-oriented approach. The generic approach involves separating data from the processes that operate on it, rather than bundling them together as classes do. The advantage of this separation is it allows us to reuse processes that are independent of the structure of the data.

The tradeoff for this reusability is that some algorithms can be implemented more efficiently by exploiting specific knowledge of the data. For this very reason, you will find some STL containers have member functions that duplicate generic algorithms, such as remove_if()in std::list. When you need efficiency more than flexibility, the member function versions of these algorithms are the best choice. In practice, a good strategy is to start out using the generic options, and then replace generic components with more specialized ones as the program solidifies and the real bottlenecks are revealed.

Generic and object-oriented programming styles are not mutually exclusive. A hybrid approach will often yield the best results, applying each style where it provides the most benefit. For example, template classes and algorithms are often more efficient alternatives to inheritance, because the static polymorphism of templates is resolved at compile-time, rather than at runtime. On the other hand, implementing matrix operations in a class with tightly coupled math functions will typically deliver better performance than the generic equivalent.

For more information about the generic components that come standard in the STL, [Josuttis99] is a great reference. With a high-level understanding of generic programming, we can now take a look at how to implement our own generic components.


Custom STL Containers

Creating our own containers that are STL compatible allows us to combine higher level STL components like algorithms and iterator adaptors with our custom components. Due to the nature of template classes, implementing STL specifications can be done gradually. Unlike classes that partially implement an interface (which won't compile), partially compatible containers can still be useful, because the compiler will only compile functions that the code actually uses. For the same reason, it's a good idea to have some unit testing in place to ensure that every function gets compiled and exercised while developing template code.

To illustrate how STL containers can be applied to game programming, we're going to take a common game data-structure, the octree, and build it STL-style. An octree is a spatial database. It allows you to do spatial queries like "find the objects which are close to this point" without testing against every object in the game world (see [Ginsburg00] for more about octrees).


Figure 2. An octree partitions space for efficient searching.


Contained Elements
One of the most important properties of STL containers is that they are designed around value semantics. This means that they store the values of the things you put in them, as opposed to, for example, a pointer or reference to the original element. This is less significant for primitive types, including pointers, which we're used to passing around by value. Pass-by-value has the nice effect of making resource ownership unambiguous: whatever is inside the container belongs to the container. The downside to this approach is that it can result in a lot of object copies and assignments. A good habit to develop when working with STL containers is judicious use of references to avoid unnecessary copying.

Containers have a small set of requirements they impose on any class that they contain. First, to support value semantics, objects in a container must be efficiently copyable and assignable. [Meyers97] has many useful tips about implementing these operations correctly in C++. Container elements must also be destroyable, so private destructors are not allowed.

A few additional properties might be required, depending on the type of container in question. For searching and some other operations, the element class needs to have an equality test operator. Sorted containers need a function for determining the order of the elements. By default, operator< (less than) for this. Some container functions also require the elements to have a default constructor, like the vector(n) form of the std::vector constructor, which initializes a vector with n default constructed elements.


Container Specifications
Now that we know how the elements in our container work, we can design the container itself. We'll start by deciding on the container specifications it will implement. Whether we are using the standard containers or implementing our own, container specifications are an important concept for writing good STL code.

Container specifications are more flexible than an interface class in a header file. They specify the syntax and semantics of the interface, but for the most part leave concrete types up to the implementer. The 2003 C++ Standard [ISO14882] includes requirements for abstract containers: container, sequence, and associative container. The standard also defines concrete containers, such as vector and map. By writing to the more abstract specifications when possible, we can produce more flexible code.

Our octree will start by implementing the basic container requirements. This essentially means providing some typedefs, begin and end iterators, and size accessors. Of course, we need more functionality than this for an octree. An octree takes arbitrary 3D locations and maps each one to a set of objects at or near that location, which is similar to taking a key and hashing it to a storage bucket. In this sense, an octree is more like a hash table than it is like an STL sequence or associative container, because the elements are part of an unordered collection. Although the C++ Standard does not include a hash table container, the standards committee has since written up an extension that does include hash tables, in Technical Report 1 [ISO19768]. We'll use the TR1 "Unordered Associative Container" requirements as the basis for our spatial database interface to the octree.


Template Parameters
Declaring the template parameters is a good place to start implementing our new container. Since we are building an associative container, we will need template parameters for the type of object to store (T) and for the key type (Key). Although we can assume that keys in an octree will always be 3D locations, different clients may use different classes for representing those locations. 
template < typename T,
           typename Key,
           int MaxObjectsPerNode = 8,    
           typename LocationFunctor 
               = DefaultLocationFunctor<T, Key>, 
           typename ContainmentFunctor 
               = ObjectContainedIn<T, Key, LocationFunctor>
           typename Allocator = std::allocator<T> >
class Octree { ... };
The class representing location vectors can be anything with x,y,z member variables that provides a constructor that takes x,y,z parameters. An inheritance-based solution to support different location classes would involve defining an interface class with virtual functions to access the coordinates. Our template version is more efficient and does not require the client class to be modified to inherit from the interface class.

Another notable aspect of the template declaration is the scalar parameter MaxObjectsPerNode. Making this a client-specified compile time constant is helpful for optimizing the octree's internal storage design.

The next two template parameters are functors for customizing the octree implementation. A LocationFunctor is used to get a Key from a container element. The default implementation assumes the object has a location member. If we were storing pointers to objects or objects that exposed the location through an accessor function, the client would simply provide an appropriate functor for that type of object.

The octree also uses a functor for the test of whether an object is contained within a given bounding box. The default functor uses the bounding box classes' own simple point test, but this can be easily replaced with more complicated tests based on the game's collision system.

Finally, we have a template parameter for a custom allocator. This is particularly useful in containers used for games, since careful memory management can often make or break game performance. See [Isensee02] for a selection of custom C++ allocators and a guide to making your own.


Octree Specification
Most of the TR1 hash table requirements map nicely onto the octree interface, although a few deviations turn out to be necessary. The primary functions for accessing the octree are: 
iterator insert( const T& t );
iterator erase( iterator pos );
iterator find( key_type k );

iterator begin();
iterator end();
local_iterator begin( const key_type& k );
local_iterator end( const key_type& k );
Our deviations from the hash table requirements are all related to bucket management. The user of a hash table is expected to be fairly involved in the process of balancing the distribution of elements across the buckets. In contrast, an octree automatically subdivides its nodes as more elements are inserted. Although most of the bucket-related interface is omitted, we use the local_iterator concept from the hash table to expose octant contents to clients. This is done by adapting the overloaded local_iterator begin()/end() functions to take a key_type parameter instead of a bucket index.


Storage
Next, we need to decide on how to store the octree's contents. Like most tree-based data structures, an octree is naturally represented by a hierarchy of nodes. Each octree node contains:
  • a bounding box representing the volume the node covers
  • a collection of child nodes
  • a collection of the elements located within the bounding box
The bounding box is a simple struct storing the center and extents of the box. The more interesting design decisions come about from representing the collections. The child nodes can be stored in-place since they are uniquely owned by their parent node. The contained elements themselves we'll have to store indirectly, because an element may be contained in more than one leaf-node's bounding box: for example when using a containment functor that supports objects with non-zero volumes.

Recall that the octree is also responsible for storing and providing access to the elements' values. Using a vector has some nice properties like guaranteed contiguous storage, and gives us random access iterators over the full set of elements in the container. Based on the decision to use a vector, container indices are the best option for referencing the elements of the vector from the octree nodes. Pointers and iterators are unsuitable because both are invalidated by internal vector reallocations, such as when the vector expands to hold more elements.

To recap, the child nodes are stored in-place, and elements are referenced by index. The easiest container to use for both of these collections is std::vector, because it is compact and can efficiently append new elements.


Octree Implementation
As you look through the full container specifications in the C++ Standard, you will notice a lot of similar functions need to be implemented. For example, there are five variants of the erase() function in the octree. Fortunately, most of these functions are just different ways of accessing the same underlying functionality. The core octree implementation is really three private functions: _octreeInsert(), _octreeFindLeaf(), and _octreeRemove(). These functions are reused throughout the public interface to deliver the majority of the required STL functionality.


Custom Iterators

Vector is a good default container for many uses, because it is essentially a C array wrapped in an STL interface, bundled with some size management code. This means that unlike most other STL containers, a vector doesn't incur any per-object storage overhead. The downside to using vector in the octree nodes is that there is some storage overhead for each vector itself. For example, compiled with Xcode* on an Intel® processor-based Mac*, the size of an empty vector was 12 bytes; on Windows* using Microsoft Visual C++* 9.0, it was 24 bytes. For large octrees, this per node storage overhead can become a significant concern.

The FixedArray container in the sample code on the CD-ROM is one solution to this problem. This class takes advantage of the fact that we know the maximum number of child nodes and maximum number of elements that can be stored in an octree node, and that one of these containers will always be empty in each node. FixedArray minimizes the size of the container when it is empty to that of a single pointer. To eliminate any extra bookkeeping data in the container, unused elements are marked with a sentinel value whose value can be specified using a template parameter to avoid collisions. This means a little more work to skip over the unused elements while iterating through the container, but the cost is marginal when dealing with small containers, and zero when the container is full.

To make this solution work, we need some code for skipping over sentinel values in the container. However, this is an implementation detail that should not concern the user of the container. This is a perfect problem for iterators.

This iterator is tightly coupled to the container, so it is declared as an inner class of FixedArray. One ‘gotcha' for implementing STL iterator classes is that we end up doing it twice – once for the const iterator, and once for the non-const. However, the differences between the two classes are usually quite minor, they mostly have to do with the types of the parameters and return values. Austern presents a nice solution that avoids redundant code for the two iterator variants in [Austern01]. The essence of this method is the ChooseType template, which selects one of two types based on the value of a constant bool. So even though we might vary half a dozen different types between the const and non-const iterator classes, we'll only need to expose a single template parameter. For example, in the listing below we use this technique to declare a type named reference that alternates between a reference to a const and a non-const element in the container, depending on the isConst template parameter: 
template <bool isConst = false> 
class FixedArrayIterator {
    typedef typename Choose<isConst, const T&, T&>::type reference;

    // reference is a reference to a const object when isConst is true,
    // and a reference to a non-const object with isConst is false...
    refererence operator*() { ... }

    // iterator code continues...
Like containers, iterators have specifications in the C++ Standard that define how they should behave. The most basic but still useful iterators implement the forward iterator specification. The main functions a forward iterator provides are operator*(), operator->() and operator++().

These functions are pretty straightforward to implement for FixedArrayIterator. The most interesting one is operator++. Whenever we advance the iterator, we skip over any sentinel values to the next real element, or to the end of the container. The end iterator is simply the one-past-the-end position.

The last thing we need for our iterator class is a set of standard typedefs that are used by STL's generic algorithms to query the capabilities of the iterator class. For the FixedArrayIterator>, they look like this:

typedef typename FixedArray::value_type value_type; 
typedef std::ptrdiff_t difference_type; 
typedef std::forward_iterator_tag iterator_category; 
typedef typename Choose&;lt;isConst, const T*, T*>::type pointer; 
typedef typename Choose;lt;isConst, const T&, T&>::type reference;
The only typedef that's a little unusual is iterator_category. The standard library provides a set of these iterator tags which allow template authors to parameterize their code in terms of the capabilities of the iterators they are given. As iterator authors, we just need to pick the tag that best matches the iterator specifications we are implementing.

Iterators have helped us to implement a container that is frugal with memory consumption for use in our octree nodes. At the same time, the octree code itself is oblivious to the underlying complexity, and we can swap between our FixedArray and std::vector by changing two typedefs in the node declaration.


Custom Function Objects

Functors in C++ are created from classes that override the operator() member function. For maximum compatibility with other STL components, functors should inherit from unary_function (one parameter) or binary_function (two parameters) when applicable. For example, a unary functor named MyFunctor, which takes an int parameter and returns a value of ReturnType is shown in the listing below: 
// define MyFunctor:
class MyFunctor: std::unary_function<int,ReturnType> { 
public:
    ReturnType operator() ( int sampleParam ) const { ... } 
};

// use it like this:
MyFunctor f;
ReturnType result = f(42);
Functors have some neat properties that make them more powerful than function pointers. Because they are classes, different functors have different types, which is useful for instantiating other templates. Another useful property is that functors can have two kinds of parameters, those bound when the functor is instantiated (i.e. passed to the constructor), and those bound when the functor is invoked (i.e. the parameters to operator()). This provides a kind of partial function application or currying. Functors are also often faster than function pointers because they can be inlined by the compiler.

In the STL, functors are intended to be passed by value, which we need to keep in mind when designing our own. In particular, this means functors should avoid keeping internal state data, which can be enforced in code by declaring operator() to be const. The reason for this restriction is we can't make many assumptions about how our functor will be used by other components (e.g. when it will be copied, how many times it will be applied), which makes it very difficult to design stateful functors that behave correctly.


Custom Algorithms

STL algorithms operate over a range of objects specified using iterators, and output their results by overwriting the elements of a container using an output iterator. Typical STL algorithms handle operations like sorting and partitioning, searching, and re-ordering. For something more specific to games, we'll look at generating a list of colliding objects from a container of game objects.

The general form of the algorithm is to take a collection of objects in the world and test each of them for collisions against a list of possible colliding objects. Each colliding pair goes into the results list. In the worst case, the candidates for each object are all of the other objects in the world, resulting in an algorithm which is not very scalable. Fortunately, this is just the kind of thing octrees are good at optimizing.

Our generic collision algorithm takes two types of iterators as input: a pair of iterators from the source container and one iterator for the destination container. The other two template parameters are functors that allow us to customize the non-generic parts of this algorithm: how the list of collision candidates is generated, and how the collision test itself is performed. 
template <typename SrcIterator, 
          typename DestIterator,
          typename CandidatesFunctor, 
          typename CollisionTestFunctor>
void generate_collisions( SrcIterator srcBegin, 
                          SrcIterator srcEnd,
                          DestIterator destBegin,
                          CandidatesFunctor getCandidates,
                          CollisionTestFunctor testCollision ) {
    typedef typename SrcIterator::value_type CollisionObject;
    typedef typename CandidatesFunctor::ResultsIterator 
                      ResultsIterator;
    typename CandidatesFunctor::Results candidates;

    for ( SrcIterator i = srcBegin; i != srcEnd; ++i ) {
        const CollisionObject& collidee = *i;
        candidates = getCandidates( collidee );
        
        for ( ResultsIterator j = candidates.first;
              j != candidates.second;
              ++j ) {
            const CollisionObject& collider = *j;
            if ( collidee != collider 
                    && &collidee < &collider
                    && testCollision(collidee, collider) ) {
                // collision detected!
                *destBegin++ = std::make_pair(collidee, collider);
            }
        }
    }
}
One nice thing about working with template functions, as opposed to template classes, is that the types are deduced automatically by the compiler when the function is called. This means we don't have to explicitly instantiate the template parameters on a template function.

Although the template parameters and typedefs take up a lot of space, the actual code is relatively simple. The outer loop uses the source iterators to step through the input objects and generate a list of possible colliders for each one, using the CandidatesFunctor. This functor takes an object and returns a begin/end pair of iterators representing the set of collision candidates. The inner loop then tests each candidate using the CollisionTestFunctor, and when a collision is detected, adds the two objects as a CollisionPair to the output container.

In this code, we can see the typedefs from the iterator classes coming into play. For example, the type of object we are processing is nested inside the source iterator in SrcIterator::value_type.

To make the discussion more concrete, let's take a look at how we actually apply this generic algorithm. A typical call to generate_collisions() would look like: 
// given a container "myGameObjects" of GameObject instances and an
// empty container "results" of pairs of GameObjects...
generate_collisions( myGameObjects.begin(), myGameObjects.end(), 
                     back_inserter(results), 
                     StdContainerCandidatesFunctor<GameObjContainer>
                         (myGameObjects), 
                     SphereCollisionFunctor<GameObject>(5) );
The back_inserter is something we haven't looked at yet; it is an iterator adapter. It takes a standard container and returns an iterator that uses the container's push_back() function to insert new items into the container each time the iterator is used to write an element. The back_inserter lets the output container manage the storage on demand, rather than requiring the caller to over-allocate a container for the worst case.

In the code listing above, we used a naive CandidatesFunctor that just returns the source container's begin() and end() iterators. This means that every object will be checked against every other object for collisions. We can reduce the complexity of this algorithm to by replacing this functor with one that uses the octree to efficiently determine the objects in the nearby region. Specifically, we use the find_range() function, which returns a pair of local_iterators over the range of elements that are in octants within a given radius. As long as the radius is fairly small relative to the size of the octants, find_range() will only visit a small subset of the octree while computing this range, which is the source of the efficiency gain.

This small change dramatically improves the scalability of this collision function. We can continue to optimize the algorithm by trying different containers and candidate functors, which use additional techniques to improve efficiency. The algorithm can also be easily extended to handle new collision models by supplying different functors. All of this is possible without virtual functions or inheritance, and without touching the generic algorithm code.


Conclusion

In this article we looked at how to implement custom functors, containers, iterators, and algorithms that are compatible with the C++ Standard Library. The finished code may look daunting at first glance, but in fact a lot of custom STL work is just boilerplate code. Over time you will build up a library of examples that save implementation time and effort. Another way to reduce the amount of boilerplate code is to use the Boost library [Boost09], which contains frameworks and base classes that implement much of the common functionality of STL components, distilling the code we have to write down to a smaller set of essential functions.

The payoff for the effort to be STL compatible is that we get flexible, efficient code that is consistent with the standard library. This enables new programmers who know their way around C++ to quickly get up to speed with in-house code. Mixing-and-matching STL, in-house, and third-party custom code becomes relatively easy. By extension, we can use generic coding style to gain flexibility and reuse, improving coding productivity without resorting to scripting and interpreted code. The flexibility inherent in generic code also provides us with a wide array of options for optimization, which have minimal impact on the surrounding code. In these ways, STL used well is a valuable part of the game programmer's toolbox.


References

[Austern01] Austern, M., "The Standard Librarian: Defining Iterators and Const Iterators," C/C++ Users Journal, Vol. 19 (January 2001): pp. 74-79.

[Boer00] Boer, J., "Using the STL in Game Programming," Game Programming Gems, Charles River Media, 2000: pp. 41-55.

[Boost09] "Boost C++ Libraries," available online at http://www.boost.org, September 1, 2009.

[Gamma94] Gamma, E., Helm, R., Johnson, R., Vlissides, J., "Design Patterns: Elements of Reusable Object-Oriented Software," Addison-Wesley 1994.

[Ginsburg00] "Octree Construction," Game Programming Gems, Charles River Media, 2000: pp. 439-443.

[Isensee02] Isensee, P., "Custom STL Allocators," Game Programming Gems 3, Charles River Media, 2002: pp. 49-58.

[ISO14882] ISO/IEC 14882:2003 "Programming languages - C++".

[ISO19768] ISO/IEC TR 19768:2007 "Information technology - Programming languages - Technical Report on C++ Library Extensions".

[Josuttis99] Josuttis, N. M., "The C++ Standard Library: A Tutorial and Reference," Addison-Wesley 1999.

[Meyers98] Meyers, S., "Effective C++," Addison-Wesley 1998.


About the Author

Neil has worked on games and related entertainment technologies since 1998. After completing his degree in Computer Science and AI at the University of Toronto, the challenges of real world programming focused his attention on software engineering, while his interests in code optimization and eye candy led him to computer graphics. He continues to stay in touch with his academic roots as an ACM Professional and SIGGRAPH member. Today, Neil runs Vertex Blast, an independent software company supplying programming skills to the entertainment industry.
Neil Gower
09-06-2010
09-06-2010
Tech Articles
no
The Standard Template Library (STL) is widely used by C++ developers, but some game programmers still shy away from it. The STL's use of templates and generic programming style can be off-putting to developers who are used to working with low-level code and within the limits of older hardware. The state of current compilers and STL implementations has advanced considerably. To get the most out of the STL, you need to know how to use it, but also how to customize and extend it to meet the needs of game development projects. To help you become familiar with the STL, we will take a look under the hood of several core STL components by extending them to solve game-specific problems.
]]> http://software.intel.com/en-us/articles/extending-stl-for-games/ Mon, 06 Sep 2010 00:00:00 -0700 http://software.intel.com/en-us/articles/extending-stl-for-games/#comments http://software.intel.com/en-us/articles/extending-stl-for-games/ Visual Computing Game Development Image Sequences or Vector Art in the Development of Flash* Games and Virtual Worlds? By Tom Costantini

Download Article

Download Image Sequences or Vector Art in the Development of Flash* Games and Virtual Worlds? [PDF 1.4MB]

For years, Adobe ActionScript* developers have been using Adobe Flash* as their main development tool for creating extremely entertaining, downloadable, and browser-based games. With hot new platforms like netbooks being released, developing games for these platforms using Flash makes a lot of sense. These games range from simple single-player games to more competitive multi-player games and very sophisticated massive multiplayer online role-playing games (MMORPGs) like Sifaka World*. These MMORPGs, or virtual worlds, allow a multitude of players to play the game simultaneously and interact with each other in real time. With so many players on screen at any given time, it's important to optimize your graphics as much as possible to allow for the most favorable user experience. It's the developer's job to decide how to best optimize these graphics, which for the most part consist of either raster or vector images.

This article covers the numerous reasons why artists and developers would choose to use an image or image sequence as opposed to vector art as it relates to Flash games and virtual world development. It discusses the process of creating vector art in Flash and converting that artwork into image sequences when needed. Also, the article touches upon how to determine when the use of an image sequence would be more beneficial to the user experience than the actual vector artwork, and discusses some of the typical problems developers may encounter along with techniques to get around those problems.

Note: This article assumes that you have a basic knowledge of as well as some experience using Flash.

Raster Images and Vector Images

When developing a 3D virtual world in Flash, you're most likely going to be importing raster image sequences into the Flash timeline in order to construct it. But if your world is a 2D environment, you have the option to build your assets directly in Flash as vector art. For this reason, it's important to understand the differences between raster and vector graphics. A raster image uses a series of pixels that form points of color to create an image on your computer's monitor. It's not possible to shrink or enlarge raster images like JPEGs, GIFs, and bitmaps without loss of image quality. As you can see in Figure 1, the raster graphic on the right appears blurry when enlarged.


Figure 1. The difference when enlarging vector and raster graphics (Images copyright Two Animators! LLP and Sifaka Productions, LLC)

Unlike a raster image, vector images store all the mathematical information necessary to construct the image within it as a series of vectors, or points. There are several advantages to using vector artwork, the principal reason being that it's easily scalable to any size without any loss of image quality. Also, vector art typically has much smaller file sizes compared to raster images, which can allow for greater optimization and overall user experience during game play.


Creating Vector Art in Flash*

Flash is a vector-based program, which means that all the graphics you create using Flash's tools are automatically vector images. Flash has many tools you can use to create your artwork, including the line tool, the brush tool, and the paint bucket, just to name a few. It also includes a useful tool called the subselection tool. When you click a vector image, the subselection tool gives you an idea of how many "points" the drawing has. In Figure 2, I've selected the outline of the character's head, and the tool highlights the points. The fewer points an image has, the more optimized it will be. However, it is important to note that you will begin to lose the form of your image if you optimize the lines too much. It's a delicate balancing act between how small you want your file size to be versus how intricate you need the artwork to be, making optimization of some files an art form unto itself.


Figure 2. Sifaka World character and the subselection tool

The procedure to optimize a vector graphic in Flash is simple. The first step is to highlight the image you want to optimize with the lasso tool. Next, click Modify > Shape, and then click Optimize from the list to open the Optimize Curves window. Here, you can choose the Strength, or how much you want to optimize the image, which is displayed in a value from 0-100%.

Note: The Flash shortcut to launch the Optimize Curves window on a PC is Ctrl+Alt+C. On a Mac*, the shortcut is Cmd+Opt+Shift+C.

Take a look at Figure 3: I have optimized the character's head at 100% to demonstrate what Flash may do to a graphic during the optimization process. Typically, I wouldn't optimize a character this much, because you begin to lose image quality. Instead, I would play with the Optimize Curves settings until I found a level of optimization I could live with. Alternatively, you can choose to optimize only one section at a time instead of the entire graphic in order to maintain a higher-quality image. The difference in file size between the two heads below is approximately 3 KB, so you can imagine how many kilobytes you can save in a Flash game or virtual world by optimizing all your graphics.


Figure 3. Sifaka World character after being optimized

For example, Sifaka World currently has more than seven main regions, each of which has several sub-regions, or world areas, to explore. The game also currently has nine different avatars, each with multiple clothing, accessory, and prop assets, which players can choose from in order to customize their characters. Because Sifaka World is regularly being updated with new graphics, audio files, and world regions, it's incredibly important to keep an eye on file sizes. By optimizing each and every item that goes into the game, my development team ends up saving a lot of kilobytes and guaranteeing users a better experience during game play!

Vector graphics sometimes have a reputation for appearing computer-generated or "clean-edged," mainly because they are made up of geometric shapes. However, in the hands of a talented artist, wonderful artwork can be created using this format. The example in Figure 4 is a vector art background built in Flash for the Sifaka World game.


Figure 4. Sifaka World vector art background (Asian region)


When to Use an Image Sequence Instead of Vector Art

For the most part, vector art is smaller in file size than raster images; however, there are some occasions when a raster image can actually be less processor intensive than vector art. In those instances, using a raster image is more beneficial.

An example of this is the main Treetop area of Sifaka World, which is an 800 × 1600 scrolling background (see Figure 5). In this area, users see only the treetop portion of the background in their browser window; however, once they enter the elevator, the entire background pans downward until their avatar exits the elevator at the Forest Floor. It's an impressive effect and adds a lot of fun to the game, but it also takes some involved planning in order to pull it off flawlessly.


Figure 5. Sifaka World main Treetop Entrance area (full scrollable image)

Let's take a closer look at just the top portion of the Treetop background (see Figure 6). I have highlighted some of the vector points used to create the background image with the subselection tool. Sifaka World is an extremely stylized environment made up of many vector points. When a computer graphics card has to process all of the points, the result is a very slow and choppy scrolling movement. In this instance, it is more beneficial to turn the vector artwork into a raster image for the scrolling effect. Because the size of the background doesn't change-only the position is moved further downward-it is less processor-intensive to use a raster image. So, by creating a raster image out of the main portion of the background and only using vector assets for the interactive portions, such as rollovers and the animation of the elevator doors, my development team created a smoother animated effect that users' computers can play back much more easily.


Figure 6. Sifaka World main Treetop Entrance area (top portion only)


Converting Your Flash* Vector Art into Images

If you decide to convert your Flash vector artwork into images, you will need to determine which type of image you want to create. I like to export images as Portable Network Graphics (PNG) images, because they use lossless data compression-a fancy way of saying they keep your graphics looking high quality. PNGs also allow for the use of alpha transparencies, which are useful when you need an image that has a see-through background. However, it is equally important to note that Flash has many export options, including JPEG, GIF, BMP, and even Adobe Illustrator*, which is also an excellent vector graphics program.

When converting Flash vector art into raster images, the first step is to line up the vector art on the Flash timeline. If you're only exporting one image, simply click File > Export > Export Image to open the Export Image window. Here, choose the type of file you want to export as well as where you want to save the image. In the example in Figure 7, I've selected to export a PNG image and to save the image to the desktop. Once you have selected your options and clicked Save, you will be prompted to select the resolution you want the image to be, how many colors, whether you want to add an alpha channel, and so on. Click OK to export the image.


Figure 7. Options in the Export PNG window


To export a sequence of images, such as the walk cycle shown in Figure 8, line up each image in the sequence on the Flash stage one after the other. Then, click File > Export > Export Movie to open the Export Movie window. Choose the type of files you want to export and where you want to save the image. In this example, I've selected to export a PNG sequence and to save the images to a folder on the desktop. (I highly recommend exporting long image sequences into a folder; otherwise, you end up with tons of images all over you desktop.) Once you've selected your options and clicked Save, the rest of the export procedure is the same as for a single image.


Figure 8. Export the movie to render an image sequence


Summary

Adobe Flash is a great program for creating intricate vector art images and animations for games that are both light in file size and easily scalable. Flash has also made it easy to export your vector files as both raster images and Adobe Illustrator files. It's extremely important for developers to have the ability to determine when the use of an image sequence would be more beneficial than using vector graphics. Although there are some limitations to what can be accomplished with vector drawings, in the hands of talented artists, truly amazing artwork can be created.


Related Content

Integrating 3D Image Sequences into Flash


About the Author

As the co-founder and creative director of Two Animators! LLP (2A!), Tom Costantini has more than nine years of experience working with highly recognized brands. 2A! is a full-service multimedia studio with clients such as Mattel, Colgate-Palmolive Company, USDA, Atmosphere BBDO, VH1 Music Channel, Meat Loaf, Mezco Toyz, Sifaka Productions, and the rock group YES. Tom has also written and co-directed dozens of animated shorts, including a five-minute educational video for Colgate that teaches kids how to properly brush their teeth and a seven-minute music video for Meat Loaf's "Bat out of Hell III" tour. His creative work has been featured on WPSD Channel 6 News and in Millimeter Magazine.

]]> http://software.intel.com/en-us/articles/image-sequences-or-vector-art-in-the-development-of-flash-games-and-virtual-worlds/ Thu, 22 Jul 2010 00:00:00 -0700 http://software.intel.com/en-us/articles/image-sequences-or-vector-art-in-the-development-of-flash-games-and-virtual-worlds/#comments http://software.intel.com/en-us/articles/image-sequences-or-vector-art-in-the-development-of-flash-games-and-virtual-worlds/ Visual Computing Game Development Artist Integrating 3D Image Sequences into Flash By Tom Costantini

Adobe Flash* has come along way from being just a simple multimedia tool for moving around vector and raster graphics. It's now used in numerous applications-from the online streaming of video and audio to creating sophisticated Web site and gaming experiences for various platforms, including netbooks, PC, and Mac*. Flash is also being used to create complex browser-based massive multiplayer online role-playing games like Club Penguin* and Sifaka World*, and it's even being used as the main animation software for creating television shows like the highly popular Foster's Home for Imaginary Friends* and Skunk Fu*.

This article shows how to integrate 3D image sequences from programs like Adobe After Effects*, Autodesk 3ds Max*, wondertouch particleIllusion*, and many others into your Flash animated projects. Topics of discussion include different reasons why you would want to integrate 3D into your Flash files and the process of automating the import of image sequences onto the Flash stage as well as creating chronological key frames. Other areas covered include the pros and cons of the overall process, specifically focusing on the difficulty of integrating large sequences into the Flash timeline. Finally, the article offers a few tips and techniques that 2A! has developed for integrating 3D sequences and managing the playback within Flash.


Why Integrate 3D?

There are many reasons you may need to incorporate 3D image sequences into Flash, but the most common reason is to enhance your project by adding a more realistic feeling. The addition of 3D elements can make your project or animation a higher-quality production. Also, in some cases, 3D can be helpful in providing a better interpretation of what an actual real-life object is like. For example, 3D may give medical students a better understanding of how the human heart works when they can explore the amazing inner workings of the valves and ventricles from every angle-something that is obviously more difficult to do with 2D graphics.


Getting Started

The first thing you're going to need is a 3D animation. You can use any of several third-party programs to create your 3D animations, including Autodesk Maya*, Adobe After Effects*, Autodesk 3ds Max*, and Electric Rain Swift 3D*, just to name a few. You can also purchase a stand-alone graphics application like particleIllusion*, which has numerous preinstalled 3D effects animations that you can easily modify to your project's specific needs. Whatever software you decide to use, make sure you have the option of exporting the final animation as an image sequence.

---------------------------------------------------------------------------------------------------------------------------------------------------
Note: This article assumes that you have a basic knowledge as well as some experience using the 3D software of your choosing.
---------------------------------------------------------------------------------------------------------------------------------------------------

Now that you have a 3D image sequence to work with, let's get started. You can use this process for integrating 3D sequences into the Flash timeline with most versions of Flash; however, for the purpose of this article, you will be using Flash CS4.

Start by launching Flash and creating a new document. Name this movie 3D_Sequence_Test.fla, and save the file to your desktop. Next, click Modify > Document. The document area allows you to customize your Flash movie to your project's exact specifications. Pay particular attention to the Frame rate text box: You want to make sure that the document's frame rate is the same as the 3D image sequence you are importing (see Figure 1). Use a stage setting of 1920 × 1080 with a frame rate of 30 fps-standard settings for high-definition television (HDTV) projects


Figure 1. Your new Flash movie project (All images are copyright Two Animators! LLP)

I recommend creating a new graphic symbol and importing your 3D image sequence into it. Doing so is helpful if you need to move the sequence later to adjust the position of the animation. To do this, click Insert > New Symbol. Name the symbol 3D_Sequence_01. Select Graphic to allow your animation to play within the Flash timeline rather than having to export a .swf file to view the playback. If you decide to import the animation into the main timeline rather than use a graphic symbol, you'll need to select and move every key frame in order to adjust the position later.


Importing Your 3D Sequence

Now, you're ready to import your 3D animation. Open the Flash library and double-click the symbol you just created. (Doing so takes you inside the 3D_Sequence_01 symbol.) Next, click File > Import > Import to Stage (see Figure 2) to open the Import dialog box. From here, you can search for your 3D files and select them for import.

Figure 2. Search for files to import.

Find and select the first image in your sequence, and then click Open. It's not necessary to click the entire sequence of images: Flash automatically detects that your image is part of a sequence and prompts you to import all of the images in the sequence (see Figure 3). Click Yes to import all the images.


Figure 3. Import all your movie images.

Depending on the length of your animation, it may take Flash a little time to import the 3D sequence of images. Flash automatically imports the images and places them in chronological key frames within your symbols timeline (see Figure 4). When your image sequence is fully imported, be sure to save your document.

Figure 4. The fully imported 3D image sequence

Now that your 3D image sequence has been successfully imported into your graphic symbol, you can drag that symbol from the library and place it anywhere on the main Flash timeline. Once placed on the timeline, change the graphic symbols properties from Loop to Play Once, and give that clip the appropriate number of key frames needed to play your animation one time. For instance, if your 3D sequence is 100 frames long, give your symbol 100 frames in the main timeline (see Figure 5). Now, you can add text, images, or sounds to complete your project.

Figure 5. Adjusting the Flash timeline to accommodate your images series


Troubleshooting

You probably won't experience too many problems when working with smaller image sequences at multimedia resolutions; however, you will definitely run into some issues if you are importing large 3D image sequences into a project with standard television or HDTV resolutions. Depending on your computer's graphics card, processor, and so on, you may run into issues where Flash will run out of memory to complete a task. When this happens, you may find missing key frames within your animation sequence, or the key frames may be there but tinted blue, which is an indication of insufficient memory (see Figure 6). Allocate as much memory as possible to your Flash application before beginning a large import.

Figure 6. Allocate sufficient memory for your project.

Another common problem when using large sequences is frequent crashing. Be sure to save frequently when working with large files, especially when trying to move large movie clips around in the timeline.


Tips and Techniques

I've been working with Flash since its earliest versions and have discovered a few tricks that help avoid the annoying problems I mentioned above. For instance, to avoid the "not enough memory" problem, import shorter segments of the 3D image sequences into separate graphic symbol instances, and then line them up on the main Flash timeline. Here's a quick example: If your image sequence is 300 frames long, separate the images into three 100-frame sequences. Next, using the technique described in the "Importing Your 3D Sequence," import each 100-frame sequence into three graphic symbol instances, labeling them Sequence_01, Sequence_02, and Sequence_03. Finally, drag each graphic symbol onto the main timeline, and line the symbols up one after another in sequence. Flash works much better when you use smaller segments, and you can easily line up your symbols on the timeline using the onion skin and align tools (see Figure 7).

Figure 7. Line up multiple small sequences on the Flash timeline to avoid memory problems.

If you do find yourself in a situation where one or more of your images is missing or tinted blue, you can try the following technique. Instead of attempting to re-import the entire image sequence, delete the missing or corrupt images, and re-import only those elements. Then, you can place them into the missing key frames and use the align tool to make sure they are in the proper position. This technique can save you a lot of time if you're working with a long sequence and have only lost a few actual images.

Similarly, to avoid the frequent crashing that tends to happen when working in Flash with larger image sequences, I often separate the project further into smaller and easier-to-work-with Flash documents. For example, a 3D image sequence that's 500 frames long would be separated into two 250-frame Flash .fla files. Again, this allows animators to work with large files without having frequent memory and crashing issues, and the final product can be easily put together in your favorite video editing software later. (This is most applicable when working with HD-size files.)


Summary

Successfully integrating 3D image sequences into your Flash animations can both enhance your project and give it the appearance of being a high-quality production. Using a limited amount of 3D sequences in your multimedia presentations and games is easy, but integrating large sequences can be both tricky and frustrating. Using the right techniques can greatly help ease the process and help your animations stand out from the pack.


About the Author

As the co-founder and creative director of Two Animators! LLP (2A!), Tom Costantini has more than nine years of experience working with highly recognized brands. 2A! is a full-service multimedia studio with clients such as Mattel*, Colgate-Palmolive* Company, USDA, Atmosphere BBDO*, VH1 Music Channel*, Meat Loaf*, Mezco Toyz*, Sifaka Productions*, and the rock group YES*. Tom has also written and co-directed dozens of animated shorts, including a five-minute educational video for Colgate* that teaches kids how to properly brush their teeth and a seven-minute music video for Meat Loaf's "Bat out of Hell III" tour. His creative work has been featured on WPSD Channel 6 News and in Millimeter* Magazine. ]]> http://software.intel.com/en-us/articles/integrating-3d-image-sequences-into-flash/ Thu, 17 Jun 2010 00:00:00 -0700 http://software.intel.com/en-us/articles/integrating-3d-image-sequences-into-flash/#comments http://software.intel.com/en-us/articles/integrating-3d-image-sequences-into-flash/ Visual Computing Game Development Artist