Descent 3 & gl4es

[JeodC]

Hello.

I have forked the Descent 3 open source repository and am attempting to use it with embedded systems via gl4es. A partner initially had the game rendering by using SDL_LoadObject instead of SDL_LoadLibrary. This rendered the game to the lower left of the display on my device:

Icculus then provided a commit to use a FBO, which caused the game to have audio and input, but no display at all. I modified the commit to use SDL_LoadFunction in conjunction with SDL_LoadObject, but this didn't help.

I use the following exports to set up the context:

# Setup gl4es environment
export LIBGL_ES=2
export LIBGL_GL=21
export LIBGL_FB=4

export SDL_VIDEO_GL_DRIVER="$GAMEDIR/libs.$DEVICE_ARCH/libGL.so.1"
export LIBGL_DRIVERS_PATH="$GAMEDIR/libs.$DEVICE_ARCH/libGL.so.1"
export LD_LIBRARY_PATH="$GAMEDIR/libs.$DEVICE_ARCH:/usr/lib:$LD_LIBRARY_PATH"

I have tried some other options according to USAGE.md to no avail. Here is the game's log file:

d3.log

Also, dyna_gl.h and HardwareOpenGL.cpp.

Is the game's code compatible with gl4es? If there need to be adjustments, can you point me in the right direction?

Thank you for your time.

[JeodC]

Through debug print statements in HardwareOpenGL.cpp I have determined that the FBO is initialized and the game blits to scale properly (1920x1152 display).

// if we're rendering to an FBO, scale to the window framebuffer!
  mprintf(0, "Value of GOpenGLFBO: %d\n", GOpenGLFBO);
  if (GOpenGLFBO != 0) {

    dglBlitFramebufferEXT(0, 0, GOpenGLFBOWidth, GOpenGLFBOHeight,
                          centeredX, centeredY, centeredX + scaledWidth, centeredY + scaledHeight,
                          GL_COLOR_BUFFER_BIT, GL_LINEAR);
    mprintf(0, "Blit framebuffer at: (%d, %d) to (%d, %d)\n", centeredX, centeredY, centeredX + scaledWidth, centeredY + scaledHeight);

CFILE: Using "intro.mve" instead of "intro.mve"
FindArg: Did not find [-sdlSndSizeMovie] on command line.
FindArg: Did not find [-sdlSndSize] on command line.
OPENGL: Setting zbuffer state to 0.
OPENGL: Setting zbuffer state to 1.
Value of GOpenGLFBO: 1
Blit framebuffer at: (192, 0) to (1728, 1152)
OPENGL: Setting zbuffer state to 0.
OPENGL: Setting zbuffer state to 1.

Edit: Confirming the SDL window is also created:

if (!GSDLWindow) {
    mprintf(0, "Creating SDL window with size %dx%d and flags %d\n", winw, winh, flags);
    GSDLWindow = SDL_CreateWindow("Descent 3", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, winw, winh, flags);
    if (!GSDLWindow) {
      mprintf(0, "OpenGL: SDL window creation failed: %s", SDL_GetError());
      return 0;
    }
  } else {
    int currentW, currentH;
    SDL_GetWindowSize(GSDLWindow, &currentW, &currentH);
    mprintf(0, "Current SDL Window size is %dx%d\n", currentW, currentH);
    
    mprintf(0, "Setting SDL Window to %dx%d\n", winw, winh);
    SDL_SetWindowSize(GSDLWindow, winw, winh);

    mprintf(0, "Setting SDL Window to fullscreen with flags %d\n", flags);
    SDL_SetWindowFullscreen(GSDLWindow, flags);

    // Retrieve and print the actual window size
    int actualW, actualH;
    SDL_GetWindowSize(GSDLWindow, &actualW, &actualH);
    mprintf(0, "Actual SDL Window size is %dx%d\n", actualW, actualH);
  }

  if (!GSDLGLContext) {
    mprintf(0, "Creating OpenGL context for the SDL window\n");
    GSDLGLContext = SDL_GL_CreateContext(GSDLWindow);
    if (!GSDLGLContext) {
      mprintf(0, "OpenGL: OpenGL context creation failed: %s", SDL_GetError());
      SDL_DestroyWindow(GSDLWindow);
      GSDLWindow = NULL;
      return 0;
    } else {
        mprintf(0, "OpenGL: OpenGL context created successfully\n");
    }
  }

Creating SDL window with size 640x480 and flags 2
Creating OpenGL context for the SDL window
OpenGL: OpenGL context created successfully

[JeodC]

d3.log

Here is a newer, more detailed logfile.

[ptitSeb]

Oh, you are using FB=4, so gbm rendering?! That will be tricky to debug, I don't have hardware like that myself

[ptitSeb]

I don't see the gl4es initialisation string on that log, that's strange.

[JeodC]

It's a partial log, the full one is rather large. Here it is. This log begins at game initialization, goes up to the main menu, then quits.

d3.log

Note that this log is generated by the game itself, so gl4es initialization string may not be present. Here is the full launch script:

#!/bin/bash

XDG_DATA_HOME=${XDG_DATA_HOME:-$HOME/.local/share}

if [ -d "/opt/system/Tools/PortMaster/" ]; then
  controlfolder="/opt/system/Tools/PortMaster"
elif [ -d "/opt/tools/PortMaster/" ]; then
  controlfolder="/opt/tools/PortMaster"
elif [ -d "$XDG_DATA_HOME/PortMaster/" ]; then
  controlfolder="$XDG_DATA_HOME/PortMaster"
else
  controlfolder="/roms/ports/PortMaster"
fi

source $controlfolder/control.txt
source $controlfolder/device_info.txt
[ -f "${controlfolder}/mod_${CFW_NAME}.txt" ] && source "${controlfolder}/mod_${CFW_NAME}.txt"
get_controls

GAMEDIR="/$directory/ports/descent3"
DEVICE_ARCH="${DEVICE_ARCH:-aarch64}"
GAME="Descent3"

cd $GAMEDIR

if [ -f "${controlfolder}/libgl_${CFW_NAME}.txt" ]; then 
  source "${controlfolder}/libgl_${CFW_NAME}.txt"
else
  source "${controlfolder}/libgl_default.txt"
fi

# Create config dir
rm -rf "$XDG_DATA_HOME/Outrage Entertainment/Descent 3"
ln -s $GAMEDIR "$XDG_DATA_HOME/Outrage Entertainment/Descent 3"

# Setup gl4es environment
export LIBGL_ES=2
export LIBGL_GL=21
export LIBGL_FB=4
export LIBGL_VBO=1
export LIBGL_STACKTRACE=1

export SDL_VIDEO_GL_DRIVER="$GAMEDIR/libs.$DEVICE_ARCH/libGL.so.1"
export LIBGL_DRIVERS_PATH="$GAMEDIR/libs.$DEVICE_ARCH/libGL.so.1"
export LD_LIBRARY_PATH="$GAMEDIR/libs.$DEVICE_ARCH:/usr/lib:$LD_LIBRARY_PATH"

# Setup controls
$ESUDO chmod 666 /dev/tty1
$ESUDO chmod 666 /dev/uinput

$GPTOKEYB "$GAME" -c "joy.gptk" & 
SDL_GAMECONTROLLERCONFIG="$sdl_controllerconfig"
./$GAME -setdir "$GAMEDIR/gamedata" -f -logfile -g $LIBGL_DRIVERS_PATH -gllogging

$ESUDO kill -9 $(pidof gptokeyb)
$ESUDO systemctl restart oga_events & 
printf "\033c" >> /dev/tty1

I've also walked through the render steps to the best of my ability, here's a brief summary of the order of operations:

SDL Window Creation and OpenGL Context Initialization:

SDL window creation with appropriate attributes (SDL_GL_SetAttribute calls).
Creation and management of the OpenGL context (SDL_GL_CreateContext).
Setting the OpenGL context as current (SDL_GL_MakeCurrent).

FBO Management:

Proper teardown of existing FBO and renderbuffers (dglDeleteFramebuffersEXT, dglDeleteRenderbuffersEXT).
Creation of new FBO and associated renderbuffers (dglGenFramebuffersEXT, dglGenRenderbuffersEXT, dglFramebufferRenderbufferEXT).

Viewport and Scissor Management:

Setting viewport and scissor to match the dimensions of the SDL window or the FBO, ensuring correct rendering area.

Blitting from FBO to SDL Window:

Proper use of dglBlitFramebufferEXT to blit the FBO content onto the SDL window when necessary.

Buffer Swapping:

Correct usage of SwapBuffers (on Windows) and SDL_GL_SwapWindow (on Linux) to swap the front and back buffers, presenting the rendered content to the screen.

[JeodC]

d3.log

Another log, run via ssh, this one shows gl4es init strings.

[JeodC]

A partner added a screenshot function to determine if the framebuffer renders correctly before blitting, and there was an oddity in the Descent 3 code. To quote him, "there is only one texture and it's 128x128 with some garbage". When building the FB, gl4es appears to be creating a texture with id 1 and attaches it to GL_COLOR_ATTACHMENT0_EXT, but later the game tries to overwrite that texture with another texture.

Setting cur_texture_object_num = 2; at https://github.com/JeodC/Descent3/blob/develop/renderer/HardwareOpenGL.cpp#L119 and https://github.com/JeodC/Descent3/blob/develop/renderer/HardwareOpenGL.cpp#L311 makes the first texture id the game uses equal 2, and then the FB renders correctly.

Unfortunately, the SDL window (FB0) still displays a blank screen. The problem seems to be in blitting, maybe: https://github.com/JeodC/Descent3/blob/develop/renderer/HardwareOpenGL.cpp#L2052C1-L2056

[JeodC]

Another opinion:

"What if GL4ES doesn't have any direct support for renderbuffers and it's creating a texture under the hood? Well, if it is, we now have a problem. Old OpenGL let you use texture names freely, so Descent 3 is like "okay my first texture is texture #1. My second is texture #2" and so on. The modern way of doing it is that you have to ask OpenGL for those numbers with glGenTextures."

I'm not sure if this is a lead, but it seemed like a valid question.

[JeodC]

I don't have hardware like that myself

PortMaster has hundreds of ports that rely on gl4es and gbm. We can surely arrange something for you if you would like hardware for testing. It would be our way of thanking you. 🙂

[ptitSeb]

I don't have hardware like that myself

PortMaster has hundreds of ports that rely on gl4es and gbm. We can surely arrange something for you if you would like hardware for testing. It would be our way of thanking you. 🙂

What kind of hardware use gl4es+gbm? ambernic console, this kind of things? (I have none anyway).

[JeodC]

I don't have hardware like that myself

PortMaster has hundreds of ports that rely on gl4es and gbm. We can surely arrange something for you if you would like hardware for testing. It would be our way of thanking you. 🙂

What kind of hardware use gl4es+gbm? ambernic console, this kind of things? (I have none anyway).

Anbernic and Powkiddy devices officially. With some effort we've gotten ports to run on more niche handhelds like the Gameforce Chi and TrimUI Smart Pro. Like I said we're more than happy to send you hardware--I can't think of a better way to witness the fruits of your labor.

If you're interested, fire an email to contact@portmaster.games and our administrator will take care of the rest. 🙂

Ports background information: https://portmaster.games/porting.html

[ptitSeb]

Ok, I'll send a mail at this address.

For the record, I ported hundreds of stuffs for the OpenPandora, that's why I developped gl4es and then box86 in the first place :D

Portmaster is a nice project indeed.

[JeodC]

Right. I know this game ran on box86 with gl4es. The only differences now are no x11 requirement, sdl2, and fbo. I'm assuming the libGL that's been compiled by another is using the correct compiler definitions (nox11=true etc). With a cursory glance, does anything specific to check come to mind given we know the fbo is receiving the draws but the screen is blank?

[ptitSeb]

There might be an issue with the context creation, especialy if the game / sdl2 tries multiple context creation to find the best one. the GLX part is still a bit fragile in gl4es, especialy with gbm backend that receive very little testing.

[JeodC]

I reverted the framebuffer object commit entirely and just went with what currently existed. It works with gl4es, but you may wish to continue looking into this particular issue. If so, feel free to reopen for tracking. Thanks!