Renderer DesignAfter approximately 4 years of development, the new Hieroglyph engine is finally being developed. Of course the heart of any game engine (or multimedia system as I'm calling it) is the rendering system, since that is what provides the most immediate feedback to the user. The sound system is a close second, but you can definitely imagine playing a game without sound - and definitely can not imagine playing a game without visuals...

So when I sit down to figure out how I want to have the renderer designed, I began drawing ideas from two trains of thought:

1. Past experience with Hieroglyph 1: Over the long development cycle of the first version of the engine, I managed to implement many of the features that wanted in a renderer. It is relatively easy to use, very easy to maintain or add new rendering features to, plus it is my own creation so I know how it works inside and out.

2. Past experience with Hieroglyph 1: No this isn't a typo - after developing around 10 applications with the old engine, I have realized that there are certain things that my renderer couldn't do, but would be nice to have. However, without changing the fundamental design of the renderer it would be difficult to modify the old engine to achieve the new features. Thus the overall design intention is to combine the nice features of the old engine with the desired added features.

Which API to use...One of the biggest problems with the old renderer that I wanted to tackle was to have the ability to use multiple APIs. I am certainly not the type to get involved in one of those DX vs. OGL debates, and its because they are both good in certain areas and worse in others. I am more fluent in DX9 than OGL, but have been learning quite a bit of OGL along the way. Also, looking at my past journal entries, I have now learned how to do limited software rendering as well. Plus there is always DX10 to eventually migrate to. So that leaves four renderer types:

1. DX9
2. DX10
3. OpenGL
4. Software

One thing that I have noticed about multiple API engines in the past is that they try to homogenize the capabilities of all of them to one feature set. I think that is a mistake - as mentioned above, each type has good points and bad points. The trick is to expose each of their benefits while maintaining a common theme among them.

So there will be a low common denominator for basic rendering functionality. This includes basic drawing functions, color controls and things like that. I suppose you could specify the basic functionality as a subset of the fixed function pipeline. Then each renderer is free to add whatever interface is most appropriate. For example, it would be nice to have access to geometry shaders in DX10, but I won't make that a common theme with a software renderer.

So that's the overall motivation for the design. Next time I'll likely talk about more specific implementation details.