• entries
7
5
• views
14746

Experiments in Game Engine development

## DirectX Cheat Sheet

I find it hard to visualise the flow and complete process required for a game loop using DirectX11 so to help myself I made myself a kind of cheat sheet. It's based on the presumption that most things are obvious and that just the order and steps required are to be detailed. The render calls made to the Model class don't include a Draw call to the GPU, as that is handled later by the Shader custom class.

HD Version: https://www.dropbox.com/s/7322x0i76sdnagm/DirectX11_Cheat_Sheet.png

## Creating Unity-like GameObjects in C#

One of the things I like most about Unity3D, apart from the rich editor environment, is the way the GameObject class is so rich. It provides access to many useful methods and exposes the things common to all objects within the game, such as position and rotation.

I wanted to emulate something similar for my C# DX11 engine, so I came up with this approach.

public abstract class GameObject{ public Vector3 Position; public Vector3 Rotation; public static int UUIDCount = 0; public static List GameObjects; public int UUID;}

This is a very stripped-bare version of the class but it demonstrates that all GameObjects will have a Position and Rotation property (along with associated methods).

The UUIDCount is a static int that is incremented whenever a new GameObject is instantiated. This is applied to the UUID field of that instance, giving each GameObject a unique identifier. (No account is currently made for destroyed objects freeing up UUIDs)

The instantiated GameObject also adds itself to a static list of GameObjects. This allows them to stay in scope even if they fall out of scope in the code that generated them, just like Unity. This list will later be iterated and each GameObject can have certain methods called, such as Update (to call Update on any attached scripts!). Any visual editors I make will also be able to list the active GameObjects (handy for debugging).

The Instantiate() method of the GameObject is static and templated, so it can be used by any derived class.

 public static T Instantiate(Vector3 Position, Vector3 Rotation) { var newGO = PInstantiate(); GameObject go = newGO as GameObject; go.TranslateTo(Position); go.RotateTo(Rotation); return newGO; } private static T PInstantiate() { var constructorInfo = typeof(T).GetConstructor(new Type[] { }); var newGameObject = (T)constructorInfo.Invoke(new object[] { }); return newGameObject; }

## Progress on "IOF" file format for OBJs

I have finished "spec 1" of my custom model format, IOF. It is intended to remove a lot of the complexity of OBJ files that I won't be using but also introduce important features that I feel OBJ files are missing.

I am splitting the work of this format up until smaller "specifications" so that I don't spend months on finishing the complete model format. The model file contains the spec version it was made for and so all files can be loaded for backwards compatibility. Unfortunately certain features will require a re-build of the IOF file from the original OBJ file.

For example, in "spec 2" I plan to support mesh groups and hierarchies. The former is partially encoded in the original OBJ file as separate group entries but the latter isn't supported at all. So a "spec 1" IOF file will have lost the group information, meaning it can't be upgraded to spec 2.

Currently, "spec 1" is very simple. Instead of the multiple separate index values for position,normal and texture coordinates in the OBJ file, the IOF file stores unique vertices and indexes to them as a whole. That means that more vertices generally will be output from the IOF than were stored in the OBJ but it also means that the Index into the vertices is compatible with OpenGL and DirectX indexed arrays.

To achieve this, an 8-tuple is used as the key in a Dictionary. This 8-tuple is merely the entire vertex information, comprising the position, normal and texture all together. This uniquely identifies each vertex. The 'faces' list is iterated through and every time, the dictionary of unique vertices is checked for that vertex. If the entry exists, the index is returned (the index is stored inside the vertex structure as Dictionary classes generally don't care about ordering) and stored in the Index list. If the entry doesn't exist, it simply creates a new vertex, fills out the index and adds it to the Dictionary before adding to the index list.

One of the features I wanted from the IOF model format was easy serialisation and deserialisation. Parsing through an OBJ file isn't hard, but its more cumbersome than it ought to be. Using a serialising system allows JSON objects to be used instead of plain-text line prefixes, making later deserialsing much easier.

The single down-side to this (that I can see) right now, is that the exported IOF files are in the order of 4 times the size of the original. This is a combination of the extra vertex information and also the names of the JSON fields being output for each vertex. This issue takes an ~90kb file up to ~250kb. While this isn't going to fill a hard-drive yet, I expect that IOF Spec 2 will have to support compression of some kind. A quick test shows that the 250kb IOF file is zip compressed down to ~23kb, a 90% saving in disk space. This must be optional though, as it will obviously put extra computation time on the deserialising later on.

## Moving from C++ to C# (and SharpDX)

I am switching my focus from C++ to C# for my landscape / environment engine, and switching from native DX to SharpDX.

There are many reasons for this, chief among them the speed at which you can achieve things in C#. I could continue my engine in C++ but the rate of progress wouldn't be great and given that this project will end up being a submission (hopefully) for a University project, I'd like to have time spare to write a dissertation! I appreciate there is a performance penalty for using managed code and calling DirectX but the engine I am writing will be portable to C++ as and when I have adequate time to do so.

One of the main areas of exploration for me here is to see how many of DirectX 11's new features can be applied simultaneously to achieve fast-performing rendering techniques for an open world environment. It may seem counter-intuitive then to use managed code to do this but as well as offering a practical investigation into how plausible game engines are in C# it also offers a chance to see whether a DirectX10 C++ engine written to be as close to a DirectX11 C# as possible competes. Obviously a scientific evaluation of DirectX 11 and 10 would pit them against each other on common ground, but I can say I'm ascertaining whether DirectX11's new features are enough to overcome certain limitations elsewhere (like using C#).

## OBJ files and indices

So whenever I read about how to import a model into your game, it tends to be followed by suggestions that the user go and read the appropriate file format specification. Then a few suggestions related to model asset libraries like ASSIMP. I have tried many of the libraries and always seemed to have one or two issues with them, none of which were fatal, all of which were annoying to debug.

For my project going forward, I will require many models to be imported and I'd like to minimise the pain of doing so further on. I wrote an OpenGL-based 'sniper' game for University that allowed the importing of hundreds of models at run-time and you could fly around the city "painting" models in and rotating them individually. There were a lot of models so I wrote a custom level format which housed a list of possible models and all the meta-data. This was in XML format.

Now, I'd like to go further and gain more control over the models themselves as well as the levels. I'm favouring JSON as a format for things as it seems to map slightly more to what I want to do, plus with serialisation tricks and some reflection, it might be possible to output replays/gamestates.

So, I'm writing a custom model format. It's going to be very basic and include only things such as

• Vertex positions,
• Normals
• Texture coordinates
• Lighting information per-vertex
• Maybe smoothing information
• Possibly hierarchical meshes
• Extra meta-data for run-time use

The first obstacle I found while running my OBJ importer is that the "Faces" index into separate position, normal and texture index arrays which isn't compatible with a DirectX index buffer. So, algorithmically parsing these index arrays must be done first. So, my output file format will be called, tentatively, "Indexed ObjectFile Format" or IOF. I'm half-way through writing a custom tool to convert between OBJ to IOF.

It's both fun and educational to write your own model formats and certainly good practice writing game tools such as model converters. Knowing your model format intimately can only be a good thing later on down the line when you wish to incorporate more advanced features like skinning, animation etc.

## DirectX Graphics Debugging

I once had to write a DirectX "scene" for a module at University. Back then, I wasn't aware of graphics debugging tools such as PIX or nSight. They are amazing! They allow you to capture a frame of your application and examine every tiny detail of the graphics pipeline.

You can see all of the DirectX calls and the render targets as they existed at each point in time. You can click on a single pixel and they can tell you which draw calls affected that pixel and how. Stepping through the shaders (black magic) allowed you to visually see the effects of the shader code and verify them with the output in the render targets. Contents of Vertex and Index buffers are easily displayed and even viewed in 3D preview.

So now, it's 2012 and Microsoft has caught up and released a suite of graphics debugging tools in their newest Visual Studio (11 / 2012). Having access to every little piece of the puzzle means people are able to diagnose bugs more quickly and in my experience, the graphical bugs are some of the hardest to understand.

Currently, nSight doesn't work with Visual Studio 2012. I wonder if they are going to update it or if they feel it's a fruitless endeavour, given Microsoft's new found efforts in this area.

## Start of my blogging on GameDev

Hello World! My name is Alex and this is my first post on my first blog on GameDev. I am currently studying for a Bsc. Hons in Computer Game Application Development at Abertay University, in Dundee, Scotland. I am about to enter my fourth year and decided that before I do, I'd start work on experimenting with the development of my own game engine.

I've never done this before, so I expect that I'll make plenty of mistakes along the way and will constantly fight myself to not try to over-optimise early-on. That kind of thing, I regularly read, is a bad thing. Optimise when there is a need.

I became interested in making a game engine when I first started to read about the advancements made possible in DirectX11. It seems quite amazing the things that are possible using DirectX and the care taken in it's development seem to suggest Microsoft cares about PC gaming, Although they have seemed to bin XNA and a lot of developers seem unhappy with the impending Windows 8 release.

So, I came to write this blog because I wanted a place to journal my thoughts and findings. After watching a video on YouTube about DirectX 11 Tessellation, I noticed the uploader had a blog here. I regularly visit this site, it's an amazing resource, but have never thought about blogging here.

It begins...