Elecorn ® : The Animated Coder

So I’ve decided to take a little diversion from work on Caster… again… and make a small multiplayer voxel based shooter.  The development name is Lexov, but it will not ship with that name.

I have this trailer for Lexaloffle’s game Voxatron to blame for this diversion:

Pretty cool, eh?  Get more details here: http://www.lexaloffle.com/voxatron.php

I’m targeting Xbox 360 via Xbox Indie Games.

Working on this game with C# on the 360 has some interesting problems that have been quite a bit of fun to try and overcome.  For example, say I have a 128 x 128 x 64 volume of voxels.  Simply walking across that volume of voxels requires over a million operations.  Doing one million operations alone in C# on the Xbox brings my frame rate down to less than 30 frames per second (just write a for loop and increment a local variable to see what I mean).

Here is an early version of Lexov where I am evaluating the voxel volume and adding the appropriate geometry for rendering:

Because of the performance issues with C# on the Xbox, I’ve had to get pretty creative in my approach.  I’ve started using approaches that reduce the number of operations that need to be done while favoring doing more work on the GPU (Graphics Processing Unit).  For example, in C# on the 360, it’s faster to draw an extra million triangles to save several thousand instructions per frame.

Currently, I’m using several dynamic vertex buffers and updating changes to the buffers as they happen in the game rather than evaluating the entire voxel volume each frame.

One important difference when using this approach is that I no longer have to render cubes on voxel boundaries.  This breaks some of the retro feel from being a true voxel volume, but allows for much smoother movement.

At this point I had to ask myself what it was that I really wanted to do with this game.  I decided that what I really wanted was a simple fun destructible environment game at 60 frames per second on the Xbox 360.  As cool as evaluating a single voxel volume would have been, it was secondary in importance.

Still, it’s hard to sacrifice the simplicity and beauty of the single voxel volume approach.  In the end, I’m actually very happy to have sub voxel movement in the game.

Here are some more videos of progress I’ve made.

And earlier today:

I’m going to try and keep an active blog on my Lexov’s progress.  I’ve been debating if the extra time to write blog posts is worth it when I could spend that time working on the game.  I’ve decided that if I get extra feedback and community support from doing the posts, then it will make for a better game.  Caster is a great example of this.  Caster would have been pretty lame and boring were it not for the amazing feedback I got while showing the game off to friends and colleagues.

More details on the plans for game play and design forth coming.

Thanks!

Lately I’ve taken a break from Caster and have been focusing my “side project” time on SmithGame.  SmithGame* is a game I’m making with my kids.

*Disclaimer: It was named by my kids and I did try to talk them into a better name but to no avail.

The game was greatly inspired by Katamari Damacy <Tangent>It’s a game my entire family including my wife adores and one of three reasons I purchased a PS2… the other two being Shadow of the Colossus and the numerous PS2 demo disks that used to come in Playstation magazine… good stuff… </Tangent>

Anyway, I didn’t plan to spend tons of time on this project, but there are some things that are worth the extra time spent.

For example, I spent the past four sittings implementing procedurally generated beveled cubes.

Was it worth it?  See for yourself:

Before Bevel

After Bevel

I think the amount of extra polish something like this gives the game is significant.  Plus it was a lot of fun figuring out a good way to handle the corners–their triangle arrangement etc.  Yes, I could have spent much less time making one in a modeling program… but that’s not as much fun so I didn’t.

It’s been a while since I’ve done much with 3D geometry and mesh manipulation and it felt really good to get back into it a bit.

Anyways, for those of you interested in looking at the very-slow-non-optimized-code-because-I-only-run-it-once-at-startup, you can download the code below (look at CustomModel):

ModelManager.cs

Nowadays everyone is looking to get that last bit of polish in the visual presentation of their game. One big thing of late is anti-aliasing the image to remove the “jaggies” that the polygones produce when rasterized to the screen:

For example consider this text:

See how much smoother the anti-aliased one looks!

This is typically an expensive process that is usually accomplished by rendering the image at twice (or more) its size and then shrinking it down and averaging the pixels together when the image is dumped to the screen. Since the fast “render to” memory is limited on many graphics cards, the image is often divided up into strips and each strip is rendered separately into the fast memory and then copied out to the more abundant not-so-fast memory. After each strip or “tile” has been rendered, they are combined together on the screen. This method is called “tiling” and is a common method for handling anti-aliasing.

Since it is expensive, it makes sense to try and do something cheaper to achieve the same anti-aliased look. This lead us at Hidden Path to investigate some other ideas and what we came up with is pretty slick.

The idea is basically the same as the old accumulation buffer method that was used for creating depth of field and anti-aliased images on older graphics hardware. You take a shot of your scene, shift it by less than a pixel, and take another shot. You do this as many times as you like to get more samples per pixel. The results are weighted and added together in the accumulation buffer which is then dumped to the screen. However, by itself this really doesn’t buy us much because we will still have to render the whole scene several times. Our answer is to spread the creation of the accumulation buffer over multiple frames. We only render one accumulation pass each frame and then combine that pass with prior passes when we display the results on the screen. We’re currently only using two passes and we have gotten some really nice results.

To clarify the above, this is our process:

1. SETUP: Draw the scene into textures A and B.
2. START:
3. Shift the camera projection matrix slightly (less than a pixel) in the positive diagonal direction.
4. Draw the scene into texture A.
5. Present textures A and B blended together at 50% each on the screen.
6. Shift the camera projection matrix slightly in the negative diagonal direction.
7. Draw the scene into texture B.
8. Present textures A and B blended together at 50% each on the screen.
9. REPEAT AT START

Here are some results from using it on my game Caster:

(Click on the images to see them at their full size)

And here is a section magnified (click to enlarge).

So now you might be saying “Ah, but texture B is lagging behind texture A. It will look blurry, you’ll see a double image”. And yes, that is correct. However, when the scene is still with no motion, we have perfect anti-aliasing. When there is very rapid motion or a low frame rate, you can detect blurring. However, this can also be looked at as a little motion blur of 1 frame for free (… okay, you’re probably not buying that last one)! Since Caster generally runs at a high frame rate (60 fps), this blurring is very small and makes sense when it is noticed like in the image below where the character is running around.

Now I haven’t tried it yet with 4 frames, but then you end up having 4 extra color buffers for your scene which can start getting just as expensive as tiling. Also, 1 frame of blur isn’t really much of an issue, but 4 frames might be a bit too much depending on what’s going on in the scene.

Weather or not this method is “free” depends on your setup. Some extra texture memory is required (or not if you don’t mind flicker or have a persistence of pixels on your screen… like old CRTs or televisions), to hold an extra color buffer of your scene. Either way, even if it’s not for free, it comes at a very low cost. Oh yeah, and no need for shaders for this so you can do this in fixed function too! So that means you can do this for… just about any 3D hardware out there right now!

This same technique of “temporal accumulation” can be applied to other things as well. For example, I’ve been using it in Caster for over 3 years now to blur my glow effect. Each frame I slightly change the position of where I render the glow effect on the screen and it is accumulated / blended in with all my prior renderings of the glow. I end up moving the glow texture in small circles to blur it out. The motion causes a shimmer of the glow and accumulating across all frames leaves motion trails. However, for my purposes this ends up being a feature that really like and want to keep.

So there you have it. Lesson learned: If something is very expensive to do in a frame and you can’t break it up into a separate threads, try thinking of ways to break it up across frames.

NOW GO AND GET SOME AA IN YOUR GAME! IT’S FREE CHEAP!

It only took about 30 minutes to add it to my game… like a quarter of the time it took me to write this article *sigh*.