Is there a direct Windows port of Vanilla Doom?

[johnhanlon]

Forgive me if I am asking something that has been asked before, but I couldn't immediately find this question answered anywhere else. 

 

I am curious if there is a direct, plain port of the original build of doom to modern Windows. I am aware of Doom95 and Chocolate and most if not all of the popular sourceports, but I am curious if there is a plain port that doesn't really change anything. As I understand it, Chocolate Doom is more of a simulator of original Doom engine rather than a plain port of it. Doom95 is very close to what I'm thinking of, but it's not entirely bugless on modern Windows, those I believe it worked the last time I tried it. Of course, if I am blatantly misunderstanding something, I wouldn't mind being corrected.

[Edward850]

Chocolate Doom is a direct and 110% accurate source port of Vanilla Doom. "Simulator" is meaningless terminology in this context as well, we don't have any source ports classed as a "simulator".

Although I suppose Vavoom could qualify as a simulation-port if you wanted to give meaning to the word, given that its playsim is a reinterpretation/reimplementation of Doom's frame logic into a Quake-esc environment.

Edited January 13, 2019 by Edward850

[johnhanlon]

9 minutes ago, Edward850 said:

Chocolate Doom is a direct source port of Vanilla Doom.

 

But doesn't Chocolate Doom purposely 'recreate' bugs from the original retail build? To me at least that implies that it wasn't a direct port, since if it was those bugs would already be present. The chocolate Doom wiki largely describes Chocolate Doom this way: a reproduction. Sure, I could just be misinterpreting the language, but that sounds like it wasn't a direct port

 

Though I know some very basic coding, that sort of project is way over my head, so I guess maybe one has to actually remake the engine as opposed to changing syntax or whatever, just because of the structuring of the source code between platforms, languages, etc.

[ETTiNGRiNDER]

3 minutes ago, johnhanlon said:

But doesn't Chocolate Doom purposely 'recreate' bugs from the original retail build? To me at least that implies that it wasn't a direct port, since if it was those bugs would already be present. The chocolate Doom wiki largely describes Chocolate Doom this way: a reproduction. Sure, I could just be misinterpreting the language, but that sounds like it wasn't a direct port

If you define things that strictly, then there isn't and never will be a port that matches what you're looking for, since A) the source code as released was for the Linux version of Doom, not the DOS one and B) code for some parts of the DOS EXE (the sound system at the very least) were left out due to licensing problems.

[Edward850]

8 minutes ago, johnhanlon said:

But doesn't Chocolate Doom purposely 'recreate' bugs from the original retail build? To me at least that implies that it wasn't a direct port, since if it was those bugs would already be present.

Vanilla Doom was a DOS game, some of its bugs were caused by memory issues related to being in a DOS environment, and would either behave differently or crash catastrophically if you were to make a direct port. Best example of this is oddly in Strife, where one of the things it did was write data to player null pointers. If you were to do that in Windows it'll die instantly.

Other bugs were things that were actually fixed/changed in the Linux Doom source release and thus was code that had to be changed back to match Vanilla behavior. As this was done based on reverse engineering and disassembly, we can be sure the code is the same.

8 minutes ago, johnhanlon said:

The chocolate Doom wiki largely describes Chocolate Doom this way: a reproduction. Sure, I could just be misinterpreting the language, but that sounds like it wasn't a direct port

You are misinterpreting the language. Programming doesn't work in quite such absolutes.

[johnhanlon]

3 minutes ago, ETTiNGRiNDER said:

If you define things that strictly, then there isn't and never will be a port that matches what you're looking for, since A) the source code as released was for the Linux version of Doom, not the DOS one and B) code for some parts of the DOS EXE (the sound system at the very least) were left out due to licensing problems.

Thanks a bunch, that was exactly what I was curious about!

[johnhanlon]

3 minutes ago, Edward850 said:

Vanilla Doom was a DOS game, some of its bugs were caused by memory issues related to being in a DOS environment, and would either behave differently or crash catastrophically if you were to make a direct port. Best example of this is oddly in Strife, where one of the things it did was write data to player null pointers. If you were to do that in Windows it'll dies instantly.

Other bugs were things that were actually fixed/changed in the Linux Doom source release and thus was code that had to be changed back to match Vanilla behavior. As this was done based on reverse engineering and disassembly, we can be sure the code is the same.

You are misinterpreting the language. Programming doesn't work in quite such absolutes.

Thanks! 

[Edward850]

In addition, if it means anything, demo compatibility in Doom requires the same code to be in place as the demo files are only recordings of player inputs, and thus any differences in any algorithm or behavior means the demo will desync in a sort of butterfly effect. If you can watch the attract demos in the title screen or the latest Zero Master TAS without them desyncing, your gameplay is 1:1 the same.

[TheMightyHeracross]

The closest you will get to 100% directly playing the original games on Windows is using DOSBOX to run the original .EXE files themselves. Otherwise, you're not going to beat Chocolate Doom.

[Apaul27]

DOS BOX and Chocolate Doom are the best choices to play vanilla Doom directly on Windows.

[Grazza]

7 hours ago, Edward850 said:

If you can watch the attract demos in the title screen or the latest Zero Master TAS without them desyncing, your gameplay is 1:1 the same.

Well, you have stated this a little imprecisely, as I expect you are aware. A demo playing back incorrectly is proof of a difference. Any particular demo playing back correctly simply provides a lack of evidence of a difference.

 

You can find plenty of demos that play back with ports that don't emulate vanilla very accurately. For instance, some nomos even work in Legacy. And Final Doom demos play back c. 60% of the time when Doom2.exe behaviour is applied (and vice versa).

 

[fraggle]

9 hours ago, johnhanlon said:

But doesn't Chocolate Doom purposely 'recreate' bugs from the original retail build? To me at least that implies that it wasn't a direct port, since if it was those bugs would already be present. The chocolate Doom wiki largely describes Chocolate Doom this way: a reproduction. Sure, I could just be misinterpreting the language, but that sounds like it wasn't a direct port

Edward has already done a great job explaining things, but just to add a bit more flavour:

 

"Plain port of the source code to Windows and other modern OSes" was pretty much literally the original design goal for Chocolate Doom and completed in the first few months of the project.

 

It quickly became apparent that there are some far more subtle details which aren't immediately obvious. Even if you change nothing in the code itself, the behaviour can end up being different, so demos recorded with vanilla Doom end up playing back differently. This fix is the classic example where a particular demo would desync but only if compiled for 64-bit.

 

So what's really wanted is not a plain port but the DOS behaviour on modern OSes. This has been something of an uphill battle, in no small part because the C programming language Doom is written in has a long list of undefined behaviours where things can vary depending on CPU, compiler or operating system. But I'm relatively confident that Chocolate nowadays pretty much exactly matches the DOS vanilla behaviour.

[MFG38]

I'd say playing on DOSBox is as close to a "direct" port as you're gonna get.