# Setting up a Visual Studio project for OpenGL and OpenGL ES

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?

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.

• First of all: Thank you for such a detailed answer! I didn't know WebGL is that much of an effort. It sounded easy in the articles I've read. Is it possible to ignore it for now and port the game later or is it more work to do so? The project organization looks good, but I didn't quite understand the benefits of CMake. I am not familiar with it but wouldn't preprocessor statements be enough to distinguish the platforms? Or do I need CMake because of the different project settings (like which dlls to use)? – Superwayne Aug 10 '15 at 19:06
• CMake is used to determine which dependencies to build against depending on the platform. WebGL isn't HARD it's just going to be a very different project structure to work against. – Honeybunch Aug 10 '15 at 19:12
• Can you recommend a link/tutorial for this use of CMake? I don't know what to search for as this seems to exceed basic tutorials of CMake. – Superwayne Aug 10 '15 at 20:26
• CMake is a bit of a beast. Start off small and build off of it: cmake.org/cmake-tutorial. What I do in my engine is I have a couple flags, GL_SUPPORT and D3D_SUPPORT. If one of them is set, it builds the engine with GL or D3D. If both are set it just uses GL (only on windows of course). What you might do is have a boolean like WEBGL and if that's set to true then CMake should target emscripten instead of g++/clang/msvc – Honeybunch Aug 10 '15 at 20:50
• Okay I tried it for some hours now but with no success. First I tried the cmake tutorial but I didn't understand how that can help me in visual studio. Then I tried this one: cognitivewaves.wordpress.com/cmake-and-visual-studio but all it seems to do is to create a visual studio project? But I already got one I would like to use. Also I don't understand how to create an android project with cmake. There are only executables and libraries? – Superwayne Aug 11 '15 at 1:57