Jump to content
  • Advertisement
Sign in to follow this  
dannyBlue

Unity Game Engine Design - Best way to handle multiple APIs and Targets?

This topic is 3672 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!