Running Nanosaur on the Raspberry Pi 4

[vanfanel]

Hi there,

Now that it's possible to build Nanosaur without GLU or X11 (once the pending PR is merged at least!), it's time to get it running on a Raspberry Pi 4 using the latest MESA OpenGL implementation.

Currently, I am getting this when trying to run Nanosaur on a Pi4:

~/src/Nanosaur/b4# ./Nanosaur 
NANOSAUR FATAL ALERT: OpenGL error 0x500
in __SetInitialClientState:170

Seems to me that Nanosaur requires OpenGL 2.0, and the Pi4 does up to OpenGL 2.1 if I am not mistaken, so.. Any idea on what's missing here?

[vanfanel]

To actively contribute to a fix for this, I ran Nanosaur Pi4 build on GDB, and found this:

Thread 1 "Nanosaur" hit Breakpoint 1, __SetInitialClientState (stateEnum=32884, stateFlagPtr=0x5555682035 <gState+5>, 
    initialValue=true) at /root/src/Nanosaur/src/QD3D/Renderer.c:165
165             *stateFlagPtr = initialValue;
(gdb) n
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred
166             if (initialValue)
(gdb) n
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred
167                     glEnableClientState(stateEnum);
(gdb) 
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred
170             CHECK_GL_ERROR();
(gdb)

As you can see, it is stateEnum=32884, which translates to:

usr/include/GL/gl.h:#define GL_VERTEX_ARRAY 0x8074

...But I have no idea on why setting GL_VERTEX_ARRAY state to true is a problem on the Pi4.
I have some full OpenGL programs working on the Pi4 with no problems so in general it works.

My guess is a previous error....

[jorio]

Yeah, GL_VERTEX_ARRAY is the very first state that gets initialized in Render_InitState, so something may have errored out before entering Render_InitState.

I suppose some GL call went wrong in QD3D_SetupWindow between the creation of the GL context (which appears to be successful since we get this far) and the call to Render_InitState.

You can try adding some CHECK_GL_ERROR(); lines after the GL calls in QD3D_SetupWindow to narrow down the culprit.

[vanfanel]

@jorio I am using glError() and I have found out that it returns 0 untill this exact call:

Nanosaur/src/Screens/Title.c

Line 342 in b567a3e

SDL_GLContext glContext = SDL_GL_CreateContext(gSDLWindow);

Does it make any sense to you?
Only happens on the Pi, on several X86 machines I have around it works perfectly well.

EDIT: Trying to call SDL_GL_CreateContext() immediately after the SDL_GL_SetAttribute() calls in CommonMain() also results on glGetError() returning 1280 (=0x0500).
So it's clearly context creation that is failing. But I don't know why, played around with different SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_MAJOR_VERSION and SDL_GL_CONTEXT_MINOR_VERSION values but didn't find anything relevant.

[orazioedoardo]

@jorio I'm getting this same error, GL_INVALID_ENUM, on a clean installed Debian 13 virtual machine with GNOME, graphic virgl(ANGLE(Apple, Apple M1, OpenGL 4.1 - Metal 89,4)). The only game that works is Bugdom 1 since CHECK_GL_ERROR doesn't do anything on release mode. If i uncomment the assertion, all games seems to work while trying for a bit though.