Jump to content

  • Log In with Google      Sign In   
  • Create Account

Alex Hopkins' Journal

DirectX Cheat Sheet

Posted by , in DirectX 11 29 August 2012 - - - - - - · 2,961 views

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

Attached Image

Creating Unity-like GameObjects in C#

Posted by , in C#, DirectX 11, Engine, Unity3D 28 August 2012 - - - - - - · 1,422 views
unity, unity3d, c#, game, object and 2 more...
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<GameObject> 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<T>(Vector3 Position, Vector3 Rotation)
			var newGO = PInstantiate<T>();
			GameObject go = newGO as GameObject;
			return newGO;
		private static T PInstantiate<T>()
			var constructorInfo = typeof(T).GetConstructor(new Type[] { });
			var newGameObject = (T)constructorInfo.Invoke(new object[] { });
			return newGameObject;

Progress on "IOF" file format for OBJs

Posted by , in IOF, Uncategorized, C#, DirectX 11, Engine 28 August 2012 - - - - - - · 708 views
obj, wavefront, directx, opengl and 11 more...
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.

Attached Image

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

Posted by , in Uncategorized, C#, DirectX 11, Engine 27 August 2012 - - - - - - · 1,510 views
sharpdx, c#, directx, native and 7 more...
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#).

DirectX Graphics Debugging

Posted by , in Uncategorized, DirectX 11, Visual Studio 23 August 2012 - - - - - - · 607 views
DirectX 11, DirectX and 9 more...
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.

Attached Image

January 2017 »

1516171819 20 21

Recent Comments