[gaula92]

Hi there!

I am trying to build latest sources (2019 09 02) on GNU/Linux.
Trying to build without OpenGL (USE_OPENGL=0) causes major errors on building:

source/duke3d/src/game.cpp:804:9: error: 'renderSetRollAngle' was not declared in this scope
         renderSetRollAngle(0);
         ^~~~~~~~~~~~~~~~~~
source/duke3d/src/game.cpp:804:9: note: suggested alternative: 'renderSetTarget'
         renderSetRollAngle(0);
         ^~~~~~~~~~~~~~~~~~
         renderSetTarget
source/duke3d/src/game.cpp:956:17: error: 'renderSetRollAngle' was not declared in this scope
                 renderSetRollAngle(0);
                 ^~~~~~~~~~~~~~~~~~
source/duke3d/src/game.cpp:956:17: note: suggested alternative: 'renderSetTarget'
                 renderSetRollAngle(0);
                 ^~~~~~~~~~~~~~~~~~
                 renderSetTarget
source/duke3d/src/actors.cpp: In function 'void G_MoveEffectors()':
source/duke3d/src/actors.cpp:7619:21: error: 'benchmarkScreenshot' was not declared in this scope
                     benchmarkScreenshot = g_BenchmarkMode == BENCHMARKMODE_GENERATE_REFERENCE;
                     ^~~~~~~~~~~~~~~~~~~
Failed building obj/duke3d/game.o from source/duke3d/src/game.cpp!
Failed building obj/duke3d/actors.o from source/duke3d/src/actors.cpp!

[LeoD]

gaula92, on 06 September 2019 - 07:01 AM, said:

Trying to build without OpenGL (USE_OPENGL=0) causes major errors on building:

Broken as of r7219 (last November). No one has noticed or cared since then. Try an older source revision.

[Phredreeke]

I suspect this is due to eduke32 using OpenGL even in software mode to blit the rendered image to the screen (this also makes switching between software and OpenGL modes seamless since it doesn't have to switch to a different backend)

[LeoD]

Phredreeke, on 06 September 2019 - 11:47 AM, said:

I suspect this is due to eduke32 using OpenGL even in software mode to blit the rendered image to the screen (this also makes switching between software and OpenGL modes seamless since it doesn't have to switch to a different backend)

I suspect this is due to Voidpoint not having even the slightest form of automated regression testing in place.

[Phredreeke]

How many people actually use devices with no OpenGL support though?

[LeoD]

gaula92, on 06 September 2019 - 07:01 AM, said:

Trying to build without OpenGL (USE_OPENGL=0) causes major errors on building

Should be fixed as of r8082.

[gaula92]

@LeoD: Thanks!! It builds and works perfectly now without OpenGL.
Now, since my platform has OpenGL_ES 1 and 2 support (Raspberry Pi) via SDL2 on KMS/DRM, would it be possible to build with a GLES1 or GLES2 renderer?
I am doing:

make -j4 WITHOUT_GTK=1 POLYMER=1 USE_LIBVPX=0 HAVE_FLAC=0 OPTLEVEL=3 LTO=0 RENDERTYPESDL=1 HAVE_JWZGLES=1 USE_OPENGL=1 OPTOPT="-march=armv8-a+crc -mtune=cortex-a53"

But I get:

1 HAVE_JWZGLES=1 USE_OPENGL=1 OPTOPT="-march=armv8-a+crc -mtune=cortex-a53"
In file included from source/build/include/build.h:25,
                 from source/duke3d/src/global.h:26,
                 from source/duke3d/src/global.cpp:24:
source/build/include/glbuild.h:17:11: fatal error: GL/glu.h: No such file or directory
 # include <GL/glu.h>
           ^~~~~~~~~~
compilation terminated.
In file included from source/build/include/build.h:25,
                 from source/duke3d/src/player.h:26,
                 from source/duke3d/src/actors.h:26,
                 from source/duke3d/src/gamedef.h:28,
                 from source/duke3d/src/gamedef.cpp:23:
source/build/include/glbuild.h:17:11: fatal error: GL/glu.h: No such file or directory
 # include <GL/glu.h>
           ^~~~~~~~~~
compilation terminated.
Failed building obj/duke3d/global.o from source/duke3d/src/global.cpp!
make: *** [GNUmakefile:1057: obj/duke3d/global.o] Error 1
make: *** Waiting for unfinished jobs....
Failed building obj/duke3d/gamedef.o from source/duke3d/src/gamedef.cpp!
make: *** [GNUmakefile:1057: obj/duke3d/gamedef.o] Error 1
In file included from source/build/include/build.h:25,
                 from source/duke3d/src/duke3d.h:29,
                 from source/duke3d/src/game.cpp:25:
source/build/include/glbuild.h:17:11: fatal error: GL/glu.h: No such file or directory
 # include <GL/glu.h>
           ^~~~~~~~~~
compilation terminated.
In file included from source/build/include/build.h:25,
                 from source/duke3d/src/duke3d.h:29,
                 from source/duke3d/src/actors.cpp:25:
source/build/include/glbuild.h:17:11: fatal error: GL/glu.h: No such file or directory
 # include <GL/glu.h>
           ^~~~~~~~~~
compilation terminated.
Failed building obj/duke3d/game.o from source/duke3d/src/game.cpp!
make: *** [GNUmakefile:1057: obj/duke3d/game.o] Error 1
Failed building obj/duke3d/actors.o from source/duke3d/src/actors.cpp!
make: *** [GNUmakefile:1057: obj/duke3d/actors.o] Error 1

I see in Android.mk that GLES should be possible, since eduke32 is supposed to work on Android, which is OpenGL_ES land.

[Hendricks266]

I don't think anything has changed regarding GL ES support since the last time you asked about this.

[gaula92]

@Hendricks256: I see. I though it would be a good time to ask again, since @LeoD seemed to have fixed the software renderer so easily!

Why doesnt the GLES support receive some love? As I understand, its needed for the Android port to build, right? So Eduke32 isnt currentenly building for Android until GLES get fixed, does it?

[Phredreeke]

Android support was necessary for the Hail to the King collection, I suspect it's considered low priority after Gearbox shut that down.

[TerminX]

Phredreeke, on 11 September 2019 - 12:00 PM, said:

Android support was necessary for the Hail to the King collection, I suspect it's considered low priority after Gearbox shut that down.

Correct, it was never finished and the work was abandoned years ago.

[gaula92]

TerminX, on 11 September 2019 - 12:17 PM, said:

Correct, it was never finished and the work was abandoned years ago.

But GLES is not necessarily meant to run on Android. GLES on SDL2 is also the most common scenario in open-source oriented single-board computers. And GLES doesnt seem to be that hard to fix if one knows the engine code, since there is in fact OpenGL 1.x support already implemented, and I once had a semi-working GLES build too.

Also, it seems that, in software mode, 640x480 does not work either: it shows a garbled screen. As things are, software mode is too much for ARM CPUs in most SBCs.
Someone also asked for the possibility of having options to run the engine on lower specs hardware:
https://forums.duke4...linux-machines/
Well, letting it run in the original 320x200 mode in software would be a solution: SDL2 can upscale 320x200 to 1920x1080 using its internal GLES renderer, so it would be rock-solid 60FPS on a lot of SBCs where the engine is currently too slow.
The other solution would be, of course, make the eduke32 GLES renderers work again.

[Phredreeke]

Yeah, but I think there's little interest from Voidpoint's side to maintain a separate GLES Polymost. 320x200 software rendered upscaled through GLES sounds more feasible.

[gaula92]

Phredreeke, on 13 September 2019 - 11:12 AM, said:

320x200 software rendered upscaled through GLES sounds more feasible.

Well, its SO simple that you dont need touch any GLES-specific code! Just let the software renderer work in 320x200, and SDL2 will automagically scale the 320x200 frames to whatever crazy hi-res mode the system is using, by means of SDL2 internal GL/GLES/VULKAN/whatever accelerated renderer!! NO software scaling must be involved. You are abstracted from anything GL-related, thats SDL2 work.
And in turn, low-powered systems will run eduke32 fine. Small work, big gain (I guess fixing the 320x200 mode in software renderer is easy for someone who knows eduke32 code).

[gaula92]

Or maybe fixing 320x200 rendering is not so easy as I believe?