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.