🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Hieroglyph 3.0

Published December 23, 2009
Advertisement

Hieroglyph 3.0

Introduction
I have officially started work on Hieroglyph 3.0. The project will have a much more focused set of objectives than my previous engine designs, but it will certainly reuse many components from versions 1 and 2. As I mentioned a couple posts ago, I'll be sharing the code base in some form along the way as the engine is built up. I still haven't decided exactly how I'll be sharing it (i.e. via codeplex or google code, or even as a download in this journal), so if anyone has any suggestions or desires, please post a comment below to let me know what works in your experience.

High Level Objectives
The project is going to be using a basic event system for communication between various engine components. The first major component to be implemented is a D3D11 based renderer. Previously I provided support for D3D9/10 renderers, but this time around I will stick to D3D11 since it supports downlevel hardware - this gives me a chance to support various hardware configurations with a single renderer which should make maintenance much easier.

The second major component to be added will be an improved scripting system. However, I will be adding the scripting support much deeper into the engine than I have previously. In Hieroglyph 2 (HG2) I manually wrote all of the script bindings - which was fine for small interfaces, but quickly grew tedious and error prone as the number of interfaces grew. For this project I'm going to integrate SWIG to automatically generate the scripting interfaces. Lua is my language of choice, so I'll start with that and perhaps add others later if it seems to make sense.

Additional components will include some entity system and scene management system. Basic input management will be handled more or less through the event system, and sound may be added later on too. I don't have much experience with networking, so that is an unlikely component that I would put at the bottom of the list...

Motivation
My motivation for making the engine available online is partially to spread the use of D3D11, since I think it is by far the best API available so far. The whole D3D10 thing was a big let down, but Microsoft really got it right with D3D11 and I am hoping the API doesn't suffer the same fate that D3D10 did. Most likely Windows 7 will help the cause, but probably hardware availability is going to be the biggest decider...

I'm also wanting to establish a code base that can be used for book samples or simple demos. After working with bare bones frameworks in the past, I really want to have my engine out there and available for anyone to see so that I can use it for book samples or anything else that needs some application developed for it. I've reinvented the wheel too many times lately and am ready to just use the code that I have already written!

With that said, the first check point is going to establish the basic windowing scheme, application objects, my math classes, the event manager, and a simple renderer interface. These will more or less be taken directly from my existing libraries, but I would like to document them better to clarify how they interact with one another. I'll likely make the first release after that is complete. This will probably make a good New Year's Resolution too - I'll have to think of some good milestones to plan on throughout the year...
Previous Entry Post from Germany
0 likes 2 comments

Comments

Saruman
I don't mean to detract from the positive points of D3D11 as the API is just amazing now, but I think there may be some adoption issues at least in the short term. We seem to have really hit a point where there is almost no reason for end-users to purchase better GPUs (I myself still only have 8800GTs in the Macs and 8800GTX cards in the PCs and I used to upgrade at least once a year!). It used to be an easy sell by showing massive FPS increases in existing games but since they doesn't really occur anymore the push to the latest hardware seems to have slowed.
December 23, 2009 01:44 PM
Jason Z
I agree completely - the only real driver is going to be features that aren't available in non-D3D11 hardware. The image quality will be increased by tessellation, but that isn't going to be obviously different to someone who isn't looking for it.

I think compute shaders are going to be the key - they will allow significant performance improvements in existing techniques. My GPG8 article addresses this regarding SSAO - there is potentially big speedups available, which I've seen first hand in hardware. I'm using a Radeon 5700 series card, and the performance is great on the compute shader. Compared to my GF8600M (in my laptop, but relevant nonetheless) it was approximately 300 times faster in compute shader performance... it should be compelling to see the new algorithms that can be performed with all the new functionality.
December 23, 2009 05:58 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement