DosFreak wrote:

It's interesting that the build docs for eduke32 state that SDL 1.2 can still be used.....

This isn't so surprising. The same is true for ScummVM and was until recently for Yamagi for example.

dr.zeissler wrote:

This game would be a big deal if it can be played within DOS or Win9x on a P2/3.

Maybe for us, but general public don't care about that.

Ran the latest build of eDuke32 on an XP (x86) machine with a Pentium 4 2.4GHz Northwood, 1GB RAM and a Matrox Mystique.

It was... rough, to say the least. 100% pegged CPU usage, eats an additional 1.5GB of HDD space for page file, barely playable framerates. This is with Polymer renderer off.

It may be possible with lots of config tweaking or a more optimised eDuke build for older machines, but playing stock on anything resembling a retro machine seems to be a dream that won't happen easily. Playing in DOS looks like it'd require significant reworks of the maps.

The game is still super fun on my main machine though!

Another major issue is the game's framerate. While it was, say, smooth enough for the overwhelming majority of the game (although never really what you should expect), it tanked to the low 10s at the worst possible times, namely during the boss battles of zones 2, 3 and 7, making the battles a very excruciating experience for all the wrong reasons. Why I'm getting a much better performance out of Rise of the Tomb Raider, a known resource-hog, at high settings is a question worth asking.

https://msdn.duke4.net/revionfury.php

x0zm_ wrote:

It was... rough, to say the least. 100% pegged CPU usage, eats an additional 1.5GB of HDD space for page file, barely playable framerates. This is with Polymer renderer off.

Things must have changed a lot in the last 6 years, in 2013 I used to run eduke at 60fps on a wii (729MHz CPU, 72MB ram)

I guess that Wii leverage it's GPU to do a HW acceleration. x0zm_ run game in SW rendering. I would expect the best results older HW with Polymost renderer, but I don't know, if it still can be used in latest eDuke32 (and I'm not home to be able to actually test it).

No, it was completely software rendered using SDL 1.2. The only "acceleration" was rendering directly as 8bpp (paletted texture).

Got it. Suffice to say I'm digging it profusely.

Also, for fans of period references: https://s.put.re/T7dDTynh.png 😉

https://www.gog.com/forum/ion_fury/ion_fury_eduke32

This is a guide on how to get Ion Fury running under EDuke32. You might find that running the game this way runs better on your […]
Show full quote

This is a guide on how to get Ion Fury running under EDuke32. You might find that running the game this way runs better on your system than using the modified version that Ion Fury uses. Though there are 2 issues specific to running it under EDuke that i've found. The in game menu scrolls and save or load pictures are blank. Other than those two things it seems to run fine.

1) Download EDuke32 from here.

If on Mac then download it from here.

EDuke32 is only available natively on Windows or Mac. However you can build it yourself if on Linux from following these instructions.

2. Put EDuke32 (unzip it if you downloaded it) into a folder on your system. It doesn't matter where or what the folder is called.

3. Install Ion Fury from wherever you brought the game from.

4. Navigate to Ion Fury's directory and copy fury.def, fury.grp and fury.grpinfo to wherever you put EDuke32.

fury.grp contains all the info about the game, such as maps, sounds etc. fury.grpinfo tells EDuke32 what the grp is and where it is, without this EDuke32 will not detected fury.grp. fury.def contains needed palette information, without this you will get a palette error and the game will not launch.

5. Double click on EDuke32.exe, make sure that Ion Fury is selected in the Game section in the window that pops up. Then click start when ready.

You can now remove Ion Fury if you want to.

So if the above is true then Windows XP 32bit should be good. Need to test eduke32 with kernelex on Windows 98 next and blackwingcat patch on Windows 2000. Anybody have a CRT hooked up?

I'll try it on XP tomorrow (not with CRT though).

Here is Ion Fury running on Windows 2000 using BlackWingCat ExtendedCore with eduke32 w/ SDL2 eduke32_win32_20190820-8043.7z

Iron Fury on Windows 98 SE using KernelEx 4.5.2016.17 w/ Kernel Extension 22 with eduke32 w/ SDL2 eduke32_win32_20190820-8043.7z
Copy msvcr71.dll to c:\windows\system, Backup old msvcrt.dll in c:\windows\system, delete msvcrt.dll. Rename msvcr71.dll to msvcrt.dll.

Run eduke32 in Windows XP compatibility mode

I'm still wondering if eduke32 can be compiled with SDL 1.2 with the current source. Need to look into that but eduke32 itself likely requires APIs not existing in Windows 98 so wouldn't be that simple but would be nice since then could potentially run on 95 and NT4.

Interesting results there.
I have less success with this on my Windows XP system, using Radeon 6670 graphics.
eduke32_win32_20190820-8043.7z only runs in software mode with the original Duke3D.grp file. Using fury.grp or OpenGL mode gives a crash.

Yeah crashes for me too in XP as well with Ion Fury and Duke 3D just shows a black screen haven't figured that one out yet.

/EDIT

It looks like eduke32 in Windows XP in Vmware 15.1.0 stopped working as of this version:
http://dukeworld.duke4.net/eduke32/synthesis/20180613-6922/

1------------------------------------------------------------------------
2r6922 | pogokeen | 2018-06-13 12:15:26 -0700 (Wed, 13 Jun 2018) | 1 line
3
4Add glsurface.cpp/h and tilepacker.cpp/h to Visual Studio Project
5------------------------------------------------------------------------
6r6921 | pogokeen | 2018-06-13 12:15:22 -0700 (Wed, 13 Jun 2018) | 2 lines
7
8Don't allow GL modes if GL Major Version is less than 2.
9Additionally, fix build issues for RENDERTYPE=WIN introduced in r6827.
10------------------------------------------------------------------------
11r6920 | pogokeen | 2018-06-13 12:15:19 -0700 (Wed, 13 Jun 2018) | 1 line
12
13sdlayer.cpp: don't alter desktop composition using win_setvideomode() if we're creating an SDL window for rendering GL
14------------------------------------------------------------------------
15r6919 | pogokeen | 2018-06-13 12:15:16 -0700 (Wed, 13 Jun 2018) | 1 line
16
17When OpenGL is available, prefer using the new glsurface to blit the classic renderer's 8-bit buffer to the screen.
18------------------------------------------------------------------------
19r6918 | pogokeen | 2018-06-13 12:15:10 -0700 (Wed, 13 Jun 2018) | 1 line
20
21tilepacker.cpp: instead of maintaining the heap on each insertion, maxheap_buildHeap() on tilepacker_pack()
22------------------------------------------------------------------------
23See http://svn.eduke32.com/listing.php?repname=eduke32 for more details.

I can see this when comparing the log files since this version (which works) http://dukeworld.duke4.net/eduke32/synthesis/20180612-6917/ shows "Trying SDL_Renderer "direct3d"" in the log whereas the newer versions show OpenGL information even though software mode is selected.

Part of this is likely buggy vmware drivers but the other part is if software mode is selected why is eduke32 still trying to use OpenGL?

/EDIT
Just disabled graphics acceleration for the XP VM and working fine with eduke32_win32_20190820-8043.7z with Duke 3D now in Vmware.

Bummer...

Before I used this version on two Windows XP systems: EDuke32 r7297 - Built Dec 20 2018 17:16:47, GCC 7.2.0, 32-bit
OpenGL mode works fine with that one. But of course it is not Ion Fury compatible.

If OpenGL works in older versions and not newer versions try going through each build to identify where it broke and then report it mabye it will get fixed.

It looks like it crashes when it's going through the files in fury.grp and compiling the scripts.

GOOD

1EDuke32 r8043
2Built Aug 20 2019 20:21:56, GCC 7.2.0, 32-bit 
3Using D:/Ion Fury/eduke32_win32_20190820-8043/ for game data
4Checking for updates...
5Connecting to http://www.eduke32.com
6Current version is 20120522... no updates available
7Running on Windows 10 (build 10.0.18362)
8Initializing SDL 2.0.10
9Searching for game data...
10 Checksumming fury.grp... Done
11Using "fury.grp" as main game data file.
12Compiling: scripts/main.con (50245 bytes)
13Including: scripts/tokens.con (27554 bytes)
14Including: scripts/names.con (59980 bytes)
15Including: scripts/sounds.con (191808 bytes)
16Including: scripts/music.con (3666 bytes)
17Including: scripts/text.con (12575 bytes)
18Including: scripts/levels.con (7633 bytes)
19Including: scripts/customize.con (6567 bytes)
20Including: scripts/subroutines.con (16878 bytes)
21Including: scripts/surfaces.con (110651 bytes)
22Including: scripts/draw.con (24750 bytes)
23Including: scripts/sectors.con (374828 bytes)
24Including: scripts/weapons.con (403793 bytes)
25Including: scripts/pickups.con (74629 bytes)
26Including: scripts/switches.con (152869 bytes)
27Including: scripts/props.con (293032 bytes)
28Including: scripts/dialog.con (40999 bytes)
29Including: scripts/player.con (340291 bytes)
30Including: scripts/screens.con (42167 bytes)
31Including: scripts/menu.con (40291 bytes)
32Including: scripts/inventory.con (1355 bytes)
33Including: scripts/particles.con (292072 bytes)
34Including: scripts/enemies.con (598362 bytes)
35Compiled 995820 bytes in 146ms

BAD

1EDuke32 r8043
2Built Aug 20 2019 20:21:56, GCC 7.2.0, 32-bit 
3Using C:/eduke32_win32_20190820-8043/ for game data
4Running on Windows XP Service Pack 3 (build 5.1.2600)
5Initializing SDL 2.0.10
6Searching for game data...
7warning: number 0x007843075dd10030 truncated to 32 bits.
8Using "fury.grp" as main game data file.
9Compiling: scripts/main.con (50245 bytes)
10Including: scripts/tokens.con (27554 bytes)
11scripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conscripts/tokens.conIncluding: scripts/names.con (59980 bytes)
12Including: scripts/sounds.con (191808 bytes)
13Including: scripts/music.con (3666 bytes)
14Including: scripts/text.con (12575 bytes)
15Including: scripts/levels.con (7633 bytes)
16Including: scripts/customize.con (6567 bytes)
17Including: scripts/subroutines.con (16878 bytes)
18Including: scripts/surfaces.con (110651 bytes)
19Including: scripts/draw.con (24750 bytes)
20Including: scripts/sectors.con (374828 bytes)
21scripts/sectors.conscripts/sectors.conscripts/sectors.conscripts/sectors.conIncluding: scripts/weapons.con (403793 bytes)
22scripts/weapons.conscripts/weapons.conIncluding: scripts/pickups.con (74629 bytes)
23Including: scripts/switches.con (152869 bytes)
24Including: scripts/props.con (293032 bytes)
25Including: scripts/dialog.con (40999 bytes)
26Inclu

It's great how this game is released and immediately the VOGONS community says "let's run it with ancient OS's" hahaha!

What goes around comes around - nowadays it is "Very new games on old systems!"

Another small tidbit of an information from Discord:

1you shouldn't use the eduke32 binary
2you should use one compiled with the FURY=1 flag
3yes, you can boot it up but it will eventually slow down to a crawl or crash
4There are some things that are specific to duke that do not get handled properly in fury and have been fixed in source level

Thanks.

http://svn.eduke32.com/log.php?repname=eduke3 … ath=%2F&isdir=1&

https://forums.duke4.net/topic/8181-ion-fury/ … post__p__327495

Regular builds wont have support for a while since there are manual overrides done on source level for things that we can't do in a modular fashion from CON.
We used eduke32 binaries a lot when testing stuff internally as well between revisions.

It's up to the guys if they want to build a standalone binary alongside regular duke binary (would make sense in a way since other "from scratch" projects could benefit from this)

Found this which does execute on XP 32bit but requires "GetTickCount64" which requires Vista. So Vista+ 32bit OS should work:
http://www.mediafire.com/file/w70bv4yddm2ccos … 0190821.7z/file

This build also works with 98 w/ kernelex and 2000 blackwingcat extended core.

I'll look into SDL 1.2 with the latest source.

DosFreak wrote:

Found this which does execute on XP 32bit but requires "GetTickCount64" which requires Vista. So Vista+ 32bit OS should work:
http://www.mediafire.com/file/w70bv4yddm2ccos … 0190821.7z/file

Assuming GetTickCount64 is the only >NT5 API call, i assume it can be easily mitigated using UncleVasya's "EU4_WinXP_fix" (contrary to the name, it should work for any game too, that will have >NT5 API calls, which this patch has reimplemented, for ex. the program's kernel32 implementation [zernel32.dll] will take care of those function calls: GetTickCount64; K32GetProcessMemoryInfo; InitializeCriticalSectionEx; GetThreadID; QueryFullProcessImageNameA) - https://github.com/UncleVasya/EU4_WinXP_fix

Unpack the latest version's archive contents into the folder with the eduke32 files, open command prompt and navigate to the said folder's path, and assuming the main exes should be patched - input this:

1rundll32 zernel32.dll,PatchFile eduke32-if.exe
2rundll32 zernel32.dll,PatchFile mapster32-if.exe

Though to be very certain it will patch absolutely everything, just patch every exe and dll in the eduke32 folder. Launch and hope that it will solve things for XP.

I haven't tested this patch on this build in a machine with XP on it, but assuming everything goes perfectly and that it's the only API call that needs to be patched, there are certain chances that it will work.