[Jblade]

EVENT_DISPLAYLOADINGSCREEN; I should try and pinpoint which snapshot the code stopped working in.

[Mblackwell]

Yes, but in the mean time try using EVENT_GETLOADTILE.

[gaula92]

Hi!

I have been using Eduke32 on the GNU/LInux PC for a while now, and I would love to see this awesome sourceport working in the best possible way on the Raspberry Pi 3.
So, it builds and works good (not perfect because framerate is unstable even with the uncapped framerate and vsync, with a CPU usage of ~40%: I guess the audio thread has something to do with that) using SDL2 and the software renderer: then SDL2 upscales any "internal" video mode (like 320x200) to full screen resolution with zero CPU usage, because SDL2 renders each frame internally as a GLES2 texture.
That's for the state of Eduke32 on the Pi/SDL2.

So, what about the polymer renderer? Well, it would need to use OpenGL_ES1/2. I believe for basic shader support GLES2 would be enough. Is there any intention to give polymer GLES1/2 support?
SDL2 can initialize GLES1/2 rendering context easily, so that part is "done", so to say.
That would enable Eduke3D polymer renderer to run on a variety of ARM platforms that only have GLES1/2 implementations and not desktop GL.

[Mark]

Our 2 Polymer guys have left the community. Chances of any updates or upgrades are slim to none for the foreseeable future.

[gaula92]

Mark., on 12 October 2017 - 07:33 AM, said:

Our 2 Polymer guys have left the community. Chances of any updates or upgrades are slim to none for the foreseeable future.

Oops, that's not too good...!
So, only the software renderer is being developed for the time being?

[TerminX]

No, there's an additional OpenGL 1.x renderer called Polymost. It works under GLES with a bit of effort.

[Jblade]

Mblackwell, on 12 October 2017 - 04:50 AM, said:

Yes, but in the mean time try using EVENT_GETLOADTILE.

No dice sadly, doesn't even show up using that.

[gaula92]

TerminX, on 12 October 2017 - 09:39 AM, said:

No, there's an additional OpenGL 1.x renderer called Polymost. It works under GLES with a bit of effort.

It does work or it "should" work? Would you give instructions for a SDL2+GLES build, please?

[Hendricks266]

I never made it to the point of actually hooking up Polymost on my RPi. Builds currently only use the software renderer. You'll need to add the jwzgles object to the Makefile, and add CUSTOMOPT="-DEDUKE32_GLES" to the Make invocation, but I'm still not sure that's everything you'll need.

[TerminX]

gaula92, on 13 October 2017 - 12:44 AM, said:

It does work or it "should" work? Would you give instructions for a SDL2+GLES build, please?

It "should" work. We got it working on Android with the addition of the extra object Hendricks266 mentioned, but we have not built for Android in over a year.

[gaula92]

Ok, I tried building with the POLYMOST renderer on the Pi3, but activating OPENGL support (which is what activates the basic POLYMOST renderer) seems to require GL/gl.h, which does not exist on the Pi and is usually present for desktop GL and not for GLES.

pi@raspberrypi:~/src/eduke32 $ make -j8 WITHOUT_GTK=1 USE_OPENGL=1 POLYMER=0 USE_LIBVPX=0 HAVE_FLAC=0 OPTLEVEL=3 LTO=0 OPTOPT="-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard" CUSTOMOPT="-DEDUKE32_GLES"      
In file included from source/build/include/build.h:23:0,
                 from source/duke3d/src/astub.cpp:24:
source/build/include/glbuild.h:28:20: fatal error: GL/gl.h: No such file or directory
 # include <GL/gl.h>
                    ^
compilation terminated.

What the Pi DOES have is /opt/vc/include/GLES/gl.h. Should I include that instead of GL/gl.h?

[Micky C]

Mark., on 12 October 2017 - 07:33 AM, said:

Our 2 Polymer guys have left the community. Chances of any updates or upgrades are slim to none for the foreseeable future.

Icecoldduke is officially gone now?

[Hendricks266]

gaula92, on 13 October 2017 - 06:37 PM, said:

What the Pi DOES have is /opt/vc/include/GLES/gl.h. Should I include that instead of GL/gl.h?

Change line 27 of glbuild.h from "#else" to "#elif !defined EDUKE32_GLES".

#if defined EDUKE32_OSX
# include <OpenGL/gl.h>
# include <OpenGL/glu.h>
#elif defined EDUKE32_IOS
# include <OpenGLES/ES1/gl.h>
#elif !defined EDUKE32_GLES
# include <GL/gl.h>
# include <GL/glu.h>
#endif

[gaula92]

Some advancements. Almost there I think.
-I have to build with:

make -j8 WITHOUT_GTK=1 USE_OPENGL=1 POLYMER=0 USE_LIBVPX=0 HAVE_FLAC=0 OPTLEVEL=3 LTO=0 OPTOPT="-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -lGLESv1_CM -L/opt/vc/lib" CUSTOMOPT="-DEDUKE32_GLES -DHAVE_JWZGLES"

..since jwzgles.cpp would not build without -DHAVE_JWZGLES

I also had to include

#include <SDL2/SDL_opengles.h>
#include <SDL2/SDL_opengl_glext.h>

in source/build/include/glbuild.h, because removing the GL/gl.h was leaving it without any GL or GLES headers and that caused a myriad of errors.

However, I still get:

In file included from source/build/src/polymost.cpp:19:0:
source/build/include/polymer.h:127:5: error: 'GLhandleARB' does not name a type
     GLhandleARB     handle;
     ^~~~~~~~~~~
source/build/src/polymost.cpp:643:45: error: 'GL_RGB5_A1' was not declared in this scope
 static int32_t const texfmts_rgb_mask[] = { GL_RGB5_A1, GL_RGBA, 0 };
                                             ^~~~~~~~~~
source/build/src/polymost.cpp:644:40: error: 'GL_RGB565' was not declared in this scope
 static int32_t const texfmts_rgb[] = { GL_RGB565, GL_RGB5_A1, GL_RGB, GL_RGBA, 0 };
                                        ^~~~~~~~~
source/build/src/polymost.cpp:644:51: error: 'GL_RGB5_A1' was not declared in this scope
 static int32_t const texfmts_rgb[] = { GL_RGB565, GL_RGB5_A1, GL_RGB, GL_RGBA, 0 };
                                                   ^~~~~~~~~~
source/build/src/polymost.cpp:645:41: error: 'GL_RGBA4' was not declared in this scope
 static int32_t const texfmts_rgba[] = { GL_RGBA4, GL_RGBA, 0 } ;
                                         ^~~~~~~~
source/build/src/polymost.cpp:656:45: error: 'GL_COMPRESSED_RGB8_ETC2' was not declared in this scope
 static int32_t const comprtexfmts_rgb[] = { GL_COMPRESSED_RGB8_ETC2, GL_ETC1_RGB8_OES, 0 };
                                             ^~~~~~~~~~~~~~~~~~~~~~~
source/build/src/polymost.cpp: In function 'uint64_t (* Polymost_PickETCFunction(int32_t))(const uint8_t*)':
source/build/src/polymost.cpp:684:14: error: 'GL_COMPRESSED_RGB8_ETC2' was not declared in this scope
         case GL_COMPRESSED_RGB8_ETC2:
              ^~~~~~~~~~~~~~~~~~~~~~~
source/build/src/mdsprite.cpp: In function 'int32_t mdloadskin(md2model_t*, int32_t, int32_t, int32_t)':
source/build/src/mdsprite.cpp:912:46: error: 'GL_BGRA' was not declared in this scope
         int32_t const texfmt = glinfo.bgra ? GL_BGRA : GL_RGBA;
                                              ^~~~~~~
source/build/src/polymost.cpp: In function 'int32_t gloadtile_hi(int32_t, int32_t, int32_t, hicreplctyp*, int32_t, pthtyp*, int32_t, polytintflags_t)':
source/build/src/polymost.cpp:1470:46: error: 'GL_BGRA' was not declared in this scope
         int32_t const texfmt = glinfo.bgra ? GL_BGRA : GL_RGBA;
                                              ^~~~~~~
source/build/src/mdsprite.cpp: In function 'int32_t polymost_md3draw(md3model_t*, const uspritetype*)':
source/build/src/mdsprite.cpp:2111:24: error: 'GL_TEXTURE0_ARB' was not declared in this scope
     int32_t texunits = GL_TEXTURE0_ARB;
                        ^~~~~~~~~~~~~~~
Failed building obj/build/mdsprite.o from source/build/src/mdsprite.cpp!
GNUmakefile:951: recipe for target 'obj/build/mdsprite.o' failed
make: *** [obj/build/mdsprite.o] Error 1
make: *** Waiting for unfinished jobs....
Failed building obj/build/polymost.o from source/build/src/polymost.cpp!

...which I don't get. Is the polymer include needed in polymost.cpp?
And, since glbuild.h is included in polymost.cpp, and I have also included SDL_opengl_glext.h (where GL_BGRA, 'GL_TEXTURE0_ARB, etc.. are defined), I shouldn't be getting those "not declared" errors...
Any more clues?

PD: I also tried manually copying the GL_BGRA, GL_TEXTURE0_ARGB, etc... defines from SDL_opengl_glext.h to mdsprite.cpp and polymost.cpp, and so I got eduke32 to compile, but I was still missing ProcessRGB and ProcessRGB_ETC2 (undefined reference on the linking phase). Removing the ProcessRGB* calls I got it to build but it would segfault on trying to setup the OpenGL renderer on the menu, with those:

OpenGL information
 Broadcom VideoCore IV HW OpenGL ES 2.0
Opened "textures" as cache file
glGetError 0x500
glGetError 0x501
glGetError 0x501
glGetError 0x502
glGetError 0x501
glGetError 0x501
Segmentation fault

[Hendricks266]

ProcessRGB is in source/etcpak/*. I don't know if the RPi GPU supports ETC1 though. Either way, removing just those calls would probably cause garbage to get passed in to the driver.

Add RELEASE=0 to the Make invocation to compile with debug symbols, and then you can use gdb to produce a backtrace of the segmentation fault.

[Micky C]

Is it just me, or is polymost slightly more stable with TROR?

[Danukem]

Micky C, on 14 October 2017 - 06:12 PM, said:

Is it just me, or is polymost slightly more stable with TROR?

Polymost is very stable even without TROR, so how could you tell if it is more stable with it? It seems like you would have to run about a million tests to verify that.

[Hendricks266]

Micky C, on 14 October 2017 - 06:12 PM, said:

Is it just me, or is polymost slightly more stable with TROR?

You might want to get that checked out.

[Micky C]

Trooper Dan, on 14 October 2017 - 06:51 PM, said:

Polymost is very stable even without TROR

Maybe stable was the wrong word.

What I meant was that I remember there being an issue where if you looked down through TROR in polymost, there'd be a visual glitch which somewhat resembled red line sector walls drawing masked walls. That glitch seems to be gone. Of course, polymost still has other issues with TROR which prevent it from being useful in anything but the simplest cases.

[Mblackwell]

Jblade, on 13 October 2017 - 12:34 AM, said:

No dice sadly, doesn't even show up using that.

Try removing the timing elements checking for tics and just increment a counter with that event. Like:

appendevent EVENT_GETLOADTILE
    ifvare LOAD_TRANSITION 0
    {
        readgamevar WHEEL1
        readgamevar WHEEL2
        setvarvar LOAD_TRANSITION 1
    }
   
    addvar WHEEL1 2
    ifvarg WHEEL1 2048 setvar WHEEL1 0
    rotatespritea 10 135 INVENSIZE WHEEL1 3228 20 12 256 -255 0 0 xdim ydim
    subvar WHEEL2 4
    ifvarl WHEEL2 -2048 setvar WHEEL2 0
    rotatespritea 10 135 QUARTERSIZE WHEEL2 3228 10 12 256 -255 0 0 xdim ydim
endevent
appendevent EVENT_ENTERLEVEL
    set LOAD_TRANSITION 0
endevent
  

You might need to draw the background yourself, but I'd try that anyway.

[Jblade]

Still no luck I'm afraid. Thanks for trying to help anyways, this just looks like a problem with something that got changed in a snapshot. I'll have to try and find out when it stopped working.

[gaula92]

After moving the etcpak stuff to source/build/src and source/build/include, I could #include "ProcessRGB.h" in polymost.cpp, and the ProcessRGB.cpp and Tables.cpp objects in GNUMakefile, and Eduke32 will compile and link with:

make -j8 RELEASE=0 WITHOUT_GTK=1 USE_OPENGL=1 POLYMER=0 USE_LIBVPX=0 HAVE_FLAC=0 OPTLEVEL=3 LTO=0 OPTOPT="-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -lGLESv1_CM -L/opt/vc/lib" CUSTOMOPT="-DEDUKE32_GLES -DHAVE_JWZGLES"

The good news is that, since I don't have to comment out the ProcessRGB* stuff anymore, there are no more segfaults.
The bad news is that I get a completely black screen with the OpenGL renderer. No surprise since I get those OpenGL error cores:

Setting video mode 640x480 (32-bpp windowed)
Refresh rate: 60Hz
polymost_glreset()
OpenGL information
 Broadcom VideoCore IV HW OpenGL ES 2.0
polymost_glreset()
Opened "textures" as cache file
glGetError 0x500
glGetError 0x501
glGetError 0x501
glGetError 0x502
glGetError 0x501
glGetError 0x501

Any idea on what's going on? If this polymost GLES renderer works on Android (GLES1/GLES2) it should work on the Pi...

[Kyanos]

https://www.khronos....ki/OpenGL_Error

This page says you can bypass the error checking, it also explains what each error code means, too bad there aren't line nums... I'd also try to disable the texture cache maybe.

[Hendricks266]

I updated the wiki article for Building EDuke32 on Windows to bring it into 2017. If you've wanted to check out how EDuke32 is built but have been intimidated, now is a good time to try.

[Hendricks266]

gaula92, on 15 October 2017 - 03:49 AM, said:

glGetError 0x500
glGetError 0x501
glGetError 0x501
glGetError 0x502
glGetError 0x501
glGetError 0x501

Any idea on what's going on? If this polymost GLES renderer works on Android (GLES1/GLES2) it should work on the Pi...

This is good progress, but unfortunately that log output (much like "Segmentation fault") provides almost no information about what is happening. Does running under gdb show anything more?

I wrote this function in glbuild.cpp:

GLenum BuildGLError;
void BuildGLErrorCheck(void)
{
    volatile GLenum err;
    while ((err = bglGetError()) != GL_NO_ERROR)
    {
        BuildGLError = err; // set a watchpoint/breakpoint here
    }
}

It is used in some places, but not all. There have been times in the past where I have considered following each and every applicable GL call with a call to this function for more effective debugging.

I have also heard of dedicated GL / GL ES debugging tools, but I have no experience with them.

The error is probably simple, since we were able to build and run Polymost under GL ES on both Android and iOS.

[gaula92]

This is exactly where the first error (0x500, which means GL_INVALID_ENUM according to https://www.khronos....ki/OpenGL_Error) happens:

757	    bglBindTexture(GL_TEXTURE_2D, tex);
(gdb) n 
759	    BuildGLErrorCheck(); // XXX: Clear errors.
(gdb) n
glGetError 0x500
761	    texfmt_rgb = Polymost_TryDummyTexture(pic, texfmts_rgb);
(gdb) bt
#0  Polymost_DetermineTextureFormatSupport () at source/build/src/polymost.cpp:761
#1  polymost_glinit () at source/build/src/polymost.cpp:410
#2  0x0013f9ec in setgamemode (davidoption=<optimized out>, daxdim=<optimized out>, daydim=<optimized out>, 
    dabpp=<optimized out>, dabpp@entry=32) at source/build/src/engine.cpp:9890
#3  0x000d63b0 in Menu_EntryLinkActivate (entry=0x1) at source/duke3d/src/menus.cpp:2800
#4  Menu_RunInput_EntryLink_Activate (entry=entry@entry=0x22c360 <ME_VIDEOSETUP_APPLY>)
    at source/duke3d/src/menus.cpp:5320
#5  0x000dcc64 in Menu_RunInput (cm=0x22cad4 <Menus+140>) at source/duke3d/src/menus.cpp:6026
#6  M_DisplayMenus () at source/duke3d/src/menus.cpp:6351
#7  0x000cbf90 in G_PlaybackDemo () at source/duke3d/src/demo.cpp:932
#8  0x00047018 in app_main (argc=<optimized out>, argv=<optimized out>) at source/duke3d/src/game.cpp:6590
#9  0x76a78678 in __libc_start_main (main=0x7efff794, argc=1991888896, 
    argv=0x76a78678 <__libc_start_main+276>, init=<optimized out>, fini=0x1f1bbc <__libc_csu_fini>, 
    rtld_fini=0x76fdf9b8 <_dl_fini>, stack_end=0x7efff794) at libc-start.c:291
#10 0x000378a8 in _start ()

Seems to happen on glBindTexture(GL_TEXTURE_2D, tex), in Polymost_DetermineTextureFormatSupport (), but I don't know how could a simple GL_TEXTURE_2D be a wrong enum...

[Hendricks266]

GL errors are maintained between commands until you pop them with glGetError(), so that GL_INVALID_ENUM could be coming from any GL function that was called up to that point. That's why I mentioned considering adding a call to BuildGLErrorCheck after every applicable GL call. For your purposes, it would be more worthwhile to look into a GL or GL ES debugging tool.

[gaula92]

I did some more investigation on this (GLES Polymost renderer on the Raspberry Pi).
I am now building with this line, to get proper debug symbols:

make -j8 RELEASE=0 WITHOUT_GTK=1 USE_OPENGL=1 POLYMER=0 USE_LIBVPX=0 HAVE_FLAC=0 OPTLEVEL=0 LTO=0 OPTOPT="-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -lGLESv1_CM -L/opt/vc/lib" CUSTOMOPT="-DEDUKE32_GLES -DHAVE_JWZGLES"

I have sorrounded every GL call with glGetError() and I am testing it's return value each time. The first glGetError return value of 0x500 (INVALID_ENUM) happens exactly on the glEnable(GL_TEXTURE_2D)
call in sdlayer_setvideomode_opengl(). bglEnable(GL_TEXTURE_2D) to be exact, since the call is abstracted for error testing.

I did a test to confirm: just after the GL context is created in setvideomode() (in sdlayer.cpp), just after

sdl_context = SDL_GL_CreateContext(sdl_window);

I added some simple GLES test calls:

           glClearColor(0,0,0,1);
           glClear(GL_COLOR_BUFFER_BIT);
           SDL_GL_SwapWindow(sdl_window);

They run fine, and I have sorrounded each with glGetError() calls which always returns 0 there.
BUT as soon as I add a

glEnable(GL_TEXTURE_2D)

I get a 0x500 (INVALID ENUM).
So glEnable(GL_TEXTURE_2D) is to blame, but I don't know why or what the problem could be.

osdcmd_glinfo(), however, detects the GLES implementation:

OpenGL information
 Broadcom VideoCore IV HW OpenGL ES 2.0

[TerminX]

Hmm... for some reason you're getting a GL ES 2.0 context when you need a GL ES 1.1 context.

[Hendricks266]

Find the following in setvideomode in sdlayer.cpp:

        struct glattribs
        {
            SDL_GLattr attr;
            int32_t value;
        } sdlayer_gl_attributes[] =
        {
#ifdef EDUKE32_TOUCH_DEVICES
              { SDL_GL_CONTEXT_MAJOR_VERSION, 1 },
              { SDL_GL_CONTEXT_MINOR_VERSION, 1 },
#endif
              { SDL_GL_DOUBLEBUFFER, 1 },
#ifdef USE_GLEXT
              { SDL_GL_MULTISAMPLEBUFFERS, glmultisample > 0 },
              { SDL_GL_MULTISAMPLESAMPLES, glmultisample },
#endif
              { SDL_GL_STENCIL_SIZE, 1 },
              { SDL_GL_ACCELERATED_VISUAL, 1 },
          };

Change the EDUKE32_TOUCH_DEVICES to EDUKE32_GLES.