Brainstorm
This will be my 5th major rewrite of the Brainstorm engine that I started writing way back in 2006. I intend to keep as many of the existing parts of the 4th generation engine as well as include a whole heap of new and improved features. And as with most projects I’m determined to do this one better than ever and include some things that I have missed in previous generations. However unlike previous re-writes this time I want to split the work up.
There are a couple of sub-projects that will make up some of the new re-write features and I will try and develop these in parallel and independently.
These sub-projects include:
- Moving from DirectX 10 to DirectX 11
- Switching over to XNAmath
- Animating .X files
- Parallelising the engine
- Incorporating PhysX 3.0 into the engine
- Moving to 64bit exe
More details on each of these sub-projects can be found further below or by following the links.
First step is to get the Visual Studio project set up correctly.
Moving from DirectX 10 to DirectX 11
Compared to the last re-write of moving from DirectX 9 to DirectX 10 this change from DirectX 10 to DirectX 11 should be much easier as most of the architecture has remained the same. The biggest challenge I think I will face will be the move to the new effects system in DirectX 11.
This is also a really good opportunity to try and develop my engine and graphics system to be more independent. Motivation includes the ability to use OpenGL for non windows based systems or make it easier to move to each new version of DirectX
Switching to XNA math
DirectX 11 has moved away from using the D3DX extension libraries that DirectX 9 and 10 relied on. This allows users to choose any exiting math library they wish or even develop their own.
I have chosen to go with XNA math rather than reinvent the wheel. This library takes advantage of the SIMD vector operations in modern processors to be lightning quick and certainly a lot faster than anything I could have written myself.
Conversion between D3DX and XNA types is well documented and fairly straight forward which is another motivation behind choosing XNA.
As Math and DirectX both make up the back bone of the engine this will need to be tackled pretty much in one go although it should be possible in the DirectX 10 engine to have both D3DXmath and XNAmath running together as I slowly switch over.
Animating .X files
Since the move to DirectX 10 the D3DX library no longer supports the .x file type natively. Losing all of the built in functions that allowed loading and animating of meshes in DirectX 9.
This unfortunately left me with a problem how did I upgrade my game engine to DirectX 10 when so much of it relied on animated .x files and the D3DX library to load them.
I intend to tackle the animated mesh problem by writing my own .x file loader and animator from scratch that works independently of graphics API so that it will work in either my existing DirectX 10/11 engine or any future engine for that matter.
There are several parts to successfully completing this project:
- Create and set up a testing environment
- Successfully load and parse all parts of an .x file
- Be able to load both ASCII and binary .x files
- Successfully load skinned and hierarchical models
- Animate skinned and hierarchical models
- Switch to XNA math instead of DirectX math to make the mesh loading completely API independent. Rendering will obviously still be API dependant.
Parallelising the Engine
Undoubtedly the most daunting of the tasks I am attempting to tackle in this engine re-write. Put simply my previous generation engine took no advantage of multi-threading what so ever and each next generation of chip continues to get more and more cores. With my goal of increasing the quality of the engine but still maintaining frame times of 16.5 milliseconds or less. (i.e. better than 60fps)
I want to take advantage of a number of different parallelising approaches to get the most out of it including data decomposition and task decomposition. Decisions of what to parralelise will be based on experiments to determine tasks that take the most amount of time to complete per frame. Then the most suitable and effective parallelising technique will be used.
I want to build a testing harness that will accurately measure the time a section of code takes to execute and ensure a section of code can indeed be improved by taking advantage of multi-threading, every millisecond counts when you’re trying to improve you’re frame rate and I don’t want to spend hours on a piece of code that is not worth parallelising.
Incorporating Nvidia PhysX 3.0
Just like me Nvidia has gone through a complete rewrite of there PhysX engine. It has completely changed from the ground up and as such all of my existing physX code amount to about nothing. Not that thtat's too big of a concern my physics code was pretty crap and not integrated into Brainstorm effectively so its not really a great loss.
Just like me Nvidia has gone through a complete rewrite of there PhysX engine. It has completely changed from the ground up and as such all of my existing physX code amount to about nothing. Not that thtat's too big of a concern my physics code was pretty crap and not integrated into Brainstorm effectively so its not really a great loss.
