OsirisEngine planned features

Share with us how are you using the powerrrr of the force

Moderator: Alain

Re: OsirisEngine planned features

Postby aqnuep » Thu Dec 10, 2009 1:31 pm

Stucuk wrote:My only suggestion would be to build in the ability to scale. But i doubt you would do it. Scalable engines mean a wider audience. But since you are going to make it using OpenGL3 then its not likley to be able to be scalable.

If you think about platform scalability, that possibly won't be an issue.

Carli wrote:When you separate the logic and the graphics well, it should be no problem to make a compatibility mode where you can play the game content without having full graphic power.

It is very very separated, they work at different layers of the engine. It's not the case that it wouldn't be possible to add a renderer which works with pre-OpenGL3 stuff, just I don't have the time and desire to do that.

Stucuk wrote:For true scalability an engine needs to have a shader system designed so that it's shaders can have definable areas which are removed/added to the shader thats passed to OpenGL, the definable areas would mainly be like {ifdef Shader4} bla {endif}. That then allows the engine to handle any Shader version. Which also makes it better when new shader versions come out as they can be supported without raising the minimum Shader version requirement. The ability to use either OpenGL2 on pc's that don't support OpenGL3 would also be needed. Based on Stu's 5 year rule Geforce 7's should still be around in 2012, while a definate minority by then it would still be alot of people. But it ultimately depends on when the engine is finished by.

The key idea behind why I use OpenGL3+ it's not related to shaders at all. Making shader backward compatibility even for cards having very limited shader capabilities like Radeon 8500 and GeForce 3 is not the main problem.
The reason behind my decision is that OpenGL3 has a totally buffer oriented terminology and design. That, and some other GL3 features makes it possible to create a rendering engine which is amazingly fast (I can say that's even faster than most commercial engines).
If I would like to create a pre-GL3 rendering path I would make it totally separated from the GL3 one for two reasons:
- The game engine supports that as almost all the sub-systems and components are pluggable, so it's easy to switch between them. That's one thing why I used the Model-View-Controller design pattern. It's I think quite unusual that someone uses MVC in a game engine as it's usually used by web applications. I don't even think that there are any game engines that uses MVC as the main building block.
- I don't want to mess up the GL3 renderer with conditional parts for pre-GL3 stuff, because that'll result in unmaintainable code and even worse performance. GL3 is quite a forward looking API, so the introduction of new features written against GL3 (like new GLSL versions) won't cause me headaches because they all fit in the design goals of the original engine. However, this is not the case for pre-GL3 stuff.
aqnuep
 
Posts: 97
Joined: Sat Dec 22, 2007 4:14 pm

Re: OsirisEngine planned features

Postby aqnuep » Wed Dec 30, 2009 9:55 am

Due to the many requests related to usage scalability I've changed my mind and the engine will support every graphics accelerator, even it would be possible to use on platforms without any such hardware acceleration.
I've altered my decision because I've figured out that it wouldn't be that hard to add backward compatibility even if the structure of the engine reflects latest graphics API architecture.
As such, the engine will have three built-in renderers:

1. Compatibility renderer
- Requirements: OpenGL 1.1 (OpenGL 1.3 recommended, OpenGL 1.4 optimally)
- Optimized for low-end graphics accelerators (Intel cards, NVIDIA GeForce4 and earlier, ATI Radeon 9200 and earlier, etc.)
- Per-vertex lighting using fixed function pipeline
- Limited support for light maps, bump mapping and reflection via multitexturing or multipass rendering
- Unlimited number of light sources (however, performance can be a concern)
- Very limited hard shadow rendering (planar shadows or shadow maps if supported)

2. Next-step renderer
- Requirements: OpenGL 2.0 (OpenGL 2.1 optimally)
- Optimized for vector based GPU architecture (NVIDIA GeForce FX - GeForce 7000 series, ATI Radeon 9500 - Radeon X1000 series)
- Forward renderer with Shader Model 2.0 based per-pixel lighting
- Support for light maps, bump mapping, reflection and other effects
- Unlimited number of light sources (however, performance can be a concern)
- Hard shadow rendering

3. Core renderer
- Requirements: OpenGL 3.2
- Optimized for super-scalar GPU architecture (NVIDIA GeForce 8000 series and later, ATI Radeon HD series and later)
- Deferred renderer with Shader Model 4.0 based per-pixel lighting
- Full support for every shading model and effects
- Unlimited number of light sources with great efficiency
- Soft shadow rendering

Each renderer has it's performance and image quality characteristics because of the rendering method used. However, this does not mean that the compatibility renderer cannot use vertex shaders to speed up skeletal animation if vertex shaders are available. Also it can use e.g. instancing as well if the required extension is available, as well as all other hardware accelerated features.
Actually the selected renderer limits only the lighting characteristics of the rendering, but every graphics resource is used in the best way as possible with any of the renderers.

Also important, that a limited version of the engine featuring only the compatibility renderer will be available totally free of charge. As the programming interface of the whole engine (no matter which renderer is used) is unified*, this means that one can master the usage of the engine even with the free version of the engine. This can be useful to increase the target audience.
(* the interface is the same, however, obviously not all options affect the rendering of all the engines, e.g. those effects which are available only in the core renderer will be silently ignored by the compatibility renderer)

This content change, however, does severely affect the road-map of the engine. I'm not pretty sure about the planned release dates, but it seams that the first version of the engine which supports only the compatibility renderer yet, will come out earlier than the planned release date, but the core renderer will be delayed because of the additional development effort required.

I would be interested how this content change affects your vision about the engine. Also if somebody is interested in the planned road-map, then I'll post it as soon as it will be available.
aqnuep
 
Posts: 97
Joined: Sat Dec 22, 2007 4:14 pm

Re: OsirisEngine planned features

Postby Stucuk » Thu Dec 31, 2009 12:00 am

Sounds like a good decision. Intel cards for example are in alot of laptops and there completely c.rap cards, so if people can make games that work on them it would boost your "clients" target audience.
User avatar
Stucuk
 
Posts: 801
Joined: Sat Mar 12, 2005 3:54 pm
Location: Scotland

Previous

Return to User Gallery

Who is online

Users browsing this forum: No registered users and 11 guests