Setting up a Visual Studio project for OpenGL and OpenGL ES

Question

I want to make a small game with OpenGL and glew for desktop, android and web.

So far I know how to set up a project for opengl and a project for opengl es but I would like to have the game source code just once. For the web version I want to use emscripten.

Now my question is how do I set up the project for this? I thought about making three projects in one solution: One for OpenGL, one for OpenGL ES and one for the game itself. But should I include the OpenGL projects into the game project (and choose the correct one when initalizing/drawing)? Or should I include the game project into the OpenGL projects and have a single game object which returns all the objects to draw?

Or is this a bad approach and can be done better?

Answer 1

If you really want to target OpenGL, GLES and WebGL you should reuse as much code as possible but it's not a simple task. OpenGL and OpenGL ES are fairly similar. In fact a lot of the code can be reused between the two. WebGL isn't quite as easy as, you're right, you need to recompile with emscripten which is a whole separate task.

Your project organization can be really different but this is how I would organize it:

• Visual Studio Solution

  • Project for library code (compile this for GL, GLES or WebGL)

  • Game project (includes previous project, doesn't care about GL or GLES)

When compiling your library for different projects I recommend writing out a CMake project. It will take your 1 code base and setup a project based on what your targets are. That way you can avoid including GL libraries when all you need are GLES and visa versa. It will also make it easier to setup a VS project to target WebGL by automatically setting itself up with the emscripten compiler. Other people might be able to suggest different alternatives but CMake is very robust and widely used.

I'd suggest writing on your native platform with OpenGL first. After that targeting GLES is probably the easiest next step. This is going to require a fair amount of #ifdef macros. Whatever GL code will need to be GLES on other platforms will probably be wrapped like this:

#ifdef _ANDROID_
    // call GLES code
#else
    // Call GL code
#endif

This is a super simple example and you'll need to double check your platform macros but this is the general idea. You should wrap as much code as possible together in one #ifdef statement. In fact in my engine when I target separate platforms I usually end up having one header and then different implementation (.cpp) files for each platform. Each implementation gets wrapped in a macro that is specific for that platform. Obviously any non-platform specific code is kept in a generic, platform agnostic implementation file that has no macro shenanigans.

So that's the idea on handling GL and GLES. What about WebGL? To be fair WebGL isn't my specialty. However there are a lot of resources around about it because it's the hot new thing in browser-based game development. I've found some neat resources around the web like this:

http://blog.scottlogic.com/2014/03/12/native-code-emscripten-webgl-simmer-gently.html

That resource mostly uses emscripten at the command line in Linux or Mac OS. There IS of course a way to use emscripten with Visual Stuido: http://kripken.github.io/emscripten-site/docs/getting_started/getting_started_with_emscripten_and_vs2010.html

The trick with targeting WebGL is that you're mostly going to be writing more library code than client code. There is no main when dealing with WebGL as the entry point is the browser! Think of it more as writing a library that you'll access from Javascript. Of course there is an EMSCRIPTEN macro so you can #ifdef your code that needs to be just for emscripten. WebGL is just OpenGL code so you shouldn't need to use any GLES on this target.

Setting up your project is really up to you but I feel that it makes sense to organize your project while keeping all this in mind.