Jump to content

  • Log In with Google      Sign In   
  • Create Account

Alex Hopkins' Journal

Creating Unity-like GameObjects in C#

Posted by , in C#, DirectX 11, Engine, Unity3D 28 August 2012 - - - - - - · 1,421 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,507 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#).

January 2017 »

151617 18 192021

Recent Comments