Game Engine Design - Best way to handle multiple APIs and Targets?
Author
I have been pondering on this question for quite some time, and have reached no decisive conclusion on my own, so it's probably best to reach out to the community with this query.
Having to deal with multiple targets and APIs is a reality that is only going to get more and more aggravated, we have to target multiple hardware levels that are capable of running multiple APIs (DX9, DX10, DX11, OpenGL 2.x, OpenGL 3.x, OpenGLES 2.x), and we also have to handle other types of platform like MIDs and other mobile devices, all in C/C++ code.
What do you think is the best way to handle this diversity of configurations?
In principle i can divide the problem in two areas build and preprocessing.
Should developers handle different versions of the same engine in multiple development branches (say DX9, DX10, DX11, OpenGL 2.x, OpenGL 3.x, OpenGLES 2.x). Meaning that we have redundancy of code and our maintenance job is multiplied by the amount of platforms that we want to target.
Or should developers use the preprocessor to handle this issue, creating complex scripts that are also very hard to maintain but giving us one entry point.
Is complexity in either levels inevitable?
Let's hypothetically consider this as a job interview question: As a lead game engine programmer how would you handle/target multiple APIs, what technique would you use for your development efforts?
Quote:Original post by dannyBlue
Having to deal with multiple targets and APIs is a reality that is only going to get more and more aggravated, we have to target multiple hardware levels that are capable of running multiple APIs (DX9, DX10, DX11, OpenGL 2.x, OpenGL 3.x, OpenGLES 2.x), and we also have to handle other types of platform like MIDs and other mobile devices, all in C/C++ code.
C or C++?
Quote:Is complexity in either levels inevitable?
It's not inevitable. All you need to do is separate your platform-dependent code from your platform-independent code, connecting the two using a clean interface designed for performance and simplicity.
Then, implement the different versions of your platform-dependent code respecting that interface, and implement your unique version of your platform-independent code on top of that interface.
This way, the different versions of the platform-dependent code are built independently without a complex build system, and there is no redundancy.
Author
Both C and C++.
Yes that is a good theory but in practice things never really work out in a clean solution.
Add to the lot the need to compile different version of shaders and different shader formats for binary shaders. What toolchain would you use to handle this?
Yes that is a good theory but in practice things never really work out in a clean solution.
Add to the lot the need to compile different version of shaders and different shader formats for binary shaders. What toolchain would you use to handle this?
Quote:Original post by dannyBlue
Yes that is a good theory but in practice things never really work out in a clean solution.
What, precisely, do you have in mind? Usually, if you don't manage to get a clean solution working, it means you're not thinking at a level that is high enough (because your abstraction fails to hide the differences between the platforms).
Quote:Add to the lot the need to compile different version of shaders and different shader formats for binary shaders. What toolchain would you use to handle this?
Depends. Some engines use a cross-platform specification language that avoids the issue of shader languages. Failing that, I would provide different assets for different platforms (including the shaders) beause unlike the Model, the View is too dependent on the platform to be abstracted.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement