Duke4.net Forums: EDuke32 2.0 and Polymer! - Duke4.net Forums

Jump to content

  • 213 Pages +
  • « First
  • 190
  • 191
  • 192
  • 193
  • 194
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 2.0 and Polymer!  "talk about the wonders of EDuke32 and the new renderer"

User is offline   Jblade 

#5731

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

User is offline   Mblackwell 

  • Evil Overlord

#5732

Yes, but in the mean time try using EVENT_GETLOADTILE.
0

User is offline   gaula92 

#5733

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

User is offline   Mark 

#5734

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

User is offline   gaula92 

#5735

View PostMark., 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. :rolleyes:


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

User is offline   TerminX 

  • el fundador

  #5736

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

User is offline   Jblade 

#5737

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

User is offline   gaula92 

#5738

View PostTerminX, 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?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5739

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

User is offline   TerminX 

  • el fundador

  #5740

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

User is offline   gaula92 

#5741

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?

This post has been edited by gaula92: 13 October 2017 - 06:40 PM

0

User is offline   Micky C 

  • Honored Donor

#5742

View PostMark., 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. :rolleyes:


Icecoldduke is officially gone now?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5743

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

0

User is offline   gaula92 

#5744

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

0

User is offline   Hendricks266 

  • Weaponized Autism

  #5745

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

User is offline   Micky C 

  • Honored Donor

#5746

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

User is offline   Danukem 

  • Duke Plus Developer

#5747

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

User is offline   Hendricks266 

  • Weaponized Autism

  #5748

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

User is offline   Micky C 

  • Honored Donor

#5749

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

User is offline   Mblackwell 

  • Evil Overlord

#5750

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

User is offline   Jblade 

#5751

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

User is offline   gaula92 

#5752

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

User is offline   Kyanos 

#5753

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

User is offline   Hendricks266 

  • Weaponized Autism

  #5754

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

User is offline   Hendricks266 

  • Weaponized Autism

  #5755

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

User is offline   gaula92 

#5756

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

User is offline   Hendricks266 

  • Weaponized Autism

  #5757

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

User is offline   gaula92 

#5758

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

0

User is offline   TerminX 

  • el fundador

  #5759

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

User is offline   Hendricks266 

  • Weaponized Autism

  #5760

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

Share this topic:


  • 213 Pages +
  • « First
  • 190
  • 191
  • 192
  • 193
  • 194
  • Last »
  • 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