While I haven’t blogged about my 3D engine developments in a long time, I haven’t been completely idle in that regard. The OpenGL engine that I made for the BHM sample was very useful in the sense that I started with a clean slate again, and I had to work to an actual release of the source code, so I wanted to make things clean and robust. There has been some cross-pollination between the OpenGL and Direct3D codebases. I have adopted the more rigorous reference-counting from the OpenGL code into the Direct3D code (which is ironic in a way, since Direct3D itself is reference-counted, while OpenGL is not. I just didn’t apply reference counting to my own classes up to now).
I have also made the base classes and interfaces more similar between the Direct3D and OpenGL frameworks. They are not yet at the point where they can be fully exchanged, but the differences have become quite superficial in most cases. One of the biggest problems is that OpenGL and Direct3D don’t use the same shader language. So building an engine that is completely API-agnostic is very difficult. It will require some kind of shader translation step. Even multi-API engines such as Ogre don’t support something like that, so you end up having to rewrite your shaders for the various APIs (and in the case of OpenGL, you also have to make an ARB assembly program version and a GLSL version, if you want to support pre-OpenGL 2.0 hardware, such as Intel DX9-class IGPs). I don’t feel like going down that road anytime soon.
What I do feel like, is playing with realtime controllers on the engine. I have implemented a simple DirectShow-based video-streaming texture, and I’m going to attach that to some kind of GUI, so the video can be positioned in realtime. I also want realtime positioning of objects and such.
Currently I’m working on that with a friend of mine. We’re making the GUI in C#. I had already separated my engine from the main application when I put the engine inside an MFC DLL. I decided to take it one step further, and put the engine itself in a static library, completely independent of MFC or any other kind of windowing API, and then building the MFC DLL around this library. This turned out to be very easy, since I had already separated the engine quite nicely in the earlier DLL process.
Now that I had an independent static engine library, I figured it wouldn’t be that difficult to wrap it in a managed C++ DLL instead of MFC, and then hosting it directly in a WinForm of a C# application. As a result, my code can now run 100% MFC-free. The performance inside the WinForm is also really good, actually slightly faster than the MFC application.
I then started to experiment with wrapping C# objects inside native C++ objects, so that the engine itself could also interact with C# code directly, rather than the engine just being hosted in C# code, but essentially being one-way traffic. The gcroot<> template in managed C++ turned out to be a really nice way to communicate with .NET objects from within native C++. Much simpler than the alternative of hosting your .NET objects inside a COM context.
With the engine cleaned up and refactored quite heavily, and the interoperation with C# working nicely, I will now concentrate mostly on building new functionality, for all sorts of effects and realtime interaction. If there is some time left, I also want to do a remake of Croissant 9 with the new engine. I had already built a basic scene player for the Croissant 9 content, for both OpenGL and Direct3D, since I figured it would be a good way to test the current framework with some actual content, and iron out some bugs. Currently the scenes can be played back from the original XML script, and the original music can be replayed. It is just lacking the effects of the original (blur filter, particles, metaballs, bumpmapping, overlays).
I hope to have some actual visuals to show soon.