Compile error aarch64 build via OpenGLES2

[Cebion]

Hi guys,

currently tryring to compile rttr for an embedded linux handheld with an RK3566 no x or opengl.

Compiled via

cmake .. -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Release -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DRTTR_USE_SYSTEM_LIBS=ON -DRTTR_INCLUDE_DEVTOOLS=OFF -DRTTR_OPENGL=GLES2.0

It complains about missing declares ```

`/root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp: In member function ‘virtual bool DummyRenderer::initOpenGL(IRenderer::OpenGL_Loader_Proc)’: /root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp:46:10: error: ‘glVertexPointer’ was not declared in this scope; did you mean ‘rttrOglMock::glVertexPointer’? 46 | MOCK(glVertexPointer); | ^~~~~~~~~~~~~~~ /root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp:39:20: note: in definition of macro ‘MOCK’ 39 | #define MOCK(FUNC) FUNC = rttrOglMock::FUNC | ^~~~ /root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp:24:15: note: ‘rttrOglMock::glVertexPointer’ declared here 24 | void APIENTRY glVertexPointer(GLint, GLenum, GLsizei, const GLvoid*) {} | ^~~~~~~~~~~~~~~ /root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp:47:10: error: ‘glTexCoordPointer’ was not declared in this scope; did you mean ‘rttrOglMock::glTexCoordPointer’? 47 | MOCK(glTexCoordPointer); | ^~~~~~~~~~~~~~~~~ /root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp:39:20: note: in definition of macro ‘MOCK’ 39 | #define MOCK(FUNC) FUNC = rttrOglMock::FUNC | ^~~~ /root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp:25:15: note: ‘rttrOglMock::glTexCoordPointer’ declared here 25 | void APIENTRY glTexCoordPointer(GLint, GLenum, GLsizei, const GLvoid*) {} | ^~~~~~~~~~~~~~~~~ /root/compile/s25client/libs/s25main/ogl/DummyRenderer.cpp:48:10: error: ‘glColor4ub’ was not declared in this scope; did you mean ‘rttrOglMock::glColor4ub’? 48 | MOCK(glColor4ub);```

I investigated the glad dependency a bit and found this in my CmakeFiles

build# ls -l external/glad/CMakeFiles/glad.dir/
total 48
-rw-r--r-- 1 root root  441 Mar 10 12:03 C.includecache
-rw-r--r-- 1 root root  631 Mar 10 12:00 DependInfo.cmake
drwxr-xr-x 3 root root 4096 Mar 10 12:00 OpenGL2.0
-rw-r--r-- 1 root root 4600 Mar 10 12:00 build.make
-rw-r--r-- 1 root root  248 Mar 10 12:03 cmake_clean.cmake
-rw-r--r-- 1 root root   36 Mar 10 12:03 cmake_clean_target.cmake
-rw-r--r-- 1 root root  293 Mar 10 12:03 depend.internal
-rw-r--r-- 1 root root  387 Mar 10 12:03 depend.make
-rw-r--r-- 1 root root  238 Mar 10 12:00 flags.make
-rw-r--r-- 1 root root   95 Mar 10 12:00 link.txt
-rw-r--r-- 1 root root   41 Mar 10 12:03 progress.make

It copied the OpenGL2.0 glad folder instead of the OpenGLES2.0. So this might be a problem too.

I'm compiling inside an generic aarch64 chroot so no limitations in that regard

Any ideas?

[kloptops]

GLES_cmake.patch

Looks like there is a bug in external/glad/CMakeLists.txt, it does a regex but then references the wrong match CMAKE_MATCH_0 instead of CMAKE_MATCH_1. Which means it always choose OpenGL instead of OpenGLES.

[Flamefire]

@kloptops You are right. Are you able to submit this as a PR? You can even do that via the github web page by editing the file in the browser and following the steps it shows you.
This will record your authorship on that change.

Thanks a lot!

[kloptops]

Unfortunately while that does fix the glad error, it now has missing definitions/functions required in TerrainRenderer.cpp

Here's the output with cmake .. -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Release -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DRTTR_USE_SYSTEM_LIBS=ON -DRTTR_INCLUDE_DEVTOOLS=OFF -DRTTR_OPENGL=GLES2.0

error.log

It seems GLES doesn't have a bunch of OpenGL functions you use. I can still fix the other issue, but GLES isn't working with the current state of things.

Edit: fixed link to the actual log file.

[Flamefire]

It seems GLES doesn't have a bunch of OpenGL functions you use. I can still fix the other issue, but GLES isn't working with the current state of things.

Ah yes, I think I remember that I wanted to port that stuff to actual shaders etc. which would then support GLES but never had the time to do so. The use of Glad was only the first step in preparation of that but the work required looks more than I initially anticipated.

So yes, it won't work with GLES (among others...) currently. However your fix certainly improves things.

[kloptops]

Okay thats good to know, I will submit a PR for the cmake fix. For now i am using a compatibility layer gl4es and a hacked up version glad that I called OpenGLES2.0Compat. I am about 95% of the way to getting the game to load.

I have a diff of what i have done so far here.