Duke4.net Forums: Building without OpenGL - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Building without OpenGL  "Compilation errors building with software-only renderer"

User is offline   gaula92 

#1

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!

0

User is offline   LeoD 

  • Duke4.net topic/3513

#2

View Postgaula92, 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.
1

User is online   Phredreeke 

#3

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)
0

User is offline   LeoD 

  • Duke4.net topic/3513

#4

View PostPhredreeke, 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.
0

User is online   Phredreeke 

#5

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

User is offline   LeoD 

  • Duke4.net topic/3513

#6

View Postgaula92, 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.
0

User is offline   gaula92 

#7

@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.

This post has been edited by gaula92: 09 September 2019 - 10:47 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #8

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

User is offline   gaula92 

#9

@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?
0

User is online   Phredreeke 

#10

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

This post has been edited by Phredreeke: 11 September 2019 - 12:00 PM

1

User is offline   TerminX 

  • el fundador

  #11

View PostPhredreeke, 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.
0

User is offline   gaula92 

#12

View PostTerminX, 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.

This post has been edited by gaula92: 13 September 2019 - 10:14 AM

0

User is online   Phredreeke 

#13

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.
0

User is offline   gaula92 

#14

View PostPhredreeke, 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).

This post has been edited by gaula92: 14 September 2019 - 10:56 AM

0

User is offline   gaula92 

#15

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

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options