CMake, macOS and Linux support

[fwcd]

I have ported the repository to the cross-platform CMake build system and tested it on macOS. It should run on Linux too though, since Clang and Make are both not unique to macOS.

This branch embeds the resources into the executable by generating a huge C source file through CMake containing the binary resources as constants:

Since my current development machine did not support OpenGL 4, I successfully backported the shaders to OpenGL <2 and added a "potato-quality" resolution (320x180) too, though not in this branch: https://github.com/fwcd/MarbleMarcher/tree/shader-backport

Screenshot of the game successfully running on macOS:

[clementperon]

Hi,

On Linux Ubuntu with i7-8550U apt-get install libeigen3-dev libsfml-dev libboost-dev libboost-system-dev libboost-filesystem-dev

But unfortunatly doesn't work with my graphics stack I think

./MarbleMarcher 
Failed to compile vertex shader:
0:17(10): error: GLSL 4.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES

Failed to compile vertex shader

glxinfo | grep "OpenGL"
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

[fwcd]

@clementperon For this exact reason I have created the shader-backport branch: https://github.com/fwcd/MarbleMarcher/tree/shader-backport

Try running git checkout shader-backport and rebuilding from there.

[HackerPoet]

Thanks for the CMake port! I will look this over tonight to make sure it's still compatible with MSVC. I worry that embedding really large binary resources into an array might cause some compiler hickups or slowdowns, but if it also works in clang and gcc, then I guess its fine.

How did you handle the OpenAL library? Just added it in the same directory as the executable?

[fwcd]

@HackerPoet SFML automatically bundles OpenAL, at least when installed through a package manager (such as vcpkg, Microsoft's own C++ package manager). The rest is handled by CMake.

Embedding binary resources through source code might not be the most elegant solution (since macOS has its own way of bundling resources inside applications too), but is definitely the most portable one. Since they are going to be bundled with the executable anyway, it should not matter though. Build times weren't bad on Windows too.

The current branch runs both on Windows using MSVC + vcpkg and macOS using clang + brew successfully.

[JayFoxRox]

I did not test or review this branch, I just want to leave my notes after skimming over the PR notes and code.

---

Packing resources into the binary feels like a bad idea to me; what's the benefit?

I think packing resources makes it harder to extend the game, because you'll keep increasing binary size and will have to keep all resources / sections in memory on some platforms. It makes it harder for non-coders to change resources, which might get them interested in otherwise helping with the project. It likely increases build times, and creates a non-standard build process.

I'm also against the inclusion of boost, because it's often opening a can of worms.

I therefore suggest to move the resource packing into a separate branch / PR.

Aside from that, I do think CMake and portability will be beneficial for this project.

[fwcd]

@JayFoxRox Yes, it would probably be better to keep the resources outside of the executable in a platform-dependent way (on Windows using the Win32 API's resource loaders and on Mac using app bundles). This would, however, make consistent packaging across platforms a bit more challenging.

The Boost dependency can be completely omitted once <filesystem> from C++17 becomes supported by all major compilers (which it is currently not). Currently, it provides an easy and standardized way of handling files without worrying about platform-specific details such as path separators.

[JayFoxRox]

Most projects I've worked on are fine with using fstream or cstdio; most platform abstraction APIs (SDL etc.) also have cross-platform file access functions - I wouldn't be surprised if SFML has something; possibly also for creating folders. filesystem is only necessary for certain things (scanning folders etc.); you can often avoid that. POSIX dirent is also widely available if you can't use C++17, but must access folders.

However, I think this is better discussed on a separate PR, instead of this one, which should be focused on reviewing "CMake, macOS and Linux support" (which does not imply packing resources).

[fwcd]

@JayFoxRox This PR has to change the resource handling mechanism in some way since upstream master depends on <Windows.h> for these operations.

[jadenPete]

Hello,

I'm using the shader-backport branch, and I get this error upon execution:

Failed to compile vertex shader:
0:18(12): error: extension `GL_EXT_gpu_shader4' unsupported in vertex shader

Failed to compile vertex shader

Here is the output of glxinfo | grep OpenGL on my Arch Linux system:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Desktop 
OpenGL version string: 2.1 Mesa 18.3.1
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.3.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

[fwcd]

@jadenPete Unfortunately, this shader extension is required to use gl_VertexID inside the vertex shader.

[sbrl]

glxinfo | grep OpenGL on Intel HD graphics & AMD Radeon R7 M445 respectively:

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
$ DRI_PRIME=1 glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: AMD ICELAND (DRM 3.26.0, 4.18.0-13-generic, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.2
OpenGL shading language version string: 4.40
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

[loganzartman]

Hello,

I'm using the shader-backport branch, and I get this error upon execution:

Failed to compile vertex shader:
0:18(12): error: extension `GL_EXT_gpu_shader4' unsupported in vertex shader

Failed to compile vertex shader

@jadenPete Unfortunately, this shader extension is required to use gl_VertexID inside the vertex shader.

I had this issue on my machine, which happens to support OpenGL 3. Since gl_VertexID was introduced in GLSL version 1.3, I found that modifying the vert.glsl shader by commenting out the #extension directive and bumping the version to #version 130 was enough to get the game running. This might be a solution for some people who have support for OpenGL 3 but not 4.

[skrat]

I had this issue on my machine, which happens to support OpenGL 3. Since gl_VertexID was introduced in GLSL version 1.3, I found that modifying the vert.glsl shader by commenting out the #extension directive and bumping the version to #version 130 was enough to get the game running. This might be a solution for some people who have support for OpenGL 3 but not 4.

Yepp, this solved it for me on

[HackerPoet]

I have tested this and it almost works on Windows. I will merge this and then push in the windows fixes as well as address some of the other issues brought up in this thread.

[tatsujb]

shader-backport branch no longer exists? has it been merged into master?

[HackerPoet]

That code is already in, yes. Though it wasn't a direct merge since it conflicted with other changes I had made.