New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake, macOS and Linux support #1

Merged
merged 23 commits into from Jan 5, 2019

Conversation

Projects
None yet
@fwcd
Copy link
Contributor

fwcd commented Jan 1, 2019

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.

screen shot 2019-01-01 at 16 36 53

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

screen shot 2019-01-01 at 16 56 42

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:

demo

@clementperon

This comment has been minimized.

Copy link

clementperon commented Jan 2, 2019

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

This comment has been minimized.

Copy link
Contributor

fwcd commented Jan 2, 2019

@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

This comment has been minimized.

Copy link
Owner

HackerPoet commented Jan 2, 2019

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

This comment has been minimized.

Copy link
Contributor

fwcd commented Jan 2, 2019

@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

This comment has been minimized.

Copy link

JayFoxRox commented Jan 2, 2019

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

This comment has been minimized.

Copy link
Contributor

fwcd commented Jan 2, 2019

@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.

//Make sure shader is supported
if (!sf::Shader::isAvailable()) {
MessageBox(nullptr, TEXT("Graphics card does not support shaders"), TEXT("ERROR"), MB_OK);
std::cout << "Graphics card does not support shaders" << std::endl;

This comment has been minimized.

@JayFoxRox

JayFoxRox Jan 2, 2019

These are fatal, and should probably be cerr?

This comment has been minimized.

@fwcd

fwcd Jan 2, 2019

Contributor

This was more of a quick and dirty solution since there is no cross-platform message box API.

IMO either an exception should be used or a custom dialog window through SFML.

This comment has been minimized.

@chrisws

chrisws Jan 3, 2019

I've bookmarked a couple of cross platform message box APIs to try later: tinyfiledialogs and nativefiledialog. They might be useful here.

@JayFoxRox

This comment has been minimized.

Copy link

JayFoxRox commented Jan 2, 2019

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

This comment has been minimized.

Copy link
Contributor

fwcd commented Jan 2, 2019

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

@jadenPete

This comment has been minimized.

Copy link

jadenPete commented Jan 2, 2019

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

This comment has been minimized.

Copy link
Contributor

fwcd commented Jan 2, 2019

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

@fwcd fwcd referenced this pull request Jan 2, 2019

Closed

Linux Build? #2

@sbrl

This comment has been minimized.

Copy link

sbrl commented Jan 3, 2019

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

This comment has been minimized.

Copy link

loganzartman commented Jan 3, 2019

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

This comment has been minimized.

Copy link

skrat commented Jan 3, 2019

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

This comment has been minimized.

Copy link
Owner

HackerPoet commented Jan 5, 2019

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.

@HackerPoet HackerPoet merged commit eb36aa7 into HackerPoet:master Jan 5, 2019

@tatsujb

This comment has been minimized.

Copy link

tatsujb commented Jan 15, 2019

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

@HackerPoet

This comment has been minimized.

Copy link
Owner

HackerPoet commented Jan 15, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment