Orion Engine Blog

I always hate this time of the year, it seems to leave me in a depressed mood.  It’s when I have to give some of my money to the government.  Since I’m self-employed, I don’t get any money back — I didn’t pay anything quarterly last year.  Oh well, it should all be over soon.

I think I have all of the bugs worked out in the engine’s effect system!  I’m finished adding the code needed to get the sampler states and/or textures all working nicely.  Now, I just need to test it to see if everything works as expected.  I’ll need to start working on Orion Genesis again for a little while, so that it can preview all of the effects properly.  Also, I want to be able to edit all of the effect parameters in the Material Editor dialog.  Based on the annotations that are found, I should be able to automatically link up some of the parameters when an effect is loaded.  For example, an application (or the tool) could automatically apply the world, view and projection matrices, the current frame time, etc.  I hope to have this stuff all ready soon.

What I thought were bugs in the effect system ended up just being incomplete code in the .fx file importer that I use with Orion Genesis.  I think the importer can now handle nearly any syntax and/or any expression encountered, the parsing of the file is a lot better.  I can actually load and render some of my effects in the engine now!  However, there is still a problem with the rendering of some shaders.  I can’t quite put my finger on the exact problem yet.  Also, I don’t think all of the texture sampler states are properly handled yet.  I need to do a little more work in order to have texturing fully functional.  I’m going to keep pushing forward.

OK, so it may be April Fools Day — but there’s no fooling around going on here, only some serious coding!  I found the bug that was giving me problems in Orion Genesis.  It turned out to be an issue with the effect manager in the engine itself.  The effects were being prematurely unloaded.  I also discovered, and fixed, a bug that caused Orion Genesis to close unexpectedly when using the debug version of the Direct3D run-time.

I’m going to continue debugging the new effect system now.  I hope to have everything working well soon.  I had actually planned to have the effect system code finished by now.  I’ve been working on it for about 2 months.  However, it turned out to be way more complicated than I had originally planned.  Oh well, at least I’m getting closer now.

An important goal of the effect system in Orion Engine is that it can handle many types of shaders and/or effect files, while still remaining to be completely cross-platform.  So far, I believe I can handle HLSL and CgFX effect files quite well.  Another important goal of the effect system is to be able to use the same data files, no matter what shader model is present, and no matter what platform is used.  Basically, our effect files can contain various binary blobs of shader code which can be selected at run-time, based on the platform and/or rendering API that is being used.  For example, we could have D3D10 shaders that get selected if the current video driver is DirectX 10 and/or 11 based.  If we only have DirectX 9, then we can fallback to a technique that uses an earlier shader model.

I’ve been spending a lot of time trying to figure out the best way to abstract the shader management in my video driver, so that it works well with all of the existing API’s such as OpenGL and DirectX.  I think I am pretty much there now.  Unfortunately, there is not one single way that works best for all of the variations.  But I do think I have found a way that is going to work quite well.  The way shader constants are handled seems to have been the hardest part for me to figure out.  When Microsoft designed the new effect system in Direct3D 10, they changed a lot of things from the way Direct3D 9 used to work.  One big difference is, instead of having just one shader constant buffer, now you can have up to 14 of them bound to a single shader at any given time.  This did bring up a lot of issues that I didn’t really expect early on in the design process.  Hopefully, the tough choices I had to make all stand the test of time.

If Microsoft supported Direct3D 10 on Windows XP, then I’d just scrap my entire Direct3D 9 driver and move promptly and directly to version 10.  But no, I feel Microsoft is trying to keep this exclusive to Windows Vista only, thinking that people will upgrade their OS for that reason.  This really kind of pisses me off.  Well, it may be good for them, but this sucks for game developers.  Because now we are forced to maintain and support one additional, totally different, rendering API in our code — if we want to take full advantage of all the graphics capabilities on all of the dominant Windows platforms out there.  This is no easy job, since Direct 3D 10 is so darn much drastically different from Direct3D 9.

Let me tell you first hand, it’s freakin’ hard to keep up with all of the rapid changes in technology.

Rust never sleeps…

I’ve been working nearly every day for the last month on the engine’s effect based rendering subsystem.  I now see why my friend reached burnout while designing the system.  He sure puts a lot of deep thought into these types of things.  It took me a while to see the “big picture”.  Lucky for me I’ve had lots of time to invest in the code recently, without any distractions!  It’s proven to be a hard architecture to implement, however I still think it’s going to be a great architecture to use!  I’m sure it will prove to be very flexible and easy to use in the long run.  I’m actually getting pretty close to finishing it now.  All of the shader parameter management is taken care of now.  For example, all of the parameters can serialize themselves to and from disk, textures are automatically being loaded and created, etc.  I’ve been working on the mechanism that automatically links the parameter sources to their respective targets, such as individual device render states.  Beyond this, I just need to finish dealing with the placement of the shader constants in their respective registers, all in the correct order.  Then things will be in good shape to move forward with the game code again!

I’ve been extremely busy working on the effect file importers for the Orion Genesis world builder tool.  OK, maybe more on the HLSL (.fx file) importer, not so much on the CgFX (.cgfx file) importer.  Also, I’ve been ironing out how the effect parameter semantics and annotations will be handled within my architecture.  I’ll be following the SAS (Standard Annotations and Semantics) guidelines.  Anyway, I’m starting to see that I’m going to be spending quite a lot of time working on these importers.  But it will all be worth it.  Even though the effect system in the engine still needs more work, I can see the light at the end of the tunnel — and let me tell you, it sure is bright!

I’ve been working on the custom, cross-platform, Orion Engine effect system this week.  I’m trying to fill in all of the blanks that have been needing attention for quite a long time.  The effect system is used to drive our pixel shaders and vertex shaders.  It’s main responsibility is to seamlessly provide a fallback, if one particular rendering method is not supported by the hardware.  In other words, it will make the Orion Engine even more scalable; i.e. it will work great on old hardware, yet it can still look awesome on new hardware.  It also manages all of the render states that are needed to render a particular shader effect.

Anyway, it might be a little while before I get back to patching the game client again.  I need to finish the effect system first, and be done with it once and for all.  Once I finally have the effect system finished, I’ll be able to create even more stunning effects in the game!