Codebase with multiple back-ends

Started by
4 comments, last by Laval B 9 years, 4 months ago

Hello

Different parts of my codebase will use various back-ends e.g. the rendering system can used Direct3D11 or OpenGL, the audio system can use OpenAL or FMOD, etc. Since The choice of those back-ends is made at compile time, the specific implementations have their own header and source files. There is also a set of headers that include the porper implementation depending on some defines. E.g. OpenalAudioDevice.h/.cpp implement the OpenAL version of the AudioDevice, FmodAudioDevice.h/cpp implement the FMOD version of the same class and the header AudioDevice.h includes the appropriate implementation depending on some defines.

The problem i have with such a setting is that i don't want to compile and link the implementations i don't use for a given configuration. I'm not sure how i could do that in a practical way.

I'm using Visual Studio 2013 and C++ for Windows implementation but i'm planning to have a version for OSX using Xcode. Also, some of these choices will be determine by the platform e.g. Windows will Direct3D only, OSX will be OpenGL only. FMOD or OpenAL on the other hand can be chosen on both platforms.

We think in generalities, but we live in details.
- Alfred North Whitehead
Advertisement
As you already have plans to go cross-platform I would recommend you to use something like CMake to manage your project files.
With CMake you manage your project in files called CMakeLists.txt which are then used to generate solution files for Visual Studio, Xcode and a couple of other IDEs that are also supported. Inside those files you can easily check for which platform your are going to compile and decide which code files to include in the build.

... use something like CMake to manage your project files.

I was planning to take a look at CMake. I've used it only to compile libraries so far and it worked great. For what i know, it generates an ide specific project/make file for you platform. It could probably generate project/make files for all the supported configurations or just thos you want (i guess). It looks like a great idea but is there good tools to manage the CMakeLists.txt file as you develop and add things on specific configurations ?

We think in generalities, but we live in details.
- Alfred North Whitehead

It looks like a great idea but is there good tools to manage the [background=#fafbfc]CMakeLists.txt file as you develop and add things on specific configurations ?[/background]


You can use basically every text editor. The part about adding files to the project isn't more than just adding the (relative) path of that file into a list of filepaths. You can even use wildcards to add multiple files at once.
Many editors and IDE do also provide syntax highlighting and even autocompletion for CMake. For Visual Studio there is a plugin available that adds this support.

I think a simple but somehow less manageable approach is just to use template and typedef:

template<class GraphicBackEnd, class VideoBackEnd>

class MyGameEngine {

public:

MyGameEngine() : graphic(new GraphicBackEnd), video(new VideoBackEnd) {}

private:

GraphicBackEnd* graphic;

VideoBackEnd* video;

};

And somewhere you do a typedef:

#ifdef _MSC_VER

typedef DXGraphicBackEnd MyGraphicBackEnd;

typedef WindowVideoBackEnd MyVideoBackEnd;
#elseif __GNUG__

typedef GNUGraphicBackEnd MyGraphicBackEnd;

typedef GNUVideoBackEnd MyVideoBackEnd;

# else

typedef OSXGraphicBackEnd MyGraphicBackEnd;

typedef OSXVideoBackEnd MyVideoBackEnd;

#endif

Finally in you game.cpp:

int main() {

MyGameEngine<MyGraphicBackEnd, MyVideoBackEnd> gameEngine;

...

}

I think a simple but somehow less manageable approach is just to use template and typedef:

In some way that's pretty much what i do ... I put the various implementations into different files (.h and .cpp) and i use include files that include the proper headers for the platform/configuration i want to compile. It's less messy that way because there isn't a bunch of conditional ifdef all over the place. It's not necessarily possible nor desirable to put all the code inline.

The real problem is not the code but the configurations and the project/make file that need to be setup on a per configuration and a per platform, basis. Remember that everything isn't just a matter of code, like linker setups and libraty paths.

We think in generalities, but we live in details.
- Alfred North Whitehead

This topic is closed to new replies.

Advertisement