Over the past few months I have been weeding out the fixed function pipeline. Last month all that remained in the FFP was rendering fonts and 2D images. I have now written shaders to handle that type of drawing and the FFP has been completely replaced by the Programmable Pipeline. This is a great improvement because it does away with the need to worry about quite a few render states (such as lighting). It also means that all drawing is done in the same way, so there is less need for branching in the rendering code.

One thing that I haven’t been happy with was the audio system in the game. Originally I had decided to use OpenAL. In part because I thought it was going to be as big as OpenGL (not that OpenGL is that big, but it least it is still somewhat backed by NVIDIA and AMD). I also thought it would be more portable. I realize now it’s not. I’m fairly certain there is no PS3 support for OpenAL and I think the 360 support is limited. The PC version is really bad as it is. So I cut out the OpenAL support and rewrote the audio engine in XAudio2. This seemed to be Microsoft’s preferred audio platform for PC and 360.

I’ll tell you this. After dealing with it for two days I’m already very happy with it, and already have about 90% of the functionality in the Emergence engine that I had with the OpenAL engine. By tomorrow it will have exceeded it. XAudio2 actually get’s you closer to the hardware (actually, lack of hardware, since all the mixing is done in software), but it get’s you closer to the software to have more control over it, with easy control over every channel. Further since it is just just software, buffers are literally chunks of memory, I mean direct memory. You allocate memory, that’s your buffer, none of this weird creation of buffers and what-not. You have memory, you have a buffer, and you can feed that buffer to as many voices as you want.

Overall I’m a lot happier with XAudio2. I didn’t even know it existed until yesterday, to be perfectly honest. I actually opened up the DirectX documentation because I thought I needed to refresh my memory on DirectSound, and I was like, What’s this? XAudio2, never heard of it. Well I quickly discovered what it was and how to use it. Really the fundamentals aren’t that different from any other software or hardware mixer, but the implementation seems to be quite good. Plus it is 360 and PC. From a developer standpoint, and some of my colleagues agree, hardware mixing is dead. Processors are so powerful that you can easily get any kind of audio effects that you want. And at this point we have so much memory that special audio effects can be pre-recorded anyway. Still, I’m sure that someone out there is going to argue that hardware will always be better. Well I respond by saying this. A quad core processor has enough cores to take care of any hardware argument. Software runs on hardware, after all.

I have mentioned that until I can really start getting content into the game there isn’t that much to do with the game engine. Really to make a game with it, most of the programming necessary would be to write AI and scripting. Without designers and artists there isn’t much AI to program, so I haven’t been doing much with the game engine as of recent.

I did go ahead and rewrite a lot of the code. Well, not completely rewrote it, but I’m trying to make many of the modules within the game more independent of each other, and more object oriented.

Get this, I have a string class for the game, which is used for basic string manipulation, it was depending on the file class, which is used for opening and closing files, which in turn was dependent on the string class. I’m working hard to get rid of all such dependencies.

The other independence I worked on is with the Renderer. I would very much like to have the Renderer 100% independent from all Emergence tech except for the IRenderer interface. Currently it is still dependent upon global variables for it’s internal settings (such as screen width, height, etc). My ultimate goal is to have it so that the Renderer could be contained in a separate DLL, kind of the way Unreal technology did things. That way I could create new renderers of different types (DX11, for instance), and even more importantly, port the renderer to other platforms. The D3D renderer that I’ve currently implemented is dependent upon Windows, so I’m trying to abstract it as much as possible. It won’t be hard to port to the 360 renderer, and as for Playstation, I really have no idea, since I haven’t dealt with PS3 rendering tech at all.

The newest feature implemented in the game is normal mapping (a form of bump mapping). This is a method for creating more detail in a rendered mesh without actually creating more geometry.

In the early days of computer graphics, lighting wasn’t calculated at all, later, lighting was calculated on a per vertex basis, today, graphics cards are capable of calculating lighting on a per pixel basis, and normal mapping is one form of doing that.

Lighting can be computing using the normal vector of a surface, in combination with the direction that the light is coming in. On a per vertex basis, this is a fairly easy computation since vertices typically have a normal attached to them. On a per pixel basis this is a little more difficult, since each pixel doesn’t have a vertex attached to it, and that is where the normal map comes in. The normal map is loaded as if it were a texture, but each pixel in the texture is treated as if it were a normal.

An example of a normal map.

From there is seems like it would be easy to calculate lighting based on that. Wrong. Consider that a texture is actually wrapped around a mesh. So each normal in the texture isn’t actually the normal of the pixel we are rendering. It’s a normal that doesn’t take any regard to the orientation of the vertex.

Therein is the problem with normal mapping. It is necessary to transform the per-pixel normal into the space of the vertex. Or, alternatively, transform the direction of the light into the space of the vertex, which is a more useful computation.

Transforming a light vector requires an orthogonal transformation into the vector’s tangent space. And for this to be accomplished a tangent vector must be computed for each vertex. The tangent vector depends upon the normal of the vertex, in combination with the orientation of the texture about that vertex. It’s a lot of linear algebra, and theory that I don’t want to explain, but after programming a complex algorithm, the tangent vector is now computed in the Emergence engine, which in turn can be used for per pixel lighting in a pixel shader. The result is thus,

Note that the spherical surface on this gun is not dependent upon mesh geometry, but rather it is depended upon the normal map (as seen above). The results look much more dramatic in the actual engine where you can move through different light sources.

One of the most difficult things to implement in a game engine is shadows. A shadow itself isn’t difficult to implement. The difficult part is getting shadows to work with the game engine itself. Important questions are how do you decide which direction a shadow get’s cast, what happens as an entity moves through different light sources, how do you determine shadow visibility.

I have just implemented volumetric shadows in my game engine. This is a process of creating a shadow volume and then everything inside that volume gets darkened by the shadow. This technique requires that any mesh that is to cast a shadow, but be a closed mesh, which basically means you can fill the mesh up with water, and it won’t spill out. Most of the meshes I developed appeared to be closed, but they had little leaks, and so when I first tried to implement shadows I ran into all sorts of problems. I knew exactly why the problems appeared, but I didn’t want to deal with modifying the meshes since I’m not an artist.

I ultimately decided to modify the entity definition file format with a new tag <shadow>. This new tags allows for a special mesh to be specified, the shadow mesh, then the entity will cast a shadow of the shadow mesh. Ideally the shadow mesh should resembled the actual mesh, because this is the mesh that will be used to cast the shadow. In that way a separate, fully closed mesh, can be specified as a shadow. This mesh can be simpler than the original, but it should have the same bone structure so that it can be animated properly.

With this new shadow mesh, I was able to cast shadows without problems. However, that’s where I ran into the more important question of, what direction should a shadow be cast? I kind of figured that since I was using a four closest lights lighting model for lighting a mesh, that I could used the same data from that to decide which direction the shadow should be cast. The first thing I experimented with, was using the closest light to cast a shadow. This of course had the problem of a shadow suddenly jumping around when the closest light changed.

I realized I needed to do something akin to what I was doing with lighting, and blend the closest lights all together. To create one faux light source, and cast the shadow from there. This was accomplished by averaging out each light source according to the same value used for the intensity of the light in the lighting calculation. This seemed to work out okay, and prevented the shadow from jumping around, except when then entity completely walked out of any light sources, then the shadow would still be cast, but in a direction that wasn’t important. This was just as bad as the shadow jumping around.

I finally decided that for the shadows to look more natural, I would need to change the darkness of the shadow depending on the overall intensity of the light. That way if an entity was far away from a light source, the shadow would be dim, and if it was out of range it wouldn’t even cast a shadow. This required some reworking as to how I was rendering shadows, as each shadow could now have it’s own intensity. Ultimately everything work out, and it looks fairly natural.

Obviously, shadows don’t get less intense in real life, but consider real life. If a single light source is blocked off, a sharp shadow is cast, but then as you move further away from the light source, the shadow does appear to get lighter, this is because there is more light to bounce around the various reflective surfaces in an environment, so ultimately the fading shadow method isn’t too unbelievable.

Click on the screenshots below to enlarge them.

You might notice that the above shadows don’t really look like shadows of the Hell Trooper, it’s because they’re not, they’re shadows of this guy. He’s the shadow mesh. In a production game you’d want a more accurate representation.