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

[gaula92]

@ Hendricks266: That did it! Now polymost renderer works... more or less. After I play around for a while, textures start to get "swapped": I mean, strange things start to happen, like letters in the menu changed ("PRUVS SPVVCU TV STUURT"), objects fly around, etc...
However, are you appliying the changes I did so Polymost is available on the Pi? Isn't there no way to have Polymer since the Pi is GLES2 compatible?

[Hendricks266]

Cool! Unfortunately our hardware accelerated graphics systems are all overdue for overhauls, including the texture manager. What happens if you `rm textures textures.cache` and enter `r_texcache 0` in EDuke32's console? `r_texcompr 0` might be something else to try.

Polymer relies on a large set of GL 3.0+ features and GL extensions that are beyond the scope of jwzgles. Neither TerminX nor I have any experience in that level of graphics programming, or the GL or GL ES APIs. I would be surprised if a Pi or a smartphone could manage 10 fps running Polymer, anyway.

[PsychoGoatee]

Not sure if this belongs here or in a bug thread, but I noticed something a bit odd in Polymer. Level geometry being slightly warped and textures lining up less, in Hollywood Holocaust for example.

Right where you land, I noticed how the shadow shaded portion "moves" and lines up less, compared to the Polymost or Classic screenshots of the same place.

First screen is Polymost, second is Classic, third is Polymer (the one with the warped/misaligned issue). In the latest version, 6488, on Window 10 with latest NVIDIA driver. Most noticeable in the black lines of the wood floor.

Attached thumbnail(s)

• 
• 
• 

[Mark]

I don't see a diff in the screenshots. But from your description it might be the 2 parameters for the texture's normal map need tweaking. The wrong values can cause the texture to slightly shift as you move. That would show only in Polymer.

[PsychoGoatee]

Screens one and two look the same (except Polymost having different lighting), but if you load up 2 and 3 (called duke0004.png) in different browser tabs and flip between them, you can see the difference. Look at the black line of the wood right where the shadow meets the lighter area of the floor. The black lines show up as misaligned/warped, most noticeable in the two planks of wood closer to Duke, lined up with the shadow area. Sounds like you may be onto the underlying cause though, this doesn't involve you moving though.

[Hendricks266]

PsychoGoatee, on 17 October 2017 - 06:32 PM, said:

Screens one and two look the same (except Polymost having different lighting), but if you load up 2 and 3 (called duke0004.png) in different browser tabs and flip between them, you can see the difference. Look at the black line of the wood right where the shadow meets the lighter area of the floor. The black lines show up as misaligned/warped, most noticeable in the two planks of wood closer to Duke, lined up with the shadow area. Sounds like you may be onto the underlying cause though, this doesn't involve you moving though.

Polymer doesn't always get texture mapping exactly right.

[gaula92]

Hendricks266, on 17 October 2017 - 02:05 PM, said:

Cool! Unfortunately our hardware accelerate graphics systems are all overdue for overhauls, including the texture manager. What happens if you `rm textures textures.cache` and enter `r_texcache 0` in EDuke32's console? `r_texcompr 0` might be something else to try.

Polymer relies on a large set of GL 3.0+ features and GL extensions that are beyond the scope of jwzgles. Neither TerminX nor I have any experience in that level of graphics programming, or the GL or GL ES APIs. I would be surprised if a Pi or a smartphone could manage 10 fps running Polymer, anyway.

Doing those brings no changes... The game starts fine, but it goes crazy after a while (when I get to the upper part of the cinema on the first map it's already full of strange phenomenoms).
Anyway, this Polymost renderer uses A LOT of CPU, like a whole core at 100% all the time. Software renderer is way faster, it's 60FPS with uncapped framerate and vysnc on, but the only problem is that it's not totally smooth like, let's say, GZDoom in software mode with uncapped framerate and vsync on.

[Hendricks266]

Sounds like Polymost. I think it's something I'll be able to address fairly soon.

I wonder, does Classic run any better if you run with `SDL_RENDER_DRIVER=software ./eduke32`? Or `export SDL_RENDER_DRIVER=software` in your terminal session before launching EDuke32.

[gaula92]

Hendricks266, on 18 October 2017 - 10:27 AM, said:

Sounds like Polymost. I think it's something I'll be able to address fairly soon.

I wonder, does Classic run any better if you run with `SDL_RENDER_DRIVER=software ./eduke32`? Or `export SDL_RENDER_DRIVER=software` in your terminal session before launching EDuke32.

I have just tested that. The result is that the game appears unscaled on a coner of the screen (SDL2 on the Pi is NOT supposed to run on a desktop enviroment but on fullscreen framebuffer instead: SDL2 provides the 2D subsystems, an interface to dispmanx, for the SDL2 GLES renderer to draw on. NOT to be confused with the eduke3D GLES renderer).
Other than that, it performs worse.

Without that, the classic renderer works well but has hiccups: that's to be expected because it's using ~88% CPU according to TOP. That high CPU usage comes from the fact that eduke3d classic renderer renders 640x480 frames: a 320x200 or 320x240 video mode should exist so eduke3d would render the frames INTERNALLY at the original game's resolution, and then let SDL2 scale to fullscreen using it's GLES renderer.
It's currently scaling the 640x480 frames, but it doesn't look as good as a 320x200 internal frame scaled to fullscreen physical resolution with a bilinear filter on it.
A matter of taste I guess, but the 320 video modes would be more optima CPU-wise for platforms like the Pi: NO software scaling at all should be done on such systems.
In fact, I seem to recall there was a 320x200 or 320x240 video mode time ago...

Producing internal frames at original game's resolution AND letting SDL2 do the scaing in hardware is what other engines do, like SDLPoP (Prince of Persia open source clone), RAWGL (Another World) or GZDoom. This aproximation works great and guarantees low CPU usage and perfect framerates without hiccups.

Also, if I set FULLSCREEN ON on the graphics menu, the APPLY CHANGES option is greyed out, as if eduke3d would be detecting (wrong) that the Pi is unable of fullscreen SDL2 window... but in fact it's the ONLY type of SDL2 window it supports!

[Hendricks266]

gaula92, on 18 October 2017 - 12:22 PM, said:

I have just tested that. The result is that the game appears unscaled on a coner of the screen

Sounds like if you ran at your display's native resolution, it would fill the screen, but if already performs worse then there's no point.

gaula92, on 18 October 2017 - 12:22 PM, said:

Without that, the classic renderer works well but has hiccups: that's to be expected because it's using ~88% CPU according to TOP. That high CPU usage comes from the fact that eduke3d classic renderer renders 640x480 frames: a 320x200 or 320x240 video mode should exist so eduke3d would render the frames INTERNALLY at the original game's resolution, and then let SDL2 scale to fullscreen using it's GLES renderer.
It's currently scaling the 640x480 frames, but it doesn't look as good as a 320x200 internal frame scaled to fullscreen physical resolution with a bilinear filter on it.
A matter of taste I guess, but the 320 video modes would be more optima CPU-wise for platforms like the Pi: NO software scaling at all should be done on such systems.
In fact, I seem to recall there was a 320x200 or 320x240 video mode time ago...

I'm not sure if you're coming from a Doom background or an emulator perspective, but right now the resolution sent to classic is used for rendering itself. Type `vidmode 320 240` into the console, take a screenshot, scale it up in an image editor to 640x480 using nearest neighbor filtering, and compare it with a screenshot in the same place at 640x480. We currently do no scaling of our own.

Your concept of "the original game's resolution" is not quite right. Even on DOS, the setup utility lets you increase the resolution (and therefore the quality of the rendering) up to 800x600, and I believe higher resolutions up to 1600x1200 are possible with varying degrees of stability if you have the right hardware.

gaula92, on 18 October 2017 - 12:22 PM, said:

Producing internal frames at original game's resolution AND letting SDL2 do the scaing in hardware is what other engines do, like SDLPoP (Prince of Persia open source clone), RAWGL (Another World) or GZDoom. This aproximation works great and guarantees low CPU usage and perfect framerates without hiccups.

Adding support for letting the user configure internal resolution vs. output scaling (done with the graphics hardware if at all possible) is on our roadmap. As you say, it's a reasonable compromise to decrease quality in exchange for higher framerate.

gaula92, on 18 October 2017 - 12:22 PM, said:

Also, if I set FULLSCREEN ON on the graphics menu, the APPLY CHANGES option is greyed out, as if eduke3d would be detecting (wrong) that the Pi is unable of fullscreen SDL2 window... but in fact it's the ONLY type of SDL2 window it supports!

That might be a problem with SDL's reporting of which resolutions support fullscreen, or it might be a side effect of how we currently set up our video mode information that will go away once it is overhauled.

[TerminX]

The apply button gets greyed out when the mode to be applied matches what's currently in use.

[Phredreeke]

What about the option in the classic renderer to pixel double?

Kinda surreal to have the Polymost strain the CPU more than the Classic renderer.

Is the classic renderer multithreaded, and if not, would it be possible to divide the screen in 2-3 slices, allowing one core for each slice?

[Hendricks266]

Phredreeke, on 18 October 2017 - 12:51 PM, said:

What about the option in the classic renderer to pixel double?

Overall it saves performance but I believe there is some aspect of software scaling there.

Phredreeke, on 18 October 2017 - 12:51 PM, said:

Kinda surreal to have the Polymost strain the CPU more than the Classic renderer.

I can see it happening for small resolutions, and possibly big ones with lots of stuff going on.

Phredreeke, on 18 October 2017 - 12:51 PM, said:

Is the classic renderer multithreaded, and if not, would it be possible to divide the screen in 2-3 slices, allowing one core for each slice?

Here is a list of everything we multithread right now:
1. Audio mixing (since it was a requirement for DirectSound)

That's it, and it's a huge problem for us.

I'm not entirely sure whether the algorithm is amenable to splitting like that, because I believe to some extent there would be duplication of work. I suspect there may be some low-hanging fruit in terms of SIMD vectorization, but I'm not familiar enough with either the instructions themselves or the renderer to know for sure.

[gaula92]

@Hendricks266: I tried "vidmode 320 240", and alongside

SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear")

before the SDL_CreateRenderer call, I get 320x240 frames being scaled up in hardwate to my monitor's full 1360x768 using SDL2 (which uses it's own GLES2 renderer).
I think I understand what you say: the engine produces actual 640x480 frames, etc... so that's what the engine really renders, not an upscaling.

However, even with as few pixels as 320x240, I can see some BIG peaks on CPU usage by the eduke32 process no other engine I have here shows on the Pi: CPU usage goes from 30% to 100% on several of the four cores! That's the cause of the hiccups. It doesn't seem to be scaling I guess, so I don't know what else to try.

[Micky C]

I have a map that's recently been crashing mapster. There's a lot of sprites on screen at once, and the crash happens when you go into 3D mode and pick a view where a lot of sprites are visible.

Here's something of interest from the log: exit(8) at source/build/src/sdlayer.cpp:344 in sighandler()

I also get a window that pops up saying:

Assertion failed!

Program: ....\mapster32.debug.exe
File: source/build/src/engine.cpp, Line 12057

Expression: windowxy2.x < xdim

[Hendricks266]

Could you send us the map in PM with the start point set so that entering 3D mode immediately will cause it?

[Micky C]

It's "mickybegins.map" in the AMC TC SVN.

[gaula92]

@Hendricks266: Do you have any idea on what could be using SO much CPU from time to time in Eduke32 on the PI? (In software mode)
There's no better sourceport, and I'd like to see it running smoothly on the platform...

[enderandrew]

gaula92, on 26 October 2017 - 06:50 AM, said:

@Hendricks266: Do you have any idea on what could be using SO much CPU from time to time in Eduke32 on the PI? (In software mode)
There's no better sourceport, and I'd like to see it running smoothly on the platform...

Wouldn't a software renderer not only put the main game logic on the CPU, but also all the renderering?

And the Pi isn't a particularly strong CPU to begin with.

[Jblade]

Quick question, what does:

Internal compiler error at 737782 (0x00000000000b41f6)
Internal compiler error at 737721 (0x00000000000b41b9)

mean in the eduke32.log? My code compiles fine and there's nothing wrong in game, but still.

[gaula92]

enderandrew, on 26 October 2017 - 05:42 PM, said:

Wouldn't a software renderer not only put the main game logic on the CPU, but also all the renderering?

And the Pi isn't a particularly strong CPU to begin with.

That's not the case, since the CPU usage is not constant. Sometimes it's ~30% and others it's 100% of several cores. Something is going on.

[Hendricks266]

Jblade, on 27 October 2017 - 12:52 AM, said:

Quick question, what does:

Internal compiler error at 737782 (0x00000000000b41f6)
Internal compiler error at 737721 (0x00000000000b41b9)

mean in the eduke32.log? My code compiles fine and there's nothing wrong in game, but still.

Is there any way to reproduce this?

[Jblade]

No idea, I wish I made more information on when it started appearing but it just appears in the log file all the time:

EDuke32 r6488
Built Oct 16 2017 14:22:05, GCC 7.2.0, 64-bit 
Using E:/AMC_TC/ for game data
Running on Windows 10 (build 10.0.10586)
Initializing SDL 2.0.6
Searching for game data...
Using "DUKE3D.GRP" as main game data file.
Using file "AMCTC.grp" as game data.
Compiling: GAME.CON (531136 bytes)
Including: USER.CON (0 bytes)
Including: DEFS.CON (0 bytes)
Including: CODE/AMCVARS.CON (52362 bytes)
Including: CODE/AMCDEFS.CON (188636 bytes)
Including: CODE/AMCUSER.CON (274990 bytes)
Including: CODE/AMC_EPS.CON (21378 bytes)
Including: AMC_Settings.txt (3076 bytes)
Including: CODE/AMC_SUBTITLES.CON (296628 bytes)
Including: CODE/getzrange.con (1494 bytes)
Including: CODE/PSTATS.CON (824405 bytes)
Including: CODE/EBIKE.CON (20593 bytes)
Including: CODE/AMCEXTRA.CON (567825 bytes)
Including: CODE/AMCSTEPS.CON (42565 bytes)
Including: CODE/AMCWEPS.CON (911133 bytes)
Including: CODE/AMCENEMY.CON (645978 bytes)
Including: CODE/AMC_COM.CON (260782 bytes)
Including: CODE/AMCCOMP.CON (1076743 bytes)
Including: CODE/AMCSCENE.CON (83883 bytes)
Including: CODE/AMCALLY.CON (183680 bytes)
Including: CODE/AMCDISP.CON (220051 bytes)
Including: CODE/AMCITEMS.CON (221097 bytes)
Including: CODE/AMC_OBJECTS.CON (63137 bytes)
Including: CODE/AMCINPUT.CON (128127 bytes)
Including: CODE/LENSFLARE.CON (6509 bytes)
Including: CODE/AMC_ZAX.CON (284626 bytes)
Including: CODE/AMC_MIKKO.CON (14414 bytes)
Internal compiler error at 738359 (0x00000000000b4437)
Internal compiler error at 738298 (0x00000000000b43fa)
Script compiled in 412ms, 7670576 bytes
AMC TC v2.0 Alpha
Initialized 512.0M cache
Loading "duke3d.def"
........
Definitions file "duke3d.def" loaded in 449 ms.
RTS file "DUKE.RTS" was not found
Initializing OSD...
Switching keyboard layout from 00000809 to 00000409
0 joystick(s) found
Loading clip map: _clipshape0.map
Loaded clip map.
Executing "settings.cfg"
Setting video mode 1920x1080 (8-bpp windowed)
Refresh rate: 60Hz
Trying SDL_Renderer "direct3d"
Initializing music...
Initializing sound... 256 voices, 2 channels, 16-bit 48000 Hz
 
Wrote eduke32.cfg
Wrote settings.cfg
Switching keyboard layout from 00000409 to 00000809

I haven't seen any issues or had any crashes happen, the game runs fine otherwise it just shows this message in the log file.

[Hendricks266]

If it reliably happens at that point in loading, I can set a breakpoint at the place the message comes from and look around.