I grabbed the source from this branch: https://github.com/drfrag666/gzdoom/tree/zdoomlebunklung wrote: ↑Fri Aug 16, 2019 12:33 pmDid you build this version ZDoom LE? car to share some detailed instructions with a noobMamiyaOtaru wrote: ↑Thu Aug 15, 2019 5:20 pmyes 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?
to compile on arm, change line 1272 of /src/p_spec.cpp from
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
static const char hexenScrollies =
static const signed char hexenScrollies =
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
This creates a zdoom executable that uses opengl 1. Possible to use xbrz scaling on the textures without a noticeable performance hit.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
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.