[MrFlibble]

I checked out the latest build with DOSBox a while ago but it crashed on startup.

I think it would actually be interesting if there was a DOS version of Ion Fury optimised for mid-90s hardware on a par with that which would handle Duke3D. That would likely involve some noticeable level modifications, similar to console ports of Doom, or maybe a complete overhaul of the levels altogether.

[Sanek]

MrFlibble, on 20 August 2020 - 08:37 AM, said:

I checked out the latest build with DOSBox a while ago but it crashed on startup.

I think it would actually be interesting if there was a DOS version of Ion Fury optimised for mid-90s hardware on a par with that which would handle Duke3D. That would likely involve some noticeable level modifications, similar to console ports of Doom, or maybe a complete overhaul of the levels altogether.

Isn't they promised that Ion Fury will be based on the actual DOS Build back when they first announced the game?

[Phredreeke]

No?

TerminX, on 26 July 2015 - 10:18 AM, said:

It doesn't run in DOS.

[MrFlibble]

Sanek, on 20 August 2020 - 09:09 AM, said:

Isn't they promised that Ion Fury will be based on the actual DOS Build back when they first announced the game?

I think it was something discussed or suggested by someone from the users here but not promised by the developers.

[Hendricks266]

Yeah. We never, ever promised this. It would be cool, but there is no reason to work on this other than for fun. This claim originated from the annoying noob population obsessed with conformity: "it's not a Build game unless it runs on DOS", "Shelly needs a quick kick exactly like Duke", "Fury needs a shareware release or else it's not a real 3D Realms game", "Shelly needs a rocket launcher just like every other FPS", "Fury needs a full-width status bar like the old games", "Shelly needs an exaggerated Jessica Rabbit-like character design to indulge my sexual titillation", etc.

[Phredreeke]

It's just going to be too slow to be playable under DOS anyway.

[Lobo4]

Well, I will repeat myself, sorry, however I would like to encourage for very good reason to continue temporarily the development of EDuke32 DOS port.

There is a nasty bug never corrected and more than 23 years old on the original binaries of Exhumed.

Even the author of the excellent is welcome DeHacker confirms that the problem is specific to the (very old) routines of the game :

(from ERRNOTES.TXT "Voodoo graphic cards may not properly support anything except mode 320x200. Try to use UniVBE, NOLFB or other VESA related tools. You may not have this
issue with Duke Nukem 3D and some other Build games, because PowerSlave / Exhumed uses very old Build engine version with completely different VESA graphic related routines.")

An overhaul of the engines of old cult games for the new platforms, coupled with a DOS update would be royal !

The DOS is easy to use and moreover it has never disappeared thanks to its nature of reaching low level hardware.

In short if it doesn't take too much time and it's possible.

[Phredreeke]

This is EDuke32 for DOS though, not PCExhumed for DOS.

[Hendricks266]

EDuke32 for DOS covers most bases with regard to the engine and audiolib. I would like to upstream the obvious changes made to this branch in the name of portability. It might be enough to get DOS versions of the original games working. Fury is a different story.

[MrFlibble]

From what I gather, EDuke32 for DOS is still a behemoth that wants a lot more resources than any of the original 16-bit DOS programmes. And it is certainly not suited to be run in DOSBox.

I wonder how much would have to be sacrificed in terms of features if someone wanted to make a DOS EDuke version (possibly EDuke16, even) that would be as functional on lower spec DOS machines, kind of like FastDoom. Is it even feasible, or is the Build engine core feature set too vast to even consider this as a theoretical possibility?

Or to put it the other way round, if we wanted EDuke to be optimised for low-end DOS machines and/or DOSBox, how far beyond the feature set of the bootleg Mega Drive port would it end up? (let's imagine there's a backport that also involves simplifying level geometry if needed).

[oasiz]

One would need to re-implement the ASM routines that have been ripped out ages ago.

In other words, quite a bit of work.

[NY00123]

Anybody who's interested can grab the sources for my unofficial DOS port and then check them out.

As I already wrote beforehand, there were unfortunately multiple problems that I went through with this port, mostly instabilities while running Duke3D under EDuke32-DOS using a specific environment or two.

One main concern that's present for 32-bit DOS apps, making use of DPMI, is the need to lock certain chunks of memory, especially data accessed by interrupt handlers.
There was a kind of an attempt of mine to lock anything on startup, but this isn't necessarily reliable. It's also possible that the specific environment in which you run the game can override certain behaviors related to memory management.

Eventually, this was mostly an experiment done to see if I could run Ion Fury under DOS, at least with a relatively new PC.
The answer was that under the right conditions, and with an important feature being disabled, I could start the Preview Campaign and then finish it. The feature that I had to disable was the saving of snapshots, as you're moving between differing hub maps belonging to the same hub.

oasiz, on 01 September 2020 - 12:08 PM, said:

One would need to re-implement the ASM routines that have been ripped out ages ago.

In other words, quite a bit of work.

From what I recall, EDuke32 still has assembly versions of differing pragmas; It also has a.masm and a.nasm. What it does not have is assembly code for the low-level audio mixing routines.

EDuke32, however, added (and modified) so much over the original, that its system requirements would obviously be higher, even if we ignore the differences in performance between ASM code and C. Higher memory requirements was actually a potential contributor to problems that I had experienced under at least a couple of setups of DOSBox variants, like crashes.

[Phredreeke]

MrFlibble, on 01 September 2020 - 12:01 PM, said:

And it is certainly not suited to be run in DOSBox.

If you're using DOSBox when a native version is available you're doing it wrong...

MrFlibble, on 01 September 2020 - 12:01 PM, said:

I wonder how much would have to be sacrificed in terms of features if someone wanted to make a DOS EDuke version (possibly EDuke16, even) that would be as functional on lower spec DOS machines, kind of like FastDoom. Is it even feasible, or is the Build engine core feature set too vast to even consider this as a theoretical possibility?

Even if you ignore the raw performance difference between 286 and later CPUs, the memory manager would have to be rewritten for the 64kb memory segments used before the 386 allowed for a flat memory model.

[Radar]

Reimplementing the inline Assembly code would be the easiest task and is near trivial.

[Hendricks266]

Ken's ASM software renderer has not been removed and could be used. I know of no other assembly code that has been removed unless I verified that modern compilers, including the GCC in the DJGPP toolchain used for NY's port, gave the same or better output.

The original games were not 16-bit. They were 32-bit. That's why they needed DOS/4GW.