• entries
    316
  • comments
    485
  • views
    322099

Hieroglyph 2 Design Notes

Sign in to follow this  
Jason Z

163 views

Renderer Design
After 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.
Sign in to follow this  


3 Comments


Recommended Comments

Why bother with a software renderer? Take the time you'd waste on that and spend it on a GL3 renderer instead.

Or, better yet, since you're not using D3D10-exclusive features, scrap all of them, do a GL2 implementation and spend that time on your game.

Share this comment


Link to comment
Just in the interest of being difficult... [razz]
Quote:
you can definitely imagine playing a game without sound - and definitely can not imagine playing a game without visuals...
I'm not so sure... blindfolded with a high quality surround sound system and a game fully utilizing 3D audio could be quite an interesting experiment. I reckon it'd be much more playable than most people realise!


Why not silo the various graphics features. A bit like D3D9 has - FF, SM1, SM2, SM3.

Just create a common interface and then define something like "no shaders", "basic shaders" and "advanced shaders" and you can then map this common functionality accordingly. If you provide a standard interface into the API's (e.g. all procedural or all object oriented) then the rest should be straight forward.

Jack

Share this comment


Link to comment
Quote:
Why bother with a software renderer? Take the time you'd waste on that and spend it on a GL3 renderer instead.

Or, better yet, since you're not using D3D10-exclusive features, scrap all of them, do a GL2 implementation and spend that time on your game.
The software renderer is more or less already implemented. All of the hard work is done, now I just need to fit it to the interface. The software renderer is actually not intended to do the full blown rasterization though - I want it to be available at the same time as the other hardware renderer to try out fancy hybrid rendering techniques. There are enough things that the APIs don't let you do to warrant doing some things on your own...

But I think you missed the fact that I will be allowing each renderer to have special features - so that DX10 and OGL3 can use the latest and greatest features while a DX9 engine still has the same basic interface as the other two even though it doesn't support geometry shaders. I think it will become more clear as I go through the design.
Quote:
Why not silo the various graphics features. A bit like D3D9 has - FF, SM1, SM2, SM3.

Just create a common interface and then define something like "no shaders", "basic shaders" and "advanced shaders" and you can then map this common functionality accordingly.
This is actually going to be done through my 'effect' system - which will be similar to the DX effect system. It should be handled through the data driven material system rather than put additional complexity into the renderer to handle fallbacks and all of that.
Quote:
If you provide a standard interface into the API's (e.g. all procedural or all object oriented) then the rest should be straight forward.
You make it sound so easy... [totally]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now