Open jeremyvisser opened 6 years ago
Hello,
Thank you for your feedback. It’s very timely as I’m currently researching the steps necessary to add support for the OpenGL+KMS driver. If you haven’t seen it, I also have an open request for help in the Contributing Guide for implementing Mesa driver support. The renderer used in Q3lite was borrowed from another project, so I don’t have the expertise to make modifications to the renderer itself. However, I’m looking into adding the framework to allow switching renderers, which will make it more modular and easier for testing.
Another user mentioned that he compiled Q3lite for the Mesa driver (dtoverlay=vc4-kms-v3d), and that he had to replace -lGLESv2 with -lGLESv1_CM to fix linker errors (the Q3lite renderer uses OpenGL ES v1.1). He mentioned that the menus weren’t visible and the rendering was choppy at 1080P. You may also want to try without the -lGL and see if that makes a difference.
Any help and feedback that you can offer would be much appreciated. Thanks again.
Thank for your try. Can you code the game and run in the window? I think sdl is for console only and it is not frandly with desktop environment.
I hope it will be batter.😃
I'll have to look at the code when I get to that point, but I should be able to get it running in a window.
I’ve added the initial framework to support the VC4 OpenGL driver. More changes to follow.
Given so much has changed from Mesa 13 to Mesa 19 I gave this a try on my Pi 3B+ with Buster. Apparently it's fixed now (menus, crosshair, health status, and ~ pull-down console all render). This could be due to fixes in Mesa or one of the recent merges from ioq3 upstream.
I validated under both windowed mode in X11 and KMSDRM.
As @cdev-tux pointed out this is OpenGL ES 1.1, not 2.0, so the proper patch is:
diff --git a/Makefile.q3lite b/Makefile.q3lite
index d8521dec..6e2f57b2 100644
--- a/Makefile.q3lite
+++ b/Makefile.q3lite
@@ -149,15 +149,7 @@ endif
PI_CFLAGS=-march=armv8-a+crc -mfpu=vfpv4 -mtune=cortex-a53
endif
CFLAGS += -DHAVE_GLES $(PI_CFLAGS) -mfloat-abi=hard -Ofast -I/opt/vc/include
- ifneq ($(wildcard /opt/vc/lib/libbrcmEGL.so),)
- ifneq ($(wildcard /opt/vc/lib/libbrcmGLESv2.so),)
- LDFLAGS += -L/opt/vc/lib -lbrcmEGL -lbrcmGLESv2
- else
- LDFLAGS += -L/opt/vc/lib -lEGL -lGLESv2
- endif
- else
- LDFLAGS += -L/opt/vc/lib -lEGL -lGLESv2
- endif
+ LDFLAGS += -lEGL -lGLESv1_CM
endif #ifneq ($(PLATFORM_TYPE),)
Note that we retain -I/opt/vc/include
in compiler flags intentionally. Using /opt/vc/include/GLES
is a workaround for Buster's removal of the GLES1 headers despite linking with Mesa's libGLESv1_CM.so
. See raspberrypi/firmware#1171.
@jdonald Thank you for taking the time to look into this. I’ll be testing the code over the next few days on a fresh install of Buster, since my current install may have some added packages that are preventing things from working properly. I did find that SDL was attempting to use its RPI legacy driver on the Pi4, which won’t work so they have some updating to do as well. Thanks again for your time and effort.
Given so much has changed from Mesa 13 to Mesa 19 I gave this a try on my Pi 3B+ with Buster. Apparently it's fixed now (menus, crosshair, health status, and ~ pull-down console all render). This could be due to fixes in Mesa or one of the recent merges from ioq3 upstream.
I validated under both windowed mode in X11 and KMSDRM.
As @cdev-tux pointed out this is OpenGL ES 1.1, not 2.0, so the proper patch is:
diff --git a/Makefile.q3lite b/Makefile.q3lite index d8521dec..6e2f57b2 100644 --- a/Makefile.q3lite +++ b/Makefile.q3lite @@ -149,15 +149,7 @@ endif PI_CFLAGS=-march=armv8-a+crc -mfpu=vfpv4 -mtune=cortex-a53 endif CFLAGS += -DHAVE_GLES $(PI_CFLAGS) -mfloat-abi=hard -Ofast -I/opt/vc/include - ifneq ($(wildcard /opt/vc/lib/libbrcmEGL.so),) - ifneq ($(wildcard /opt/vc/lib/libbrcmGLESv2.so),) - LDFLAGS += -L/opt/vc/lib -lbrcmEGL -lbrcmGLESv2 - else - LDFLAGS += -L/opt/vc/lib -lEGL -lGLESv2 - endif - else - LDFLAGS += -L/opt/vc/lib -lEGL -lGLESv2 - endif + LDFLAGS += -lEGL -lGLESv1_CM endif #ifneq ($(PLATFORM_TYPE),)
Note that we retain
-I/opt/vc/include
in compiler flags intentionally. Using/opt/vc/include/GLES
is a workaround for Buster's removal of the GLES1 headers despite linking with Mesa'slibGLESv1_CM.so
. See raspberrypi/firmware#1171.
I'm still having some issues getting this to run in X11. When you have time could you post a /condump from the game console so I can see the output of the game loading? Thanks.
Sorry for the delayed response.
By default, Raspbian compiles SDL2 with both rpi and x11 video support, but not kmsdrm. I expect they're going to keep rpi
for a while as Raspbian needs to support the Pi 1 and Pi Zero. When debugging though, it's unfortunate that it comes earlier in the alphabet.
As for what's causing your issues: q3lite's build process appears to default to give the binary a linker path to a locally built SDL2 (/usr/local/lib
), so for testing I would often override that at runtime. For example:
cd /usr/local/games/quake3
LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf ./quake3.armv7l
Sometimes I pass SDL_VIDEODRIVER=x11
explicitly to ensure it doesn't try rpi
, but that isn't necessary as SDL2 will figure out what to do when running from an X session.
To double-check that it's always calling the particular libSDL2.so (and other libraries) you're intending, I recommend often using the ldd
command.
cd /usr/local/games/quake3
LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf ldd ./quake3.armv7l
Note that due to the excess use of sudo
in the /usr/local/bin/q3lite
script, environment variables (including DISPLAY
) get unintentionally dropped. I rarely use the q3lite wrapper script due to such issues.
When running X11 in full screen the stdout text (not a condump, but gets the point across) has what you'd expect:
...
----- Client Initialization Complete -----
----- R_Init -----
SDL using driver "x11"
For testing kmsdrm, that isn't available in the default Raspbian install so I would build a local SDL2 with:
sudo apt install libdrm-dev libgbm-dev
./configure --enable-video-kmsdrm --disable-video-x11 --disable-video-rpi
And of course occasionally check with ldd
to make sure your quake3.armv7l is loading the right libSDL2.so.
Thanks for your response. Setting LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf
allows the game to run in X11. I didn’t realize that Buster has an SDL2 package installed by default. Apparently my issue was caused by not compiling SDL2 with the proper settings.
For testing I’ve been compiling the latest SDL2-2.0.10 and using that instead of the shared library installed by Q3lite. This can be done by setting the following in make-raspberrypi.sh.
USE_LOCAL_HEADERS=0
Q3LITE_INSTALL_SDL=0
In the past Q3lite hasn’t been able to use the SDL2 package in the Raspbian repo because that package is compiled to use X11 first, and the game hasn’t been using X11 for performance reasons. If SDL2 is compiled from source it places libs in /usr/local/lib
by default. Q3lite places its own compatible SDL2 shared library in /usr/local/lib/q3lite
and uses rpath to look there first for SDL2, then in /usr/local/lib
second. This has been necessary due to a Raspberry Pi specific SDL2 bug that affected 2.0.4+ and wasn’t fixed until 2.0.9. Anyway, that’s some background as to why paths are set up the way they are. It’s unlikely that I’ll be able to use the SDL2 package from the repository as the game needs to support OpenGL, legacy GLES, X11, and KMSDRM on a Pi 0-4. That’s not going to be an easy task.
I came to the same conclusion as you about using sudo in the wrapper script. I plan to remove that code while I’m in there adding Pi 4 support.
Things are working in KMSDRM, although at a low framerate for now.
Thanks again for your help; that got me going in the right direction.
The VC4 driver for Raspberry Pi allows use of Mesa instead of Broadcom-specific GL APIs.
Firstly, Q3lite runs normally and as expected with the default Broadcom GL libraries. But I wanted to run Q3lite with the VC4 driver, so I did this by first configuring my system to use VC4, then modifying the Makefile like so:
Exactly how correct this approach was I'm unsure (having no GL experience whatsoever) but it at least compiled.
I ran it within an X11 session with the following parameters:
The game started, and I could see the map and walk around, but all 2D things were missing from the display, like my crosshair, health status, and the pull-down console.
I ran the game through
apitrace
and noticed the following errors:According to the documentation, it appears the
glOrthof()
function doesn't exist in OpenGL ES 2.0, and hence not Mesa, but for some reason is included in the Broadcom ES 2.0 library anyway:I've attached the apitrace file. I'm not sure how portable this file is, but it reproduces the graphical issue nicely on my laptop with Intel graphics:
quake3.invisible.trace.gz
As VC4 is the long-term future of graphics on the Raspberry Pi, using more standard components of the Linux graphics stack (Mesa, DRM, KMS), it will be good to get Q3lite working in this situation.