EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#5761 Posted 17 October 2017 - 01:31 PM
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?
#5762 Posted 17 October 2017 - 02:05 PM
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.
#5763 Posted 17 October 2017 - 05:55 PM
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.
This post has been edited by PsychoGoatee: 17 October 2017 - 05:59 PM
#5764 Posted 17 October 2017 - 06:17 PM
This post has been edited by Mark.: 17 October 2017 - 06:18 PM
#5765 Posted 17 October 2017 - 06:32 PM
This post has been edited by PsychoGoatee: 17 October 2017 - 06:34 PM
#5766 Posted 17 October 2017 - 07:07 PM
PsychoGoatee, on 17 October 2017 - 06:32 PM, said:
Polymer doesn't always get texture mapping exactly right.
#5767 Posted 18 October 2017 - 03:26 AM
Hendricks266, on 17 October 2017 - 02:05 PM, said:
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.
#5768 Posted 18 October 2017 - 10:27 AM
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.
#5769 Posted 18 October 2017 - 12:22 PM
Hendricks266, on 18 October 2017 - 10:27 AM, said:
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!
This post has been edited by gaula92: 18 October 2017 - 12:27 PM
#5770 Posted 18 October 2017 - 12:36 PM
gaula92, on 18 October 2017 - 12:22 PM, said:
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:
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:
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:
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.
#5771 Posted 18 October 2017 - 12:46 PM
#5772 Posted 18 October 2017 - 12:51 PM
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?
#5773 Posted 18 October 2017 - 02:05 PM
Phredreeke, on 18 October 2017 - 12:51 PM, said:
Overall it saves performance but I believe there is some aspect of software scaling there.
Phredreeke, on 18 October 2017 - 12:51 PM, said:
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:
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.
#5774 Posted 18 October 2017 - 05:06 PM
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.
This post has been edited by gaula92: 18 October 2017 - 05:06 PM
#5775 Posted 21 October 2017 - 02:37 PM
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
#5776 Posted 22 October 2017 - 12:50 AM
#5778 Posted 26 October 2017 - 06:50 AM
There's no better sourceport, and I'd like to see it running smoothly on the platform...
#5779 Posted 26 October 2017 - 05:42 PM
gaula92, on 26 October 2017 - 06:50 AM, said:
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.
#5780 Posted 27 October 2017 - 12:52 AM
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.
#5781 Posted 27 October 2017 - 02:32 AM
enderandrew, on 26 October 2017 - 05:42 PM, said:
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.
#5782 Posted 27 October 2017 - 08:50 AM
Jblade, on 27 October 2017 - 12:52 AM, said:
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?
#5783 Posted 27 October 2017 - 09:13 AM
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.
#5784 Posted 27 October 2017 - 10:58 AM
#5785 Posted 28 October 2017 - 11:36 AM
#5786 Posted 29 October 2017 - 02:26 PM
#5787 Posted 29 October 2017 - 04:40 PM
else ifrnd 32 { ifvare ally_subtitles 0 { state SOLDIER_NAMES qputs 7501 ^1%s: ^0We've got sierra tangos here. qsprintf 7501 7501 573 setvar ally_subtitles 60 } sound EDFS_PARA_2 }
else ifrnd 8 { ifvare ally_subtitles 0 { state SOLDIER_NAMES qputs 7501 ^1%s: ^0Enemies incoming. qsprintf 7501 7501 573 setvar ally_subtitles 45 } sound EDFS_INCOMING_2 }
The calls to state SOLDIER_NAMES specifically in these two places are what is causing the message. I'm not yet sure why.
#5788 Posted 29 October 2017 - 11:52 PM
#5789 Posted 02 December 2017 - 12:11 AM
Also, what's the correct way to hide/remove the default ingame huds? Since times of old I've just locked the screensize to the largest one possible but I'd rather not lock it anymore especially with the new events and stuff.
This post has been edited by Jblade: 02 December 2017 - 12:17 AM
#5790 Posted 10 December 2017 - 01:57 PM
Jblade, on 02 December 2017 - 12:11 AM, said:
Also, what's the correct way to hide/remove the default ingame huds? Since times of old I've just locked the screensize to the largest one possible but I'd rather not lock it anymore especially with the new events and stuff.
http://wiki.eduke32....ENT_DISPLAYSBAR