OpenArena and Other OpenGL Games RPI 4

[bunklung]

Many of the major review sites have reported OpenArena benchmarks at about 40fps on the PI4.

I can't get anywhere near that. The frame rate is closer to 2fps.

Are people using custom builds of OpenArena?

Does anyone have any other games that work well on the PI 4 in OpenGL?

[jdonald]

2 fps sounds like Mesa resorted to CPU rendering (llvmpipe).

Are you configured for fkms in /boot/config.txt? Even if the vc4 module (still called that even on VC6!) reports being loaded, sometimes the system can get into a bad state as happened to me and another user in this thread. It can be diagnosed by running glxgears and checking CPU usage, or some games will print out on the console whether you end up in llvmpipe instead of V3D. Usually fixed by just rebooting.

Does anyone have any other games that work well on the PI 4 in OpenGL?

Not GL, but cdev-tux got q3lite (ioq3 engine, same as OpenArena) running at reasonable speed with Mesa GLES 1.1. I don't have a Pi 4 so I can't confirm.

Serious Sam TSE (GL) is expected to run well on a Pi 4. Would like someone to test that.

Minecraft Java Edition 1.12.2 with OptiFine seems to working well for everyone.

Mupen64plus (GlideN64 video plugin) with libretro: Some users have reported smooth performance and there are videos online to back this up. However, other users report being unable to get better than 25 fps and aren't sure why.

[Gavinmc42]

SuperTuxKart runs
Warzone2100 has some issues and I having trouble compiling the latest version.
0AD might need more ram?
The Cube2 demo works
The Raspbian Minecraft obviously
Minetest works
DreamChess , 3D Chess are OpenGL?

Lots of games seem to work now, but it is a big list to check

Installing Openarena now, it takes some time.

[MamiyaOtaru]

I get 50 to 90 FPS at 1270*780 on the pi 4 in Quake 3. Apt-get installed from the buster repos.

[Hanicef]

Don't forget to go into raspi-config and enabling experimental OpenGL drivers under the advanced options, then restarting the Raspberry Pi.
Not doing so will cause the rendering to be done on the CPU, which is horrendously slow.

[bunklung]

I get 50 to 90 FPS at 1270*780 on the pi 4 in Quake 3. Apt-get installed from the buster repos.

Okay, I installed Quake3 and all the pak files, but it still runs unusually slow. What Quake 3 graphics settings do you have?

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
dtoverlay=vc4-fkms-v3d
gpu_mem=256

Quake seems to report it's using the correct Mesa Drivers. If I set it to fastest and like a resolution of 512, it playable. But I can't seem to make widescreen options stick.

[bunklung]

I can tell when 3D is not enabled as it' says VMWARE for the 3D driver in Quake 3.

Does anyone think if I have a bad silicone chip of something. The texturing seems to pop in an out, like its corrupting somehow someway.

[Gavinmc42]

Sounds like you messed up a setting.
My 4 defaults to OpenGL, yours must be software rendering.

[bunklung]

Sounds like you messed up a setting.
My 4 defaults to OpenGL, yours must be software rendering.

When I disable 3D (#dtoverlay=vc4-fkms-v3d), it's clearly running in software rendering mode. When you look at driver info it says VMWare. I get like 2fps.

When 3D is enabled (dtoverlay=vc4-fkms-v3d), it shows MESA as the driver. It runs better than software mode, but closer to 10-20 FPS. If I lower the detail to fastest and pick a low resolution it can get up to 50-90 fps.

The textures seem to corrupt when playing.

I can do a fresh install, again, do you have any other recommendations?

Should I install the mesa-dev package? The glxgears seemed to run 60 in a tiny window.

[leilei]

The textures seem to corrupt when playing.

OA doesn't support whatever debian downstream does for an engine (we only support this). I'm assuming it's forcing that new unfinished default OpenGL2 renderer - which looked completely broken last time I checked on a Pi3.

[bunklung]

The textures seem to corrupt when playing.

OA doesn't support whatever debian downstream does for an engine (we only support this). I'm assuming it's forcing that new unfinished default OpenGL2 renderer - which looked completely broken last time I checked on a Pi3.

I see this effect on both Quake 3 and OA. I assume they are running the same ioquake build?

Why aren't others reporting this?

[dreed]

The textures seem to corrupt when playing.

OA doesn't support whatever debian downstream does for an engine (we only support this). I'm assuming it's forcing that new unfinished default OpenGL2 renderer - which looked completely broken last time I checked on a Pi3.

I see this effect on both Quake 3 and OA. I assume they are running the same ioquake build?

Why aren't others reporting this?

I have the same experience. Q3 and OA are unplayable with low FPS and texture popping in and out like crazy. I can also get it to play at an acceptable FPS if I drop the resolution and every setting to low, but the texture popping still makes it unplayable. I haven't really changed anything other than updating the firmware.

[bunklung]

OA doesn't support whatever debian downstream does for an engine (we only support this). I'm assuming it's forcing that new unfinished default OpenGL2 renderer - which looked completely broken last time I checked on a Pi3.

I see this effect on both Quake 3 and OA. I assume they are running the same ioquake build?

Why aren't others reporting this?

I have the same experience. Q3 and OA are unplayable with low FPS and texture popping in and out like crazy. I can also get it to play at an acceptable FPS if I drop the resolution and every setting to low, but the texture popping still makes it unplayable. I haven't really changed anything other than updating the firmware.

I wonder if it has something to do with memory allocation? Perhaps somehow/someway there is only a limited set of memory being reserved for video/texture memory. So we get this off texture thrashing effect? Is this related to model?

Does everyone have the 4GB model?

How do with check how much memory is available to OpenGL? In the past this was done by config.txt, but that's ignored now at some level?

[leilei]

It's less to do with texture memory and more to do with GLSL implementation...


For now you should be able to rebel against the bad default and set
/cl_renderer opengl1

to get something that (hopefully) works.

[bunklung]

It's less to do with texture memory and more to do with GLSL implementation...


For now you should be able to rebel against the bad default and set
/cl_renderer opengl1

to get something that (hopefully) works.

Thanks. Now the questions:

I did a clean install and could not get either to run correctly, yet other's seem to run OpenArena fine (or Quake 3) without setting cl_renderer.

Are others inadvertently running cl_renderer 1?

quake3 +set cl_renderer opengl1 +set r_mode -1 +set r_customwidth 1280 +set r_customheight 720 +set r_fullscreen 1 +set cg_drawFPS 1
openarena +set cl_renderer opengl1 +set r_mode -1 +set r_customwidth 1280 +set r_customheight 720 +set r_fullscreen 1 +set cg_drawFPS 1

So yeah, I was able to get decent framerates in Quake 3 and OpenArena when forcing cl_renderer to 1.

Thanks, but how can this be explained?

In Quake 3 I get about 86 fps in 720 or about 36 in 1080 on four.dm_68 timedemo.

Mirror effects/portals don't seem to render correctly.

[bunklung]

I get 50 to 90 FPS at 1270*780 on the pi 4 in Quake 3. Apt-get installed from the buster repos.

What does cl_renderer report in console?

[jdonald]

Recently got a Pi 4 and was able to test openarena + GL quake3.

OpenArena: Default renderer is opengl2 and renders at about 20 fps for 1280x720. Switching to opengl1 makes things smooth at 60+ fps. Maybe MamiyaOtaru just neglected to mention that bit

Meanwhile quake3 from the Raspbian APT repository runs in opengl2 mode (slowly just like openarena), but if I switch to opengl1 it always freezes after the splash screen animation. q3lite (GLES 1.1) on a Pi 4 gets 70~80 fps for the same resolution.

[bunklung]

Recently got a Pi 4 and was able to test openarena + GL quake3.

OpenArena: Default renderer is opengl2 and renders at about 20 fps for 1280x720. Switching to opengl1 makes things smooth at 60+ fps. Maybe MamiyaOtaru just neglected to mention that bit

Meanwhile quake3 from the Raspbian APT repository runs in opengl2 mode (slowly just like openarena), but if I switch to opengl1 it always freezes after the splash screen animation. q3lite (GLES 1.1) on a Pi 4 gets 70~80 fps for the same resolution.

How did you get q3lite? Built it yourself?

[cdev-tux]

Thanks. Now the questions:

I did a clean install and could not get either to run correctly, yet other's seem to run OpenArena fine (or Quake 3) without setting cl_renderer.

Are others inadvertently running cl_renderer 1?

Yes. Originally the opengl1 renderer was the default in ioquake3, but they changed to using the opengl2 renderer as default in 2016. Early versions of ioquake3 (and Quake III Arena itself) only had a single renderer and didn’t use the cl_renderer cvar.

The opengl2 renderer that Ioquake3 now uses as default requires OpenGL 3 for some of its features, so it won’t work well with the VC4/V3D driver which is OpenGL 2.1.

Mirror effects/portals don't seem to render correctly.

With the legacy GLES driver this can be fixed by setting ‘r_fastsky 0’, but there’s a performance hit. With the VC4 driver I haven’t been able to get the portals to render correctly with r_fastsky on or off, and with either OpenGL or GLES. Also, r_portalOnly has no effect.

I’m working on Pi 4 support for Q3lite and have the game working on a Pi 4 with SDL’s X11 driver. Running timedemo four at 720P (1280 x 720), the game benchmarks at 74 fps with OpenGL and 94 fps with OpenGL ES 1.1. These are early numbers and should improve over time. It's a large change to the codebase so it's going to take some time to finish up and test.

[MamiyaOtaru]

OpenArena: Default renderer is opengl2 and renders at about 20 fps for 1280x720. Switching to opengl1 makes things smooth at 60+ fps. Maybe MamiyaOtaru just neglected to mention that bit

yes this is correct. Using opengl1 as the renderer. Opengl2 presents issues like the wrong textures showing, or changing randomly. It's possibly related to the glitches I have with gzdoom, where all the menu textures are the same. It runs fine in software, but not in opengl (2). It does work with gzdoomLE, which is limited to opengl1. Is this a known thing with the pi4? Nice to have the supposed capability, but it seems a bit deficient

*edit* reading above it looks like it is at least expected with ioquake, if the new renderer does in fact try to make use of opengl3. Thanks for the explanation, and working on q3lite. Do you foresee good improvements over just using Buster's ioquake 3 with cl_renderer opengl1?

[SlySven]

Slight detour in the above thread - I code for a project (Mudlet the MUD Client) that uses antique OpenGL direct rendering - using pre-GLSL code from the OpenGL 1.4 era. We have, within the last couple of days (https://github.com/Mudlet/Mudlet/pull/2971) done something to close off the part of our MUD Client that uses the OpenGL (the 3D map) to allow the rest of the application to run on the Raspberry Pi.

The burning question I have is, what is the OpenGL that is now available in the latest Raspian (and I guess possibly other RPi distributions)? Is it an OpenGLES version {which is what I would expect for "embedded" type systems} or a full-blown OpenGL one? If it is the former then it MUST be a GLSL using system and if the latter then I guess it still is using a reasonably modern version that does not have the direct mode support that was phased out somewhere around OpenGL 2.0 .

In the medium term I would like to see our project switch to more up to date code but that will require me (or some other intrepid individual) getting a grip on how things are done with GLSL and shaders and stuff like that...

[Gavinmc42]

glxinfo reports things like this.

Code: Select all

   Vendor: Broadcom (0x14e4)
    Device: V3D 4.2 (0xffffffff)
    Version: 19.1.0
    Accelerated: yes
    Video memory: 1887MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Broadcom
OpenGL renderer string: V3D 4.2
OpenGL version string: 2.1 Mesa 19.1.0-devel
OpenGL shading language version string: 1.20

Tim's shadertoy demo shows GLSL is working
https://www.raspberrypi.org/forums/view ... 8&t=247036

The VC6 hardware is supposed to support GLES 3.2.
The OpenGL driver is a layer above OpenGLES 3.0?
Some GLES 3.1 code was done, but 3.0 is what is working now.
Mesa looks like it is currently using OpenGL 2.1 and shader 1.2 on the Pi4's

[bunklung]

Thanks. Now the questions:

I did a clean install and could not get either to run correctly, yet other's seem to run OpenArena fine (or Quake 3) without setting cl_renderer.

Are others inadvertently running cl_renderer 1?

Yes. Originally the opengl1 renderer was the default in ioquake3, but they changed to using the opengl2 renderer as default in 2016. Early versions of ioquake3 (and Quake III Arena itself) only had a single renderer and didn’t use the cl_renderer cvar.

The opengl2 renderer that Ioquake3 now uses as default requires OpenGL 3 for some of its features, so it won’t work well with the VC4/V3D driver which is OpenGL 2.1.

Mirror effects/portals don't seem to render correctly.

With the legacy GLES driver this can be fixed by setting ‘r_fastsky 0’, but there’s a performance hit. With the VC4 driver I haven’t been able to get the portals to render correctly with r_fastsky on or off, and with either OpenGL or GLES. Also, r_portalOnly has no effect.

I’m working on Pi 4 support for Q3lite and have the game working on a Pi 4 with SDL’s X11 driver. Running timedemo four at 720P (1280 x 720), the game benchmarks at 74 fps with OpenGL and 94 fps with OpenGL ES 1.1. These are early numbers and should improve over time. It's a large change to the codebase so it's going to take some time to finish up and test.

Thanks for all this info. I have been watching the Q3LITE thread, but there didn't seem like there was an update on any build instructions or binary to apt-get.

[bunklung]

OpenArena: Default renderer is opengl2 and renders at about 20 fps for 1280x720. Switching to opengl1 makes things smooth at 60+ fps. Maybe MamiyaOtaru just neglected to mention that bit

yes this is correct. Using opengl1 as the renderer. Opengl2 presents issues like the wrong textures showing, or changing randomly. It's possibly related to the glitches I have with gzdoom, where all the menu textures are the same. It runs fine in software, but not in opengl (2). It does work with gzdoomLE, which is limited to opengl1. Is this a known thing with the pi4? Nice to have the supposed capability, but it seems a bit deficient

*edit* reading above it looks like it is at least expected with ioquake, if the new renderer does in fact try to make use of opengl3. Thanks for the explanation, and working on q3lite. Do you foresee good improvements over just using Buster's ioquake 3 with cl_renderer opengl1?

Did you build this version ZDoom LE? car to share some detailed instructions with a noob
https://github.com/drfrag666/gzdoom/releases/tag/2.8.3a

[jdonald]

How did you get q3lite? Built it yourself?

Yeah cdev-tux has made it pretty straightforward, just sudo make-raspberrypi.sh; sudo make-raspberrypi.sh install and this barely takes any time on a Pi 4. There are aspects that could use some cleanup, but the script is fairly self-documenting so whatever you need to fix or tweak it gives a great starting point.

glxinfo reports things like this.

It also includes the GLSL ES version further down:

Code: Select all

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.1.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

If you disable the accelerated OpenGL driver in raspi-config or run LIBGL_ALWAYS_SOFTWARE=1 glxinfo it'll report capabilities as high as OpenGL 3.3, but this is Mesa's software renderer (slow).

If it is the former [GLES] then it MUST be a GLSL using system and if the latter [GL] then I guess it still is using a reasonably modern version that does not have the direct mode support that was phased out somewhere around OpenGL 2.0 .

It sounds like you're referring to the fixed-function pipeline. However, you also seem to assume that by the driver supporting OpenGL 2.1 you lose access to OpenGL 1.5. That is not the case. Your program can request and use an older GL profile.

With GLES things are a bit more complicated because recent versions of Mesa as used on Raspbian Buster have dropped support for OpenGL ES 1.x. Fortunately it turns out you can still access these functions and that was demonstrated with Wolfenstein Enemy Territory and (quite on-topic now) q3lite. This is discussed in raspberrypi/firmware#1171.

The more troublesome aspect of supporting GLES in the Pi ecosystem is that prior to the Pi 4 there were two different GLES implementations and it takes some effort to support both dynamically. Relatively few applications/frameworks (e.g. Minecraft Pi, JOGL/Processing, and Qt) have done so. If you need your code to run on a classic Pi or Pi Zero you'll have to deal with this split, while another option is to move forward with Mesa and expressly not support older boards.

A good place to ask these kinds of questions is the Graphics programming subforum. It garners more attention from the Raspberry Pi engineers than Gaming.

Welcome and good luck building out Mudlet.