Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
johnhanlon

Is there a direct Windows port of Vanilla Doom?

Recommended Posts

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.

Share this post


Link to post

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 by Edward850

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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!

Share this post


Link to post
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! 

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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).

 

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×