[Mister Sinister]

Okay, sorry to litter this thread with this garbage.
Turns out I was wrong: crane behavior is indeed the same, but it is very weird.
The thing is you can only drop down the first time crane picks you up. Trying to do that the second time doesn't seem to work.
If you saved your game before the crane picks you up, it kinda resets. I don't know if that was the same in the original game.
To illustrate here's a quick video using 6450, same thing happens in other builds as well:

[NUKEMDAVE]

Are there plans to make the PS4 controller work with EDuke32? I randomly happened to discover that I could control some programs on my PC with the controller while I was using my PC's USB port to charge its battery one night. I decided to launch EDuke32 and see what would happen. I was able to move up and down in the game menu, but that was about it.

[Hendricks266]

I don't know what API capabilities a PS4 controller has out of the box, but we will support it through Steam.

[Jblade]

I used to use getticks to animate something during the loading screen, but it doesn't seem to work anymore; the code still animates perfectly fine on the main menu and other places but during loading it now just seems to freeze up.

code is here:

  getticks curtick
  ifvare prevtick -1 
  setvar DISPLAY_TEMP 0
  else
  {
    readgamevar WHEEL1
    readgamevar WHEEL2
    setvarvar DISPLAY_TEMP curtick
    subvarvar DISPLAY_TEMP prevtick
  }
  
  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


  setvarvar prevtick curtick
  

it's not a massive issue of course, but just curious if it's a bug or if I need to change something. The readgamevar is there because I coded in a transition effect when a level is ending and it basically reads the position of the animation so it was seamless between gameplay and the level load.

[Mblackwell]

This code is executed in which event?

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