OpenArena and Other OpenGL Games RPI 4

[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?

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

I grabbed the source from this branch: https://github.com/drfrag666/gzdoom/tree/zdoomle
prerequisites IIRC:

Code: Select all

apt-get -s install --no-install-recommends cmake libsdl2-dev libbz2-dev libjpeg-dev libfluidsynth-dev libgme-dev libopenal-dev libmpg123-dev libsndfile1-dev libgtk-3-dev timidity nasm libgl1-mesa-dev libsdl1.2-dev libglew-dev

to compile on arm, change line 1272 of /src/p_spec.cpp from
static const char hexenScrollies[24][2] =
to
static const signed char hexenScrollies[24][2] =
Also I used gcc 4.9 to compile (gcc 8 at least would not do it). install gcc/g++ 4.9 from the repos with apt-get
In the main gzdoomle directory, create a build directory (should end up with a build directory next to the src directory, tools dir, zlib dir etc). cd into build. There run

cmake .. -DNO_FMOD=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS:="-DNO_SSE" -DCMAKE_C_COMPILER=gcc-4.9 -DCMAKE_CXX_COMPILER=g++-4.9
make -j4

This creates a zdoom executable that uses opengl 1. Possible to use xbrz scaling on the textures without a noticeable performance hit.

BUT it takes ages to start, ages to switch into fullscreen (and fails at it, just occupies the bottom right corner for me) and is barely any faster than running https://github.com/drfrag666/gzdoom/tree/g3.3mgw (aka lzdoom) in software mode. The latter starts and runs in opengl mode, but all the UI textures are messed up (they all use the same texture on any given screen, making menus impossible to read for instance). see
http://chattypics.com/files/20190802212 ... 8dntwv.png
http://chattypics.com/files/20190802212 ... 67sy5d.png
http://chattypics.com/files/20190802212 ... hyclgq.png
http://chattypics.com/files/20190802212 ... qg0ve8.png
I'd love to know why, as it is limited to opengl2, and the pi 4 can supposedly handle that. Same results with gzdoom-legacy, raspzdoom etc. All those newer versions at least don't require any source code changes or non default gcc to compile like gzdoomle did.

[Gavinmc42]

0AD did need more ram, it runs on my new 2GB Pi4, it does not run on 1GB Pi's.
Only played a few minutes but it feels just a good as my old Celeron Mint box.
Might need a bit more memory tweaks, "free" did not show much left.

Need another stress test game - Flightgear?
Linux Combat Sim ran and crashed

[jdonald]

[On q3lite] Do you foresee good improvements over just using Buster's ioquake 3 with cl_renderer opengl1?

I mentioned somewhere in this thread that for Quake 3 Arena + opengl1, ioquake3 hangs after the splash animation even though OpenArena doesn't have the same problem. And quake3 + opengl2 has the same slowdown issue as OpenArena.

It's probably some trivial bug but until it's resolved, q3lite has the advantage of actually running. Or are you able to get further with quake3 (from the Buster repos) + opengl1?

[bunklung]

[On q3lite] Do you foresee good improvements over just using Buster's ioquake 3 with cl_renderer opengl1?

I mentioned somewhere in this thread that for Quake 3 Arena + opengl1, ioquake3 hangs after the splash animation even though OpenArena doesn't have the same problem. And quake3 + opengl2 has the same slowdown issue as OpenArena.

It's probably some trivial bug but until it's resolved, q3lite has the advantage of actually running. Or are you able to get further with quake3 (from the Buster repos) + opengl1?

Mine does not hang. I installed from Buster repos. As long as I launch with opengl1 it's very smooth.

Code: Select all

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

[jdonald]

Thanks. I investigated further, and it worked in opengl1 after I nuked my ~/.q3a directory. It must have been corrupted or cached a bad setting from my earlier testing.

[MamiyaOtaru]

just FYI opengl2 renderer seems to work now after the september updates. The framerate is abysmal though. It's like some opengl2 function is not working in hardware and is emulated (correctly now!) in software or something. Twice to three times the framerate with opengl1 renderer. I'll be sticking with that. It is a bit more dull, the lighting is more vibrant in opengl2. OTOH that could be some additional bling setting, which if turned off, could bring the FPS in opengl2 up to par with opengl1. Might be worth investigating.

[leilei]

No, the overbright lighting wouldn't harm performance. the gl1 renderer neglected to fix that regression for over a decade, which could be approached in many ways:

- Dropping a blended quad on top of the viewplane
- Multitexture combine ops
- GLSL postprocess shader

but nah ¯\_(ツ)_/¯