Gentlemans, might I politely ask version of OpenGL you're trying to run Fury on?

With little luck and effort, I've been able to boost my i915 driver from OpenGL 1.6 to OpenGL 2.1:

1name of display: :0
2display: :0  screen: 0
3direct rendering: Yes
4Extended renderer info (GLX_MESA_query_renderer):
5    Vendor: Mesa Project (0x8086)
6    Device: i915 (chipset: 945GME) (0x27ae)
7    Version: 22.2.4
8    Accelerated: yes
9    Video memory: 192MB
10    Unified memory: yes
11    Preferred profile: compat (0x2)
12    Max core profile version: 0.0
13    Max compat profile version: 2.1
14    Max GLES1 profile version: 1.1
15    Max GLES[23] profile version: 2.0
16OpenGL vendor string: Mesa Project
17OpenGL renderer string: i915 (chipset: 945GME)
18OpenGL version string: 2.1 Mesa 22.2.4
19OpenGL shading language version string: 1.20
20
21OpenGL ES profile version string: OpenGL ES 2.0 Mesa 22.2.4
22OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

well, thanks to way version got checked in sdlayer.c, there is no reason to even try to run eduke32/fury on SDL2. Won't even budge. But works pretty well good linked against libsdl1.2.
Only I suppose there has to be some texturing bug. Ion Fury has been able to bomb MESA completely:

It is either black windows with Software renderer or red window with Polymer/Polymost.
eduke32 as is works:

but all I get are untextured red polygons with some errors. Gameplay works though (just don't see it).

1Mesa: User error: GL_INVALID_VALUE in glBindSampler(unit 8)
2Mesa: 7 similar GL_INVALID_VALUE errors
3Mesa: User error: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_RED)
4Mesa: 1 similar GL_INVALID_VALUE errors
5Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
6Mesa: User error: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_RED)
7Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
8Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
9Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
10Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
11Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
12...
13Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
14Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
15Mesa: User error: GL_INVALID_VALUE in glBindSampler(unit 8)
16Mesa: 7 similar GL_INVALID_VALUE errors
17Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
18Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
19Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
20...
21Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
22Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
23Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
24Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
25Mesa: User error: GL_INVALID_VALUE in glBindSampler(unit 8)
26Mesa: 7 similar GL_INVALID_VALUE errors
27Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
28Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
29Mesa: User error: GL_INVALID_VALUE in glBindSampler(unit 8)
30Mesa: 2239 similar GL_INVALID_VALUE errors
31Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
32Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
33Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
34Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
35Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
36Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
37Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
38Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
39Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
40Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
41Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
42Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
43Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
44Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
45Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
46Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
47Mesa: User error: GL_INVALID_VALUE in glBindSampler(unit 8)
48Mesa: 111 similar GL_INVALID_VALUE errors
49Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
50Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
51Mesa: User error: GL_INVALID_VALUE in glBindSampler(unit 8)

eDuke32/Fury is recent GIT version. I'm not even sure if I should try to find and report a bug as driver is slowly getting out of mainline MESA and isn't maintained (probably) anymore.

Grunt wrote on 2022-12-11, 15:13:

Gentlemans, might I politely ask version of OpenGL you're trying to run Fury on?

Below are the lowest spec I tested to run Ion Fury, that is with a custom eDuke32 r10161 XP build, but it should not matter for OpenGL requirements:
Windows 7 SP1 x64, Graphics: NVidia Geforce 210 PCIe = OpenGL version string: 3.2.0 verified
Windows 7 SP1 x64, Graphics: Intel HD Graphics 3000 integrated in i3-2310M = OpenGL version told to be 3.1

IIRC the HD 3000 does not give an acceptable frame-rate with Polymost OpenGL renderer selected. Don't remember how the Geforce 210 fared.

gerwin wrote on 2022-12-11, 17:37:

but it should not matter for OpenGL requirements:

It does:

1gladLoadGLLoader(SDL_GL_GetProcAddress);
2        if (GLVersion.major < 2)
3        {
4            LOG_F(ERROR, "Video driver does not support OpenGL version 2 or greater; all OpenGL modes are unavailable.");
5            nogl = 1;
6        }

Absolute minimum checked is OpenGL2.0 but I'm afraid even OpenGL2.1 might not be enough. How the hell does it works on Win2000 and XP then?

gerwin wrote on 2022-12-11, 17:37:

IIRC the HD 3000 does not give an acceptable frame-rate with Polymost OpenGL renderer selected.

Well, 1.6Ghz 32-bit Atom - software rendered and software rasterized does not give an acceptable frame. Everything else must be smooth gameplay 😉

Grunt wrote on 2022-12-11, 18:12:

gerwin wrote on 2022-12-11, 17:37:

but it should not matter for OpenGL requirements:

It does:

I meant, and wrote, that the OpenGL requirements of my custom build are the same as the official eDuke32 build, of that revision. This one https://dukeworld.com/eduke32/synthesis/20220 … 0161-1585e73fc/

Current eDuke32/Ion Fury is not very friendly for older systems and older OS. Like I wrote before, for Duke Nukem 3D on such systems, it is better to use this version with the OpenGL 1.1 Polymost renderer.
https://dukeworld.com/eduke32/synthesis/20180212-6650/
But that won't play Ion Fury at all.

I am not a developer of these games/ports, and unfortunately do not have the solution in that regard.

gerwin wrote on 2022-12-11, 18:15:

Current eDuke32/Ion Fury is not very friendly for older systems and older OS. Like I wrote before, for Duke Nukem 3D on such systems, it is better to use this version with the OpenGL 1.1 Polymost renderer.
https://dukeworld.com/eduke32/synthesis/20180212-6650/

OK, I'll try. Thanks.

Grunt,

I'm sure you don't care about Windows here but posting this so there is less confusion:
AFAIK "eduke32_win32_20100425-1623" is the last working Windows 2000 build for vanilla 2000 with SDL1.2 so likely OpenGL 1.2 but most people would likely be using eduke32 for Windows 95 which is around the same version anyway.
For XP "eduke32_src_20131012-4097.tar" is the last compiled version for SDL 1.2 but newer versions can be compiled.
For XP "eduke32_src_20211006-9631-cbb598f10.tar for official ver is the last working build that works for <OGL 2.0 with SDL2
For XP r10161 for gerwin unofficial build with SDL2
For Vista for less than OGL 2.0 then eduke32_src_20211006-9651-a891732fd.tar with SDL2
For Vista then "eduke32_win32_20211112-9782-661883a52" requires OGL2.

Unknown when < OGL 2.0 was dropped for Linux. Haven't bothered to test, you can check the changelog and git on changes later than 20211006-9651 and see if it applies to Linux or not. Unknown if SDL 1.2 works with Ion Fury doubt anyone has tested it.

I'm confused by what you posted above though, to test have you tried running eduke32 on Linux user software OGL via MESA or are you just using software OGL provided by the game. AFAIK the game requires hardware OGL for both if OGL support is detected. If the game works with Mesa software OGL then it's an issue with the graphics drivers.

Something else to check is "http://dukeworld.duke4.net/eduke32/synthesis/20180613-6922/".
This is where they changed some more things with OGL, this breaks support in Vmware since if you run Vmware with graphics acceleration then you'll just see a black screen in the game so you have to disable vmware graphics acceleration support to run the game for builds later than this version. Near as I can tell this change made is so that if it detects OGL support then it requires it for both modes, whereas when the videocard is disabled you can use software OGL again.

Beware if you test with earlier versions of eduke32 with Ion Fury since newer versions of the game won't work and you'll get a confusing error messag, so you'll need to have all the different builds of Ion Fury available.

Hmm, you we're right guys. Older version works just fine.

DosFreak wrote on 2022-12-11, 18:55:

Unknown if SDL 1.2 works with Ion Fury doubt anyone has tested it.

I did and it works just as SDL2 does but the with same problem.

DosFreak wrote on 2022-12-11, 18:55:

Something else to check is "http://dukeworld.duke4.net/eduke32/synthesis/20180613-6922/".
This is where they changed some more things with OGL, this breaks support in Vmware since if you run Vmware with graphics acceleration then you'll just see a black screen in the game so you have to disable vmware graphics acceleration support to run the game for builds later than this version.

1source/build/src/glsurface.cpp:
2/*
3 * glsurface.cpp
4 *  A 32-bit rendering surface that can quickly blit 8-bit paletted buffers implemented in OpenGL.
5 *
6 * Copyright  2018, Alex Dawson. All rights reserved.
7 */
8
9#include "glsurface.h"
10#include "glad/glad.h"
11
12#include "baselayer.h"
13#include "build.h"
14

Problem is probably here. Game engine (Polymer) works but it has black untextured polygons (or red). Great. Now what?

Ok I see problem right now. It's actually complaining about it:
glTexImage2D(internal_format=GL_RED) - invalid operation
GL_RED isn't allowed argument for internal_format as far allowed by OpenGL2.
I guess same thing for glTexSubImage2D().

Ok, so now what? Report it, leave it be or should I just rewrite glsurface.cpp right now to be OpenGL2 compliant?

Grunt wrote on 2022-12-11, 21:03:

Ok, so now what? Report it, leave it be or should I just rewrite glsurface.cpp right now to be OpenGL2 compliant?

There is a voidpoint Gitlab with an issue section. It is here
They may say that anything older then OpenGL 3 is unsupported, I don't know.
In any case, I would certainly be interested in synchronizing an OpenGL 2 effort into the XP backport that I host.

I also noticed another thing. The boss of Duke Nukem 3D looks corrupted, as in image below (map E2L6), same goes for the Flying heads in Ion Fury.
Verified this in official eduke32_win32_20210927-9607 and current eduke32_win32_20221026-10165 on Windows 7 x64. The 2018 version that I mentioned does not have this problem.

guys first of all i sincerley appologies if i got it wrong but i read that a dude make it run on win9x without kernelx. i cant hide the fact that i want this game on dos and propably this guy did something near that
here the link in russian
LINK REMOVED

but for what i undreastand i will be possible on modern os like xp 32 bit

Anything can be done (within reason) if you spend enough time to do it. Without KernelEX the game would need to either use SDL1 or replace SDL2 with something else and be compiled with a compiler that supports 9x. Mingw, MINGW-W64 (win32 thread and using a newer MSVCRT.dll), VS2008/2008 (or higher with some hackery), etc. Also non-SDL code that uses newer Windows APIs need to be accounted for.
The game worked alright in kernelex last time I tried it a year or two ago, obviously without OGL which never bothers me with eduke32 anyway.
For DOS then continuation of https://gitlab.com/NY00123/eduke32-dos/ would need to be done.

I'd rather see a DOS port than a 9x port. Back in the day only booted 9x if I had to and today I stay as far away as I can.

IMO - Before considering any serious back-port efforts, one has to first assess why and how, after eDuke 2018-02-12 r6650, legacy compatibility and especially performance was hit so severely. In different steps that is, in the period 2018..2021. Without addressing that, why bother.

i agree dos port will be the best. but thats need a lot of work from guys know very good what they are doing

I don't know how exactly Fury should work in DOS.

On eduke32_20211006 and little tweaking, I've been able to get Polymer running even on OGL2.1 compatible graphic card. But it is no fun:

It is slow (CPU intensive), full of graphical glitches and corruptions. Ion Fury is more like slideshow and with first level I've been able to crash cards core. But it is relatively new eduke32 and it works (SLD2 + SDL1.2). I'm happy.
Maybe OpenGLES is a way (is defined in source code).

gerwin wrote on 2022-12-13, 02:01:

There is a voidpoint Gitlab with an issue section. It is here
They may say that anything older then OpenGL 3 is unsupported, I don't know.

I know exactly how it would end: NOTABUG with "Anything lower than OpenGL 3 compliant card not supported, you're on your own and good luck". Just like MBF. No thanks.

Grunt wrote on 2022-12-22, 21:42:

I don't know how exactly Fury should work in DOS. On eduke32_20211006 and little tweaking, I've been able to get Polymer running […]
Show full quote

I don't know how exactly Fury should work in DOS.
On eduke32_20211006 and little tweaking, I've been able to get Polymer running even on OGL2.1 compatible graphic card. But it is no fun:
It is slow (CPU intensive), full of graphical glitches and corruptions. Ion Fury is more like slideshow and with first level I've been able to crash cards core. But it is relatively new eduke32 and it works (SLD2 + SDL1.2). I'm happy.
Maybe OpenGLES is a way (is defined in source code).

I applaud you for trying, and getting it to run. Though I am a bit confused about "it is no fun / It is slow -> I'm Happy".

Grunt wrote on 2022-12-22, 21:42:

I know exactly how it would end: NOTABUG with "Anything lower than OpenGL 3 compliant card not supported, you're on your own and good luck". Just like MBF. No thanks.

Is that last bit a reference to that time, where you wanted the flashing floppy disk in Doom MBF 2.04?

gerwin wrote on 2022-12-23, 01:09:

I applaud you for trying, and getting it to run. Though I am a bit confused about "it is no fun / It is slow -> I'm Happy".

I'm happy it works. There is no physical obstruction why eduke32 shouldn't work on old 32-bit CPU with old OpenGL2 card.

Yes, as eduke32 stands, is in dire need of crucial optimization if it should ever support older HW, but there is no physical obstruction other than incompatibilities introduced in upstream (by developer?). That's why I'm happy.
Actually I was willing to create binary package for my distribution and maintain it (well, why not? right?) but:

• I would have to either convince somehow developer not to break compatibility deliberately in upstream. Good luck with that. Answer is pretty much known.
• Use older git version and patch it regularly by myself. Hmm, okay.
• Use 2018 build and keep it without support for Ion Fury. I don't see any point in this.

This is reason why I asked here what to do. I myself have no idea.

Since upstream intentionally breaks support then it would have to be a fork. The fork wouldn't have to be constantly kept up to sync, commits from upstream could be reviewed periodically and added if they are wanted.

Guys, I don't get how you were able to get Ion Fury running on…well, on anything.

I just finished reading whole thread and to address first obvious thing: There is a reason why Ion Fury has been released as 64-bit, SDL2 compatible binary. It was built on eduke32 engine, but Ion Fury is pretty much modern game on older base. So don't let the appearances fool you. By profiling the thing, I just discovered there is Virtual friggin' Machine! And you may not notice on regular modern dual-core CPU it's presence (as modern CPUs are designed to swallow instructions), it is very first thing on gprof list, profiling eduke32 on old 1,6GHz (45 nm) single-core Diamondville Atom. I don't know how it got there and when, but it is simply there.

I've been able to to execute eduke32 + Ion Fury just barely. First thing is to load small map (don't start with z1m1.map, guaranteed way to crash), next is to disable monsters (-m startup parameter).
As soon as I look into map and engine has to traverse through all portals/sectors (on BSP engines it is software BSP tree traversal, no idea how it is done here), looking gets jerky. And as soon as I wake up monsters (or actors or whatisitactualy),it is pretty visible as engine has to go through entire thing and updates states just once per second or even less with CPU on fire. Surprisingly original duke3d works pretty fine, but load bigger complex map and guaranteed it will get older CPU to knees. This is why I don't get how you may be able to get this thing working on Win9X or let aside DOS. Nonsense. Not modern eduke32 git trunk.

eDuke32 contains not two, but four "Video rasterization modes":

• Polymost - I haven't been able to get it working as all I still see are either red or black screen. Bummer. Some OpenGL bug I assume.
• Polymer - works with bugs and glitches (see screenshots) and it consumes even more CPU than software mode (all palatalized textures has to be converted and updated to GPU, not very effective I guess). On the other side, it doesn't matter which screen resolution I choose and it works pretty good even in fullscreen. And as soon as CPU is able to fill polygons quickly enough (very rarely in my case), it's smooth too.
• Software renderer on OpenGL canvas - bugged in my case. All I see is one channel (red), four times and resized in SDL windows. Just some texturing bug. Didn't bother further as OpenGL canvas is slower than just pour pure pixmaps.
• Software renderer directly to SDL - binary has to be compiled with "USE_OPENGL=0". Surprisingly faster than anything as long as window is small. But I guess software rasterization has to take some CPU cycles too and of course price is no perspective correction. Should work on anything as long as SDL is able to initialize. Tested od SDL1.2/SDL2.

Screenshots directly form EEE PC in fullscreen (1024x600 pixels) and OpenGL mode.

I wish I could see Ion Fury on some handheld PC or older HW and I'm going to do some further testing and profiling, but since I'm no expert in the field of VM optimizations, I think I might be done. If you still decide to optimize eduke32 somehow, let me know. I'm interested (if nothing, at least in testing).

heres my experience its as you say appearence can decieve especialy us old school into thinking its fit for p2 p3 machines. ive (run) it on my win98se p3 800mhz 512mb ram using eduke 32 for dos and the thing simply stuck at the very 1st map 1fps!!! the i undust a lga 775 core2duo 2.93 ghz install win9x with patches and the game flyes even on with 512mb as well. the eduke even dos port is making things very complex but also the game con files are complex themselfs make things want a real beast of cpu.

truemaster wrote on 2022-12-27, 15:44:

ive (run) it on my win98se p3 800mhz 512mb ram using eduke 32 for dos and the thing simply stuck at the very 1st map 1fps!!!

Don't test it on first map. As first map (with very first spawn point) is very complex, you'll get it stuck guaranteed. Test it with -l2, -l20, -l24 (look into GRP file, folder maps and sort it by size). Maybe isn't bad idea to create series of testing maps in ascending order of complexity just to purely test engine.

I think it simply boils to wrong assumptions and distorted childhood memories. We've came with wrong assumption (or maybe I just came, I don't know) if BUILD and duke was pretty playable on old i486-DX2 on something newer with computing power in order of Gigahertzes it has be like playing minesweeper and it has to fly. Wrong! Just out of curiosity I've read Fabien Sanglard's engine review and for sakes of just trying it, compiled and tested Chocolate Duke on poor Atom thing.
Shareware Duke, no surprise here, is smooth as butter. But look:

1New vidmode flags: SDL_HWPALETTE.
2init_new_res_vars 320 200
3genspriteremaps()
4levname=E1L1.map
5CONFIG_WriteSetup...
6
7
8
9real    2m25,099s
10user    2m0,365s
11sys     0m7,444s

Even on OG resoultion 320x200 pixels it is burning through CPU's time. And where scenes are complex sound is jerky and distorted as CPU hasn't enough power to process sound as well. How the heck we were able to play it on 486/586 as children is mystery for me. Flat profile attached:

1Flat profile:
2
3Each sample counts as 0.01 seconds.
4  %   cumulative   self              self     total           
5 time   seconds   seconds    calls   s/call   s/call  name    
6 34.93     19.55    19.55  1508594     0.00     0.00  vlineasm4
7 13.06     26.86     7.31   902387     0.00     0.00  mvlineasm4
8 11.74     33.43     6.57  2227575     0.00     0.00  hlineasm4
9  3.72     35.51     2.08   242030     0.00     0.00  wallscan
10  2.20     36.74     1.23 35315373     0.00     0.00  mul32_64
11  2.05     37.89     1.15                             __x86.get_pc_thunk.bx
12  1.93     38.97     1.08        1     1.08     1.08  newgame
13  1.88     40.02     1.05   992316     0.00     0.00  vlineasm1
14  1.75     41.00     0.98   295131     0.00     0.00  clearbufbyte
15  1.64     41.92     0.92   596615     0.00     0.00  slopevlin
16  1.32     42.66     0.74   146353     0.00     0.00  drawalls
17  1.20     43.33     0.67   205913     0.00     0.00  drawsprite
18  1.13     43.96     0.63   118198     0.00     0.00  florscan
19  1.09     44.57     0.61   101449     0.00     0.00  scansector
20  1.02     45.14     0.57    37534     0.00     0.00  rhlineasm4
21  0.98     45.69     0.55                             __divdi3
22  0.89     46.19     0.50   110537     0.00     0.00  dorotatesprite
23  0.70     46.58     0.39 22165585     0.00     0.00  mulscale
24  0.69     46.97     0.39  2225424     0.00     0.00  hline

As visible, it is spending time where it should. Drawing, scanning sectors and computing. And is eduke32 worse? Honestly, not that much (with Polymer enabled I would say is even better. On fullscreen native resolution definitely). Add bigger complex map, lot of slopes, plenty of voxels, something for VM to compute, MOD music, poorly optimized engine and not very successfully implemented or broken OpenGL (all in fury) and you get what you got. Slideshow in better case.

I have few question:

1. Was someone able to record demos in Ion Fury? I would love to test it, but as I'm able to barely move is no it's no glory.
2. It's there way how to disable graphical output in eduke32 and test just demo and engine? Equivalent for -benchmark parameter in DOOM I mean. My assumption is if just with sound it would give more time to chew through complex map than CPU offers, there is no reason to implement things like older OpenGL, Win9X or even DOS.
3. Maybe isn't wrong thing to ask developer implementing some graphical cue to write in-game in which parts/modules of engine is time spent. I mean VM/Drawing/Music/IO waits/whatever. Shall I ask in for New issue?

It left me puzzled, because DOOM engine (idTech1) works just fine on bigger maps. Maybe it scales better. Who knows.