Most AAA titles seem to support something like 5-6 dynamic lights. I’m sure you’ve noticed by now that this game takes place mostly in the dark, and I plan on making it darker still (if I can). Well placed lighting will play a big role in making things look interesting, as well as just being able to see your surroundings.

Pre-pass or fully deferred rendering would allow for many lights with little work, but these rendering schemes don’t support MSAA or, more importantly, transparent objects. Also, deferred lighting is not a very good fit for the XBOX, due to it’s 10MB EDRAM and predicated tiling, and it’s relatively low texture bandwidth. I did spend a little bit of time playing with J. Coluna’s pre-pass rendering code on the XBOX a few days ago, but the lighting quality was very poor when used with the XBOX HDRBlendable format (which is 10 bits per channel plus 2 bits left over).

By partitioning the space into a grid and registering objects and terrain chunks into it, I can currently draw 30 point lights at once on the xbox (at 60 FPS). The CPU speed is the limitation so far, not the graphics card.

Of course, that is with just the terrain. Things will get a lot slower when I start adding trees and other objects.

And I haven’t mentioned shadows yet.

In order to be able to set the game in the dark atmosphere that I’m going for, I’ll want to have at least 20 point lights, though I might be able to get away with casting shadows from only 10 or so.

Dynamic point lights moving across the terrain.

I’ve starting writing some basic rigid body physics. I have projectiles working that can detect collision, but do not react to collisions appropriately yet. Actually the lights in the picture above are projectiles launched from the camera’s position.

I’ve also built a framework for making explosions of various types, complete with flying debris.

A couple of basic explosions with debris.

The explosion above uses a fairly flexible Explosion class that I wrote yesterday, so new explosions can easily be created with little code at this point. Most projectiles that the player can fire will need some sort of explosion, so recreating an explosion type effect will happen often. This could be used to display the destruction of a crate for example. Just replace the explosion particles with subtle smoke, and the debris with broken wood models. Since the explosion debris are projectiles themselves, they can have their own explosions, which can have their own debris, ad infinitum.

Today though, I (re)wrote an object pool class.

Garbage collections are expensive on the compact CLR, they occur whenever 1MB of garbage is created, and cause noticeable stutter in the game when they happen. For this reason, I simply try not to generate any garbage.

Why we can’t just choose to have collections occur every 16MB or something, I don’t know.

I’ve written custom pools in various places in this project, because creating an efficient generic pool is tricky. Have a look at swampthingtom’s generic object pool. It uses a struct as a container for each pooled item and can only pool types that meet the new() constraint (public parameterless constructor, and no abstract classes allowed).

Having to write a pool for every type though is slowing me down, so I spent some time today thinking about a good design for a generic object pool.

Giving up abstract classes (which is what swampthingtom does with his pool) is going a little too far for me. Also, a significant performance cost is associated with the use of that pool, which makes it less than ideal if you are using it to allocate hundreds of objects or more.

Here’s another approach, which is minimalist, and still uses the new() constraint. This pool is clearly faster, but offers no way to iterate over over the collection of active pooled objects, and again, no abstract classes or constructors with parameters allowed. It’s also basically just an unsafe version of Stack

So I wrote a pool that partitions an array into two parts, the first part for live objects, the second for dead objects. Then I effectively do what the compact CLR does with dead objects — sweep across the dead objects once in a while, and compact them into the second part of the array. As for object initialization, I pass the pool a Func delegate that does the initialization. Delegates are a little slow, but in this case they are called rarely — in fact, they should be called never, if I pick the right pool sizes. The code is barely tested so far and might benefit from another small optimization or two, but I’ll be sure to post it soonish. As usual, I’m also not fond of the idea of posting good code this far from the competition deadline.

By the way, I fought with stackoverflow to try to get some discussion going about ways to iterate over the pool without generating garbage. Most people did not want to hear about avoiding garbage creation. Eventually Eric Lippert came to the rescue and defended my question.

E.g.:

• [-3] Pure black rolling fog to simplify fog shader.
• [4] Dual paraboid point light shadow map implementation
• [2] Terrain diffuse lighting based lightning effect.
• [6] Moon billboard.
• … etc.

Where [x] represents x priority for the item. (A larger priority value means I should focus on that item before a lower priority valued item.)

I assign higher priority to items that are both easy/fast to implement and important features that the game needs. Hence the moon is high priority — it dramatically alters the mood of the scene for something that should only take maybe an hour to implement (considering that I have zero billboards in the game at the moment).

The more I try to estimate the time cost of implementing various features, the more I realize how hopeless it is to try to estimate the time cost of implementing a feature.

Creating the moon texture took an hour.

Creating the billboard code took an hour, including setting the moonlight from the right direction.

Getting the moon to look just right (that is, tweaking the texture, position, and lighting) took an hour.

At this point it was working on the PC.

The moon! Notice the specular moonlight shining on the terrain.

Then I slept, and when I woke up, tested some other code on the XBOX only to find that the moon is not displayed properly on the XBOX!

Obviously this is not how the moon is supposed to look.

Figuring out this bug took over an hour.

The fix by the way, was changing this pixel shader:

float4 PixelShaderFunction(float2 texCoord : TEXCOORD0, float4 color : COLOR0) : COLOR0
{
    color = tex2D(TextureSampler, texCoord);

    // Apply the alpha test.
    clip((color.a - AlphaTestThreshold) * AlphaTestDirection);

    return color;
}

To this one:

float4 PixelShaderFunction(float2 texCoord : TEXCOORD0) : COLOR0
{
    float4 color = tex2D(TextureSampler, texCoord);

    // Apply the alpha test.
    clip((color.a - AlphaTestThreshold) * AlphaTestDirection);

    return color;
}

All in all, creating the moon took over 4 hours — about 4 times longer than I thought.

Days like this make me nervous — what if creating the whole game takes 4 times longer than I thought? After all, first place DBP winners likely spend years, not months, (and certainly not just 3 months) on their submissions.

The bloom filter takes the brightest parts of the image, blurs them, and mixes the result back into the scene. This makes lights glow, softens bright edges, and generally makes things look more natural.

Since there’s very little light you can’t notice the bloom so much, although it’s very obvious on the bottom center bar indicator. The rest of the HUD does not have the bloom applied to it.

The blue sky effect resembles an aurora somewhat, and is animated. It’s obviously more interesting to see in motion than in this still picture.

Compare to this aurora below (courtesy wikipedia).

Aurora Australis

public void ReturnPointLight(PointLight3D light)
{
#if DEBUG
    // Assertion tests.

    Debug.Assert(light == _pointLightPool[light.PoolIndex]);
    Debug.Assert(_pointLightAvailable[light.PoolIndex] == false);

    // Make sure that light is not already in available stack.
    foreach (int index in _pointLightAvailableIndices)
    {
        Debug.Assert(index != light.PoolIndex);
    }

    _pointLightAvailable[light.PoolIndex] = true;
#endif
    _pointLightAvailableIndices.Push(light.PoolIndex);
}

That is an excerpt from my LightingManager class, which has a PointLight pool built in.

That function returns a point light to the pool when it is no longer needed. This is roughly the equivalent of doing free(myPointLightInstance) in C or C++ when the instance is no longer being used. Sadly, the compact CLR that the XBOX uses has a terrible garbage collection implementation, so using object pools and allocating and freeing objects from the pools manually is a necessity.
As you can see in this function, several assertions are done.

• Assert that the light instances’ index matches the index of the internal pool.
• Assert that the light is actually not available (because the function is meant to make unavailable lights available).
• Assert that the light is not already stated as being available in the availability stack.

These checks are a bit slow, so I run them only when the DEBUG flag is set.
Edit: Using the DEBUG conditional is not necessary if you only write Debug.Assert() since Debug methods are only called if the DEBUG flag is set automatically, but are useful if you’re writing other code, as I have above.
And actually, the bool[] _pointLightAvailable array is only used for debugging/testing. Setting up some decent sanity checks light this throughout my code makes development much faster in the long run, because I can be confident that things are doing what they are supposed to.

With the lighting manager in particular, it would be easy for the manager to do something unwanted, and cause the lights to LOOK wrong, although the program will not crash. In this type of case, it’s hard to know what’s causing the problem without lengthy code tracing/debugging if you don’t have some pre/post condition assertions in the code.

However, I did find time to write the terrain chunk drawing loop, which implicitly builds a quadtree and tests at each recursive level the nodes of the tree against the camera frustum.

I discovered quickly that testing whether every single chunk is in the camera frustum or not is very expensive — 8 ms, which is half the time I have to do all draw thread computation at 60 fps.

In my previous terrain, where I used a quadtree for each chunk, the number of tests to see if a chunk was in the frustum was bounded, since the quadtree didn’t need to recurse all of the way, if the entire terrain was visible, since further blocks would simply be drawn larger.

In the new chunk LOD method, in the worst case, the entire terrain is visible and all blocks need to be drawn and tested, which takes 8 milliseconds to check, using 64×64 chunks and a 1024×1024 terrain heightmap.

On the XBOX (using only 1 core), using XNA’s BoundingSphere and BoundingFrustum classes, I can do about 40,000 sphere/frustum tests per second (600-700 per frame).

The GPU can test whether a triangle is in the frustum on the order of 100,000,000 times per second (over 1 million per frame).

The terrain chunks I’m using are 64×64 = 4096 triangles each. It is actually faster to send thousands of triangles to the GPU than to perform a single intersection test on the CPU. Unless of course, you’re GPU bound and have some CPU cycles to spare.

Exactly how my situation will turn out is to be determined, but I thought I’d emphasize just how large the processing speed difference is for this type of operation, between the CPU and the GPU on the XBOX with XNA.

In an effort to minimize the chunk drawing loop CPU time, I’ve also built a ReusableMinHeap class, which is a garbage-free min heap, which sorts the chunk draw calls for me from closest to furthest — to minimize overdraw. So far, it performs roughly the same as C#’s Array.Sort, which uses quick sort.

I’ll be happy to share the min heap class when the competition is over. Someone remind me.

By the way, here’s what the chunk-LOD terrain looks like so far:

The current state of the terrain as of March 19, 2011. Using 64x64 chunks and a 1024x1024 heightmap.

Recall from my previous post that pathfinding was done in 3D, including diagonal movement, allowing 26 possible directions of movement at each cell in the grid. To reduce this, we move to 2D pathfinding, since the 3D grid was very thin anyway, and introduce weights at each grid cell to account for almost-3D objects on the grid.

Allowing diagonals permits 8 movement directions. It also allows actors to circumvent obstacles by moving through a corner, when adjacent cells touching at their corners should block it.

With diagonals, if we aren't careful, objects can pass through two objects that meet at their corners.

To increase speed and avoid having to check for adjacent obstacles before moving through corners, we can use only 4 directions of movement. The problem with this is that monsters following a path defined by this movement look robotic:

2D path finding without diagonals. A monster following this path in the naive way would turn down, right, down, right,... making it seem robotic.

One solution I proposed to this was to use minimal acceleration hermite curves to generate smooth paths between grid cell centers.

To find any alternatives, I asked myself, what would Captain Kirk do?

Then I remembered this: http://kirkfails.ytmnd.com/

While I might still need to generate these curves, in the meantime I have decided to take a different approach:

Path finding in a hexagonal coordinate system.

Using a hexagonal coordinate system will naturally produce smoother paths.

In the first diagram, the end position is 10 units across and 10 units down relative to the start position. In the hexagonal version, the end position is still 10 units across, and is 9.5 units down.

Notice that we can’t create a perfect analog of the end position, or of the obstacle locations. In this particular example, the chosen path in the hexagonal version took 12 steps, as opposed to 17 in the square coordinate system.

This was no coincidence. A circle inscribed in a square occupies 79% of its area. A circle inscribed in a hexagon occupies 91% of its area. So on average we expect to represent an equivalent square grid with a hexagonal grid using 11% fewer cells.

However, since the hexagonal version requires checking 6 neighbor cells at each step, a minimum of 102 cells were examined in the hexagonal path, as opposed to a minimum of 72 cell examinations (at 4 examinations per cell) in the square version.

Game Programming Gems 7 chapter 1.5 “For Bees and Gamers: How to Handle Hexagonal Tiles” makes the claim that you gain performance by using hexagonal coordinates, because fewer cells are needed to represent the same data as rectangular cells. However, other constructs are rectangular, and need to be mapped to hexagonal coordinates. For example RAM is rectangular. The terrain quadtree subdivides into squares, and the world octree or GGR grid is square. Mapping between rectangular and hexagonal coordinate systems has an associated time cost, and having to check 6 directions instead of 4 in the path finding is going to cost a little bit more. Of course, it’s likely that hexagonal pathfinding is going to be faster than 8 directional rectangular pathfinding.

In the end I expect performance to be similar, though we gain the benefit of more natural looking paths, since hexagons have the same distance between the center and any adjacent cell (as opposed to squares, where you must travel 41% further to a diagonally placed cell).

One of the themes in this game is hexagonal tiling. I use them in the menu, and the skill tree (yet to be implemented). You’ll even find hexagonal tiling behind the main character of the game in the title banner of the website right now (look at the red background closely). That said, using hexagonal objects in the game world is something I’ve been considering for a while now. If used, hexagonal path finding would make a lot of sense.

Hexagons tend to represent organic shapes well (like islands and rocks), and squares tend to represent manmade shapes better (like city buildings or the rooms of a house).

Since most of the objects in this game will be organic in nature, hexagons will work out well. If you are building a post-apocalyptic zombie game that takes place in New York, then maybe not so much (streets and buildings are rectangular).

So in the next couple of days, I’ll be extending my hexagonal coordinate class (already used for the hexagonal menu system), and then modifying the path finding to use it.