Grunt wrote on 2022-12-27, 22:18:

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?

Some months ago I was reading posts at the 4Duke forums, the Steam game reviews and developer interviews. What I understand is, that performance was always a known issue. For Ion Fury the eDuke32 feature-set was expanded, like the CON scripting system, newer OpenGL interfacing. With that came problems with performance. There were some remedies, like multi-threading and an OpenGL PersistentStreamBuffer. But these require a somewhat recent OS, hardware and drivers. For most of the customer base, the game then ran reasonably OK. But on old systems, one is left with the performance problems, without the benefit of the remedies, because the remedies don't work there. That is probably the reason they never bothered with an official 32bit version of Ion Fury.

The eDuke32 Polymer renderer is not select-able in Ion Fury - as in - a build of the engine for Ion Fury specifically. It is an unmaintained renderer for years now. You can read about it on the 4Duke forums.

Also check out ProAsm's ports for Duke Nukem 3D and Shadow Warrior. They have their own problems, but run much faster then eDuke32 for sure. ProAsm's ports were based on the earlier OpenGL ports by Jonof. By the way, one of the problems is Networking: Notice that in eDuke32 multiplayer is disabled, because it was too troublesome. I am told it was never proper, not even in the original DOS game.

I can run the original Duke Nukem 3D on a Cyrix 5x86-100MHz (486 upgrade chip). That way it is enjoyable in 320x200, but only just.

gerwin wrote on 2022-12-28, 02:05:

Some months ago I was reading posts at the 4Duke forums, the Steam game reviews and developer interviews. What I understand is, […]
Show full quote

Grunt wrote on 2022-12-27, 22:18:

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?

Some months ago I was reading posts at the 4Duke forums, the Steam game reviews and developer interviews. What I understand is, that performance was always a known issue. For Ion Fury the eDuke32 feature-set was expanded, like the CON scripting system, newer OpenGL interfacing. With that came problems with performance. There were some remedies, like multi-threading and an OpenGL PersistentStreamBuffer. But these require a somewhat recent OS, hardware and drivers. For most of the customer base, the game then ran reasonably OK. But on old systems, one is left with the performance problems, without the benefit of the remedies, because the remedies don't work there. That is probably the reason they never bothered with an official 32bit version of Ion Fury.

The eDuke32 Polymer renderer is not select-able in Ion Fury - as in - a build of the engine for Ion Fury specifically. It is an unmaintained renderer for years now. You can read about it on the 4Duke forums.

Also check out ProAsm's ports for Duke Nukem 3D and Shadow Warrior. They have their own problems, but run much faster then eDuke32 for sure. ProAsm's ports were based on the earlier OpenGL ports by Jonof. By the way, one of the problems is Networking: Notice that in eDuke32 multiplayer is disabled, because it was too troublesome. I am told it was never proper, not even in the original DOS game.

I can run the original Duke Nukem 3D on a Cyrix 5x86-100MHz (486 upgrade chip). That way it is enjoyable in 320x200, but only just.

Recently, i get a ibm ps/1 486 sx25, and when i tested duke3s i say "oh is not bad"

And i finish first episode just for fun

This moments i realize how low are my fps standard jaja

Gentlemans, may I once again politely ask what kind of HW are you trying to run Ion Fury on?

I've abandoned the idea of exploiting OpenGL on old EEE, simply because GPU is such a pice of (s)crap, even software mode (NO_GL) is faster. Instead I've focused on pure software mode without OpenGL. Even so I can't believe you are able to run fury on older HW (Win2000/XP era) . How? I'm able to load any map from fury.grp, there is no problem. But even without monsters (-m parameter) I'm able to run only very small maps (boss arenas without any monsters, Level 20, Level 24). As far as actors and scripts are involved (monsters, scripts, barrel explosions), CPU doesn't have enough power to update world fast enough (no problems with drawing though). I see updates like few times per second or even 1fps.
I tried incorporate microprofiling, unfortunately unsuccessfully. Could you please post some evidence? I still can't belive it would even move on older HW like Win98/KernelEx, let alone DOS.

Grunt wrote on 2023-02-12, 10:17:

Gentlemans, may I once again politely ask what kind of HW are you trying to run Ion Fury on?

I mentioned earlier in this thread some anecdotes, using my build with Ion Fury game data:
Core i5-3550 / Radeon HD7750 / Windows XP x86 SP3 = OpenGL mode insufficient frame-rate (Driver issue?). Software mode OK.
Core i5-3550 / Radeon HD7750 / Windows 7 x64 = OpenGL mode runs fine
Core 2 Duo P9600 2.66 GHz / NVidia GT 710 GDDR5 / Windows XP x86 SP3 = OpenGL mode runs fine

gerwin wrote on 2019-08-25, 21:31:

Laptop + Windows XP + Intel HD 3000 - Game starts and menu looks fine, but 3D game has serious glitches and slowdowns. Previous eDuke versions run fine with OpenGL.

I have pretty similar system (Think Pad T430, with Intel HD 4000 and XP), and I can concur, that there are massive slowdowns, which makes the game pretty much unusable. I was able to trace it to build 6884, everything after that is not usable in XP for me with mentioned laptop. 6880 works just fine.

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

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.

Finally managed to get rid of this rendering problem with the mentioned characters, in both eDuke32 and Ion Fury. A single setting:

1r_hightile=0

Defaults to 1 if not set.
https://wiki.eduke32.com/wiki/Console_commands
https://forums.duke4.net/topic/11965-the-inde … ghtiles-thread/
For me this was still an issue with the latest official eDuke32 build running on Windows 7 x64 (Radeon HD 7750).

Also I changed my Windows XP Radeon driver from v13.1 to the very last iCafe v2015 Catalyst driver, and now OpenGL framerate jumped up significantly. A scene that was 24 FPS before now shows 86 FPS. (I skipped the v14.4 driver version there, but I have reason to believe it has the exact same OpenGL component as v13.1.) I am not sure about the underlying cause for the framerate difference, maybe a shader compilation hickup, like I saw recently in the Force Engine project?

So first big bottleneck solved. A while ago, we had private discussion with Srandista how older version of eduke32 (pre-2019) were much faster. Somewhere around 2018-2019 there was implemented something in tree which introduced weird lag or wrong responsiveness feeling in game (at least for me). And I finally know what it is.

It was timer! All eduke32 version up to v.7972 (incl.) are still using timer (I firmly believe) written by Ken:

1sdlayer.cpp:
2
3//
4//
5// ---------------------------------------
6//
7// All things Timer
8// Ken did this
9//
10// ---------------------------------------
11//
12//
13
14static uint32_t timerfreq;
15static uint32_t timerlastsample;
16int32_t timerticspersec=0;
17static double msperu64tick = 0;
18static void(*usertimercallback)(void) = NULL;
19
20
21//
22// inittimer() -- initialize timer
23//
24int32_t timerInit(int32_t tickspersecond)
25{
26    if (timerfreq) return 0;	// already installed
27
28//    initprintf("Initializing timer\n");
29
30#if defined(_WIN32) && SDL_MAJOR_VERSION == 1
31    int32_t t = win_inittimer();
32    if (t < 0)
33        return t;
34#endif
35
36    timerfreq = 1000;
37    timerticspersec = tickspersecond;
38    timerlastsample = SDL_GetTicks() * timerticspersec / timerfreq;
39...

In version 20190813-7976 there is introduction of SDLTimer and timer.cpp file:

------------------------------------------------------------------------ r7976 | terminx | 2019-08-13 07:44:16 -0700 (Tue, 13 Au […]
Show full quote

------------------------------------------------------------------------
r7976 | terminx | 2019-08-13 07:44:16 -0700 (Tue, 13 Aug 2019) | 1 line

Replace separate timer implementations in SDL and Winlayer with a shared implementation based on std::chrono
------------------------------------------------------------------------
r7975 | terminx | 2019-08-13 07:44:09 -0700 (Tue, 13 Aug 2019) | 1 line

There's no way this is correct.
------------------------------------------------------------------------
r7974 | terminx | 2019-08-13 07:44:05 -0700 (Tue, 13 Aug 2019) | 1 line

Name fix, I guess?
------------------------------------------------------------------------
r7973 | terminx | 2019-08-13 07:44:00 -0700 (Tue, 13 Aug 2019) | 1 line

Fix remaining casts to vec2_t/vec3_t
------------------------------------------------------------------------
See http://svn.eduke32.com/listing.php?repname=eduke32 for more details.

I should explain: I'm still rocking old EEE PC for this occasion. Intel Atom inside. 1-core 32-bit weak CPU. 1.6Ghz but can be stepped-down to 800Mhz. Unfortunately, poisoned by HT-technology (because it was cool back in the day). It creates two virtual cores for operating system, but somehow is still running on one physical core in CPU. eduke32 was one-thread application (I believe) but it started using threads for services like music and miscellaneous stuff. And this exactly is problem for me as SDLTimer is created as separate thread assigned to different virtual core than main game loop.
As is CPU context switched between two virtual cores, updates for timer aren't tied to main rending loop and thus entire game world is updated as CPU time is unperiodically assigned to core running SDL timer. Resulting in weird update lag. But believe it or not, old timer is still there:

1#ifdef HAVE_TIMER_SDL
2        default:
3        case TIMER_AUTO:
4        case TIMER_SDL:
5            return TIMER_SDL;
6#endif // HAVE_TIMER_SDL
7#ifdef _WIN32
8#if !defined HAVE_TIMER_SDL
9        default:
10        case TIMER_AUTO:
11#endif // !HAVE_TIMER_SDL
12        case TIMER_QPC:
13            return TIMER_QPC;
14#endif // _WIN32
15#ifdef HAVE_TIMER_RDTSC
16#if !defined _WIN32 && !defined HAVE_TIMER_SDL
17        default:
18        case TIMER_AUTO:
19#endif // !_WIN32 && !HAVE_TIMER_SDL
20        case TIMER_RDTSC:
21            return TIMER_RDTSC;
22#endif
23    }
24}

it's simply defined by HAVE_TIMER_SDL as default value. I redefined HAVE_TIMER_RDTSC as default value, complied entire engine and problem solved. Combined this with disabling HT-technology (nosmp parametr for linux kernel) resulting in smooth frame rate in eduke32 and unbroken music playback again. Even for newer git versions.
This might help someone struggling with similar problem.

If HT is part of the cause due to context switches happening, you could also disallow it within user space. On MS Windows, this can be done in Windows Task Manager. Start the game, then Alt+Tab to Task Manager, go to the Details tab, sort by name, then right-click an already running process and pick "Set affinity", deselect all but one logical CPU and apply the setting. You can also build a simple launcher batch script for it (Call it eduke32.bat or something), that sets CPU affinity right at launch if you have at least Windows NT 5.2 (XP x64, Server 2003), e.g.:

1@ECHO OFF
2START /AFFINITY 0x1 C:\some\path\eduke32\eduke32.exe

On Linux, you can do that when launching or after having launched a process with taskset[1]: $ taskset -a 0x00000001 eduke32 to launch the game and force all of its threads on logical CPU 0, or $ taskset -a -p 0x00000001 <PID> to assign an already running game to only CPU 0. You should be able to get the PID by running $ ps ax | grep 'eduke32'. With the -a option, all threads of the process will be affected. Similar to above, a simple shell script launcher can be used, e.g.:

1#!/usr/bin/env sh
2taskset -a 0x00000001 /usr/local/bin/eduke32

Since eduke32 is also available on FreeBSD as a package, I'll mention a way for this system as well, using the cpuset[1] utility:

1#!/usr/bin/env sh
2cpuset -l 0 /usr/local/bin/eduke32

With that, you can leave HT enabled, and it will not affect eduke32 at all. Since some programs can slightly benefit from HT, this might be more desirable than switching it off globally.

I don't know. nosmp or maxcpus=1 as kernel parameter and RDTSC timer did the thing for me.

Edit: And OG resolution: 400x200px 😉

Grunt wrote on 2023-10-30, 18:38:

I don't know. nosmp or maxcpus=1 as kernel parameter and RDTSC timer did the thing for me.

Edit: And OG resolution: 400x200px 😉

Thanks for the tip!
May I ask some technical details:
What OS are you using on your eee PC? And which build of eDuke32 are you using (version, architecture, Ion Fury base or Aftershock data)?

EDIT:
Answer by PM; Grunt uses Linux on that eee PC, eDuke32 v9710, Ion Fury v2 base game data.

So, i've published on nexus and moddb eduke32 mod for Ion Fury: Aftershock on Windows XP 32 bits
 
 
 
 
Short way:

1) Download modded binaries

https://disk.yandex.ru/d/PYprvzXPwfWo6w

2) Place fury.grp and fury.grpinfo near eduke32.exe

3) Play

Advice:
Disable voxels in graphics menu. Performance with enabled voxels is awful (something about 5 fps on GTX 680).
 
 
 
 
Long way (modding binaries by yourself):

1) Take eduke32_win32_20230926-10459-8feaf6c25 (https://dukeworld.com/eduke32/synthesis/20230 … 0459-8feaf6c25/) or compile it with sources

2) Take 4 dlls from One-Core-Api (https://github.com/Skulltrail192/One-Core-API-Binaries) or compile it with sources

One-Core-API-Binaries/Packages/x86/Base Installer
- ntext.dll
- msvcrt.dll
- kernelbase.dll

One-Core-API-Binaries/Packages/x86/Base Installer\XPSP3
- xpspkernel32.dll

3) Replace 2 bytes in msvcrt.dll from One-Core-Api:

Address                Byte change      Purpose
0x000002A7    0x32 to 0x33    Import table kernel32.dll to kernel33.dll
0x0009B82F    0x32 to 0x33    Import table kernel32.dll to kernel33.dll

4) Place 4 dlls from One-Core-Api near eduke32.exe and then rename them (because of "known dlls"):

One-Core-Api dll        Rename to

- xpspkernel32.dll    - kernel33.dll
- ntext.dll                     - ntext.dll
- msvcrt.dll                  - msvcru.dll
- kernelbase.dll         - kernelbase.dll

5) Replace 3 bytes in eduke32.exe:

Address                   Byte change      Purpose
-0x00043AC9    0x01 to 0x00    minicoro calls CreateFiberEx with argument FIBER_FLAG_FLOAT_SWITCH (1). This flag is not supported by Windows XP, change it to 0
-0x005F0F7F      0x32 to 0x33     Import table kernel32.dll to kernel33.dll
-0x005F11C9      0x74 to 0x75     Import table msvcrt.dll to msvcru.dll

6) Place fury.grp and fury.grpinfo near eduke32.exe

7) Play

Boroda1: I've just noticed how much effort do you guys put into executing modern eduke32 engine on Windows XP. And just to note, there is still SDL1.2 in source tree and native Windows timer in timer.cpp:

1#if !defined HAVE_TIMER_SDL
2        default:
3        case TIMER_AUTO:
4#endif // !HAVE_TIMER_SDL
5        case TIMER_QPC:
6            return TIMER_QPC;

Query Performance Timer should work fork for Windows2000 and later. It simply isn't default anymore.

Boroda1 wrote on 2023-11-05, 06:42:

So, i've published on nexus and moddb eduke32 mod for Ion Fury: Aftershock on Windows XP 32 bits

Thanks for the binaries and the explanation. This is an interesting quick method to get it running. Works fine on my end.