There's no 3d accelerated DOS port. Not of Quake, not of Doom.

Also please fix your wiki link to Doomwiki.org instead.

I figured as much.. Nice to know for sure though

Still worth investigating the updated ports for their bugfixes - ones that supported higher resolutions would also be interesting.

Care to explain what is wrong with the link?

Ok so there's still VQuake, but that's not OpenGL and is more like a software renderer with help from the card 😜

The most recent one I can think of is this MBF for DOS

There's also some later versions of Vavoom that still urn in DOS

For DOS - I'd say BOOM/MBF. They basically give you the original experience, with some UI improvements, bug fixes, engine limit removals, more customization options, and a few new level design elements which are nice but not very intrusive.

"Generally the original Doom is 25% faster on 486s, because of the Mode-X code"

That's a bummer with this port. Good suggestions tho!

Shame there was no port that turns on 3dfx anti aliasing or bilinear filtering in these games.. looks all blurry in descent 2 and blood but nice to have the option. I'm no coder but possibly simple to do?

Turning a sector/line span driver into a polygonal world for a 3d card to process is far from simple, and on a 486 at that point, it'd be far slower than just running it in software.

Which is why i only suggested filtering/anti-aliasing.. Doing this has some precedent with the games i mentioned (filtering at least)

For a 486, you'd do well to go with a patched up version of vanilla Doom with expanded limits and greater stability: Doom+

You may also try Doom 1.91 for an improved demo recording experience.

Lo Wang wrote:

For a 486, you'd do well to go with a patched up version of vanilla Doom with expanded limits and greater stability: Doom+

You know, I thought about this, and the thing is that any scene that could benefit from such a patch, because it exceeds the original limits, will probably be way too slow for a 486 anyways. So it will have no practical advantage over the original EXE.

dr_st wrote:

Lo Wang wrote:

For a 486, you'd do well to go with a patched up version of vanilla Doom with expanded limits and greater stability: Doom+

You know, I thought about this, and the thing is that any scene that could benefit from such a patch, because it exceeds the original limits, will probably be way too slow for a 486 anyways. So it will have no practical advantage over the original EXE.

Not necessarily so. E.g. A visplane overflow doesn't mean the scene would trigger a slowdown if it were to be rendered properly. You can indeed be well over the visplane limit on a 486 and retain sufficient speed. Problem is, it takes maps made specifically for this patched up version of the vanilla executable because not many people, if any, designed and distributed maps that would crash the original engine back when there were no source ports.

I think I'll compare all the latest DOS supporting versions on a 486. So far I've got:

Doom Legacy 1.41
Vavoom 1.17
MBF 2.04
Zdoom 1.17
Eternity Engine 3.31

Any others worth looking at?

Edit:

Edge: but I can only find version 1.24 (1.27 is supposed to support dos?).
CDoom: Can't find this at all so far
Doom+ 1.92.2?
Doom2+?

IIRC Cdoom was a modified DOSDoom with a portuguese translation

kreats wrote:

"Generally the original Doom is 25% faster on 486s, because of the Mode-X code"
That's a bummer with this port. Good suggestions tho!

That is not just an issue with this port I worked on, but with all of them. No one ever recreated the Mode-X code that is used in the original DOS releases. The source for that part was never released, and proper Mode-X support requires a lot of messy code and 'planar' image buffering. By then everyone was just glad Pentiums could run 3D games in linear modes just fine.

gerwin wrote:

That is not just an issue with this port I worked on, but with all of them. No one ever recreated the Mode-X code that is used in the original DOS releases. The source for that part was never released, and proper Mode-X support requires a lot of messy code and 'planar' image buffering. By then everyone was just glad Pentiums could run 3D games in linear modes just fine.

Curious. Why wasn't this part of the source released? Was there a licensing issue like with the music library? So what did the source port makers do in lieu of it?

The Linux version source was released, the DOS version source was not...
Here is a nice read: 10 years of Doom - A Slightly Condensed Genealogy of DOOM Source Ports
Also consider that in 1997 there was not much interest in true Mode-X usage. Mode-X with planar buffering is hack to get a speed gain on 386s and early 486s, which would otherwise be unable to transfer the 320x200 pixels at the desired framerates. For Pentiums it is just a unnecessary annoyance for the Developers.
Linear Mode 13h was there already, and became the easier choice. Then Pentiums made VESA modes a viable option for action games as well.

There are four ways I can think of to draw in 320x200 8bpp in DOS:
1-Mode 13h, unfortunately without page flipping.
2-Mode-X with planar image buffering, with or without page flipping.
3-Mode-X while keeping the image buffers linear, and convert things during the screen draws. No speed gain, but does allow for page flipping.
4-VESA mode 320x200 8bpp, with or without page flipping.

MBF 2.04 supports 1+3+4.

Thank you for the link. It was a very pleasant and informative read indeed. 😀

Does the GPLed Hexen/Heretic code have the mode-x stuff?

I suppose not. One could test it with DosBox Debug output, to check which video mode is initialized.
Some pointers here:
http://www.doomworld.com/vb/doom-general/5786 … requirements/2/