GLXBadFBConfig

[Mzed3D]

Hi! I'm trying to run Alan Wake's American Nightmare on my Odroid N2+ single board computer. It's an Arm64 device. I've compiled the software successfully but when I try to launch I get the error "GLFW Error 65543: GLX: Failed to create context: GLXBadFBConfig" Is this something related to the minimum OpenGL version required? My board is OpenGL 3.1, does the software require a newer version? Thanks!

[Mzed3D]

[Nostritius]

Hi Mzed3D, glfw is configured to request an opengl 3.3 context, so this is required to run OpenAWE. However, it might be possible that OpenAWE can run with an even lower context, since I have not found any command which requires an opengl version higher then 3.0. The 3.3 version was added when I started this whole thing as an estimate where I want to roughly land with the support. For this to change you have to go in the file src/platform/window.cpp and change glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); toglfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0); and comment out the line glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);. I have tested it on my pc and it seems to work so far. I would be very interested if it worked in your case, too.

[Nostritius]

Oh, and could you send me the output of glxinfo on your device? That could provide me a better Idea of what your device can do.

[Mzed3D]

Hi! I did what you said and recompiled the software but it didn't work anyway.. I got this error:

[2022-06-07 21:25:36.739] [info] GLFW Info: 3.3.6 X11 GLX EGL OSMesa clock_gettime evdev shared [2022-06-07 21:25:37.225] [critical] Missing GL version

This is how I've modified those lines in src/platform/window.cpp is everything alright, no?

35 glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0); 36 glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_API); 37// glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

Here's the output of glxinfo on my device: glxinfooutput.txt

[Mzed3D]

Is there something else I could do to try to make it run on my device?

[Nostritius]

Hmm, I was thinking what would help. One thing you can try is to change the GLFW_CONTEXT_VERSION_MINOR to 1 and readd glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); Your device seems to like a 3.1 opengl context. What makes me really curious is, that the window creation succeeded but glew was unable to get the opengl entry points. I know that sometimes the opengl driver does some weird stuff. I have seen that a lot in macOS.

[Mzed3D]

This is weird.. this time I got this error:

[2022-06-08 20:46:14.190] [info] GLFW Info: 3.3.6 X11 GLX EGL OSMesa clock_gettime evdev shared [2022-06-08 20:46:14.293] [error] GLFW Error 65540: Context profiles are only defined for OpenGL version 3.2 and above awe: ./src/input.c:512: glfwSetInputMode: Assertion `window != NULL' failed. Aborted (core dumped)

even if in /OpenAWE/src/platform/window.cpp I think I've specified 3.1, as you said:

switch (type) { case kOpenGL: glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1); glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_API); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

Is there somewhere else in the source files where I need to specify OpenGL 3.1?

[Nostritius]

That was my mistake, you have to keep glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); commented out.

[Mzed3D]

Almost! but it didn't work.. a window appeared for a fraction of a second and then quickly disappeared, after that the terminal gave me this error again..

[2022-06-08 22:11:02.121] [critical] Missing GL version

Do you have some x86_64 build to share? I'm curious to see if I can make it run using Box86 or Box64, even if I think I'll need a working ARM64 build to feed the game all the power it needs to run properly.

[Nostritius]

Could you execute glewinfo and send me the result?

[Mzed3D]

Here it is!

glewinfooutput.txt

[Nostritius]

Is it possible that you use wayland instead of x11?

[Mzed3D]

No, I'm certain that I'm using x11. I'm not even sure if Armbian even has wayland. I'm using xfce.

[Nostritius]

Could you try the following, after the glfwCreateWindow method, try to add the following code:

makeCurrent();
assert(glfwGetProcAddress("glGetString"));

And then tell me if the assertion triggered.

[Mzed3D]

Should I also change GLFW_CONTEXT_VERSION_MINOR to 1 and comment out glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);?

[Nostritius]

yes

[Nostritius]

Could you send the output of ldd awe on the awe executable?

[Mzed3D]

It still doesn't work, again a window appears for a second and quickly disappears, after that I get the error:

[2022-06-09 17:27:25.613] [critical] Missing GL version

Here you can find the output of ldd awe:

lddoutput.txt

[Mzed3D]

This is how I've modified OpenAWE/src/platform/window.cpp (I've changed the extension to .txt just to upload it here) window.txt

[Nostritius]

Could you run glewinfo again, but htis time with the following parameters:

glewinfo -version 3.1 -flag debug -experimental -profile core

[Mzed3D]

Sure, here it is: glewinfooutput2.txt

[Nostritius]

Can you go into the file renderer.cpp in the constructor and move the following lines of code just after the _window.makeCurrent(); and before the area marked with"Initialize GLEW":

spdlog::info("OpenGL Vendor: {}", glGetString(GL_VENDOR));
    spdlog::info("OpenGL Renderer: {}", glGetString(GL_RENDERER));
    spdlog::info("OpenGL Version: {}", glGetString(GL_VERSION));
    spdlog::info("GLSL Version: {}", glGetString(GL_SHADING_LANGUAGE_VERSION));

and send me what it return. I have also packed a compiled x86_64 version of openawe awe.zip. I am working in fedora so there might be some library mismatches.

[Mzed3D]

This is the error I get:

[2022-06-09 19:19:22.436] [info] GLFW Info: 3.3.6 X11 GLX EGL OSMesa clock_gettime evdev shared [ LOG ERROR #0001 ] [2022-06-09 19:19:23] [] {string pointer is null} [2022-06-09 19:19:23.640] [critical] Missing GL version

[Mzed3D]

I don't know if this could be of any help, but the output of the x86_64 version that you've sent me is:

Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL PageSize:4096 Box64 with Dynarec v0.1.9 e29326d built on Jun 9 2022 17:55:15 Using default BOX64_LD_LIBRARY_PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/ Using default BOX64_PATH: ./:bin/ Counted 46 Env var Looking for ./awe argv[1]="--path" argv[2]="/home/mattia/Documents/Alan Wake American Nightmare/data" Error loading needed lib libGLEW.so.2.2 Error loading one of needed lib Error: loading needed libs in elf /home/mattia/Downloads/awe

[Nostritius]

Hmm, that's strange, it seems that OpenGL is not properly initialized. Another idea would be to force OpenGLES instead of opengl. For this you have to geo into src/game.cpp and change the line

_window = std::make_unique<Platform::Window>(Platform::Window::kOpenGL);

to

_window = std::make_unique<Platform::Window>(Platform::Window::kOpenGLES);

Furthermore you have to change in the window.cpp glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2); in the OpenGLES case to glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);

[Mzed3D]

Nothing, still the same behaviour.

[2022-06-09 22:43:26.505] [info] GLFW Info: 3.3.6 X11 GLX EGL OSMesa clock_gettime evdev shared [2022-06-09 22:43:26.975] [critical] Missing GL version

[Mzed3D]

but why it's still talking about GL if we're forcing GLES?

[Nostritius]

Well, because GL and GLES are for about 98% the same and boards such as yours normally prefer GLES. I even researched a bit and found out that these odroid boards do not have a up until recently OpenGL support. The problem seems to be, that the application is not propertly linked to a libGL and when trying to call into gl functions there seems to be problems. One last thing I have in mind for this is that you can try to give cmake the argument "-DOpenGL_GL_PREFERENCE=LEGACY".

[Mzed3D]

Now something interesting happened. This was the output:

[2022-06-09 23:37:19.194] [info] GLFW Info: 3.3.6 X11 GLX EGL OSMesa clock_gettime evdev shared [2022-06-09 23:37:19.901] [info] OpenGL Vendor: Panfrost [2022-06-09 23:37:19.901] [info] OpenGL Renderer: Mali-G52 (Panfrost) [2022-06-09 23:37:19.901] [info] OpenGL Version: 3.1 Mesa 22.2.0-devel (git-0cb05d13b0) [2022-06-09 23:37:19.901] [info] GLSL Version: 1.40 Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_PATCH_VERTICES) [2022-06-09 23:37:19.906] [info] OpenGL Max Texture Units: 32 [2022-06-09 23:37:19.906] [info] OpenGL Max Texture Coordinates: 8 [2022-06-09 23:37:19.906] [info] OpenGL Max Vertex Attributes: 16 [2022-06-09 23:37:19.906] [info] OpenGL Max Uniform Attributes: 16 [2022-06-09 23:37:19.906] [info] OpenGL Max Patch Vertices: 0 [2022-06-09 23:37:19.906] [info] OpenGL Max Vertex Uniform Components: 16352 [2022-06-09 23:37:19.906] [info] OpenGL Max Fragment Uniform Components: 16380 [2022-06-09 23:37:19.906] [info] Num OpenGL Extensions: 242 [2022-06-09 23:37:19.906] [critical] Not enough patch vertices available

[Mzed3D]

Isn't this something related to OpenGL 4.0?

[Nostritius]

Yes, but it is not yet implemented. In short, both Alan Wake games utilize tessellation for the terrain. But since it is not yet in use, I could make a conditional around it. In the long term it might be an option to make the whole tessellation part optional, since the terrain works quite well without it, but I cannot guarantee that. Maybe the panfrost driver will add support for tessellation in the meantime since the hardware is in theory capable for that, I have added two commits, one of them removes the defaulting of the OpenGL preference to GLVND (instead of LEGACY), the other makes the whole retrieval of the tessellation information optional. According to the logged information you probably also need to change the version of the glsl files to 140. You can do this by replacing

#version 330 core

with

#version 140

[Mzed3D]

In which file should I replace that line? Anyway, I hope the developers will implement that but unfortunately just these days they have announced they'll focus their efforts on newer hardware so I think panfrost development will be slowed down.

[Nostritius]

The glsl files are stored in the shaders directory and have the file ending .glsl

[Mzed3D]

Still no luck, this time I got this error:

Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_PATCH_VERTICES) [2022-06-10 14:48:26.355] [info] OpenGL Max Patch Vertices: 0 [2022-06-10 14:48:26.357] [critical] /home/mattia/OpenAWE/src/graphics/opengl/renderer.cpp:89: Not enough patch vertices available. Expected 4, got 0

I also tried to delete the lines 84 to 91 from your today's first commit, these ones:

if (GLEW_ARB_tessellation_shader) { GLint maxPatchVertices; glGetIntegerv(GL_MAX_PATCH_VERTICES, &maxPatchVertices); spdlog::info("OpenGL Max Patch Vertices: {}", maxPatchVertices); if (maxPatchVertices < 4) { throw CreateException("Not enough patch vertices available. Expected 4, got {}", maxPatchVertices); } }

I compiled again and this time I got this other error:

[2022-06-10 14:59:52.393] [error] 0:28(1): error: shader output explicit location requires GL_ARB_explicit_attrib_location extension or GLSL 3.30 [2022-06-10 14:59:52.395] [critical] Error while compiling shader: 0:28(1): error: shader output explicit location requires GL_ARB_explicit_attrib_location extension or GLSL 3.30

[Mzed3D]

Why is asking for GL_ARB_explicit_attrib_location which is OpenGL 3.3 even if I specified everywhere in the source code to use 3.1?

[Nostritius]

The problem is probably is that there was one layout modifier left in a shader, which I removed in the last commit

[Mzed3D]

I made three tests:

1) the first time I edited the source so that everything was set to opengl 3.1 and the result still was:

[critical] /home/mattia/OpenAWE/src/graphics/opengl/renderer.cpp:89: Not enough patch vertices available. Expected 4, got 0

2) then, a friend of mine suggested me that the mesa drivers for the Odroid N2 (Panfrost) actually supported OpenGL 3.3, almost entirely, as shown here: https://mesamatrix.net/#OpenGL (just unfold "Drivers details" to see that there are 90% of the 3.3 extensions implemented). So he suggested to put the line "PAN_MESA_DEBUG=gl3" in /etc/environment to enable the support for OpenGL 3.3. I did. Glmark2 correctly showed "OpenGL 3.3", so I cloned again the repository and this time I didn't edit anything from the source, but still I got the error:

[critical] /home/mattia/OpenAWE/src/graphics/opengl/renderer.cpp:89: Not enough patch vertices available. Expected 4, got 0

3) So I decided to try to avoid this error by just changing the sign of "if (maxPatchVertices < 4)" in /OpenAWE/[src/graphics/opengl/renderer.cpp just as an experiment. I wrote "if (maxPatchVertices > 4)". I recompiled again and the error didn't show of course but I had a new error instead:

Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_PATCH_VERTICES) [2022-06-11 01:39:43.049] [info] OpenGL Max Patch Vertices: 0 [2022-06-11 01:39:43.049] [info] Num OpenGL Extensions: 165 awe: /home/mattia/OpenAWE/src/graphics/opengl/renderer.cpp:111: Graphics::OpenGL::Renderer::Renderer(Platform::Window&): Assertion `glGetError() == GL_NO_ERROR' failed. Aborted (core dumped)

Do you understand something?

[Nostritius]

Hmm, in the first two examples it fails on the tessellation test and falsely assumes, that tessellation is available, even if its not. The third one has a similar error because glGetIntegerv already sets the error, because it doesn't know GL_MAX_PATCH_VERTICES, leading to the error check to trigger. There are two things you can try. First you can set glewExperimental from true to false right before the call to glewInit. Secondly you can try to replace GLEW_ARB_tessellation_shader with glewIsSupported("GL_ARB_tessellation_shader").

[Mzed3D]

Sorry, I had closed the issue by mistake :) Anyway, After having set my device to use the available OpenGL 3.3 extensions, setting glewExperimental to false and compiling with DOpenGL_GL_PREFERENCE=LEGACY worked! Now, I don't know at what stage this project is but I had this window with a 3d landscape (seen from below) standing still. I coldn't control anything and nothing was moving. But anyway.. We have the first step for an ARM64 port of Alan Wake!

[Mzed3D]

I don't know if everything is actually still or maybe my device is to weak to handle an entire 3d map at once..

[Nostritius]

Ouh, nice, I was always wondering if it is possible to port it onto a single board computer with more limited resources. The fact, that it is able to load the whole map without some out of memory error is promising. Anyway, the camera can be controlled with the WASD keys for movement, the QE keys for rotation and the RF keys for up and down. You can also slow down or speed up the camera with the TG keys. The idea was basically to provide a fly cam mode as in the original game. You can get a significant speedup of the renderer, if you compile it in release mode. That enables compiler optimizations making the renderer (at least on my pc) significantly faster.

[Mzed3D]

You would be amazed to see the performance this little sbc has when there is a good port. OpenMW (The Elder Scrolls III: Morrowind), Arx Libertatis (Arx Fatalis), Dhewm3 (Doom 3), ReVC (GTA: Vice City), they all fly on this device. But a good port is essential and they're quite rare. Are you serious about OpenAWE? Alan Wake 1 is one of my favourite games and it would be great to see it working on this device. I also understand that is a much more demanding game compared to the ones above.. anyway, now I'm recompiling using -DCMAKE_BUILD_TYPE=RelWithDebInfo, is this right? Let's see what happens..

[Mzed3D]

It worked! I was able to navigate the scene without problems :) of course it was quite a bad framerate but not even terrible.. And it was the whole map!

[Nostritius]

You would be amazed to see the performance this little sbc has when there is a good port. OpenMW (The Elder Scrolls III: Morrowind), Arx Libertatis (Arx Fatalis), Dhewm3 (Doom 3), ReVC (GTA: Vice City), they all fly on this device. But a good port is essential and they're quite rare. Are you serious about OpenAWE? Alan Wake 1 is one of my favourite games and it would be great to see it working on this device. I also understand that is a much more demanding game compared to the ones above.. anyway, now I'm recompiling using -DCMAKE_BUILD_TYPE=RelWithDebInfo, is this right? Let's see what happens..

I am definitely serious on OpenAWE. In fact, I have reversed it that far, that a playable version is totally doable. There is much more already implemented, which you do not see, for example animations are already working well, while they are not yet added visibly to the game for a certain reasons. I just try to keep it one small step at a time to make it handleable for me alone and seeing immediate results for motivation. But the truth is also that things could be faster with more help from other people, I'm doing this currently on my own.

[Nostritius]

It worked! I was able to navigate the scene without problems :) of course it was quite a bad framerate but not even terrible.. And it was the whole map!

That's great to hear. I know that the renderer currently wastes a lot of potential for speed up, but I wanted to first focus on reproducing at least a rough estimate of Alan Wakes render path before I start to optimize it further. I'm actually working on an overhaul of the renderer, making stuff like lights possible. If there is nothing else, you can close the issue. Feel free to open another issue if problems arise in the future. As I said I am quite interested, how OpenAWE performs on sbcs. You can also join the gitter chat, if you want to talk with me more ;).

[Mzed3D]

I'll definitely join the chat! As for some help for your project I can talk to Salvador, he's the owner of the YouTube channel called "Microlinux", which is dedicated to linux arm sbcs. Also Sebastien (the Box86 developer) talks about his channel on his github page. I can ask Salvador if he can talk about this project in one of his next videos and tell him you're looking for help.

[Nostritius]

Thanks, I would really appreciate that :smiley:

[Mzed3D]

I've talked to him, let's see..