Doom and Strife source code restoration

[nukeykt]

Hi,

As you know Doom source code as released in 1997 was not for original DOS version, but rather was Linux version cleaned up by Bernd Kreimeier. During clean up, code specific for DOS version was stripped out. Another big change was reorganizing header files, specifically doomdef.h, p_local.h and r_local.h were split to smaller header files. This is where Heretic sources comes in handy. Raven released their code as is, without any sort of clean up. Specifically it has majority of Doom's DOS specific code and header files organization is very close to Doom's original form.

The goal of this project is to combine both these sources and get codebase that is close to the Doom's original codebase as possible. Actually I had this idea for a pretty long time and had previous attempts in the form of PCDoom and PCDoom-v2. This time I decided to start mostly from Heretic sources, gradually reverting Raven's code changes by comparing it to Linux Doom sources. I targeted id Anthology Final Doom EXE as it was closest to linuxdoom sources. Eventually I got compiling EXE, but as expected it had lots of differences to original EXE files. Then I gradually fixed all the differences and got EXE that identical to original EXE by behaviours. Once I covered both revisions of Final Doom, NY00123 volunteered and also covered a lot more Doom revisions down to prototype v1.666. This also includes Chex Quest.

Meanwhile I decided to try to do the same for Strife executable using restored Doom code. As Strife source code was never released, I had to rely on reverse engineering of original EXE file. After finishing initial reversing resulted EXE had some differences to original EXE. Eventually after lots of trial and error and not without some help from NY00123 we eventually got EXE that identical to original EXE (up to usual garbage data between string literals and differences due to __LINE__ macro).

As original release of Doom this does not include proprietary DMX code. You can use APODMX replacement library instead to get complete GPLv2 compatible codebase.

 

TL;DR These repositories recreate different revisions of Doom and Strife codebase. Compiled EXE files are identical to original EXE in term of behaviours. In total both repositories cover 15 different revisions of Doom, Strife and Chex Quest.

 

List of covered Doom revisions:

Spoiler

Doom II prototype v1.666

Doom Shareware / Doom II early v1.666

Doom v1.666

Doom II v1.7

Doom II v1.7a

Doom II French v1.8

Doom / Doom II v1.8

Doom / Doom II v1.9

Doom v1.9 Special Edition prototype exe

The Ultimate Doom

Final Doom

Final Doom, later id Anthology revision

Chex Quest

 

List of covered Strife revisions:

Spoiler

Strife v1.3

Strife v1.31

 

Doom repository
Strife repository

[JustAthel]

Nobody's commented on this yet, so let me be the first to say that I'm actually pretty impressed by this, it's a pretty neat little thing to have to look at. Great work!

[Redneckerz]

On 1/29/2022 at 1:48 PM, nukeykt said:

Hi,

As you know Doom source code as released in 1997 was not for original DOS version, but rather was Linux version cleaned up by Bernd Kreimeier. During clean up, code specific for DOS version was stripped out. Another big change was reorganizing header files, specifically doomdef.h, p_local.h and r_local.h were split to smaller header files. This is where Heretic sources comes in handy. Raven released their code as is, without any sort of clean up. Specifically it has majority of Doom's DOS specific code and header files organization is very close to Doom's original form.

Would it be useful to have the original Doom version on NeXT computers, called NeXTDoom to study at? Or were you already aware of that one?

 

Here is a ZDoom thread with more details.

On 1/29/2022 at 1:48 PM, nukeykt said:

The goal of this project is to combine both these sources and get codebase that is close to the Doom's original codebase as possible. Actually I had this idea for a pretty long time and had previous attempts in the form of PCDoom and PCDoom-v2.

So if i get this correctly, this is a recreated source, but not a reverse engineering effort for Doom atleast, correct?

On 1/29/2022 at 1:48 PM, nukeykt said:

This time I decided to start mostly from Heretic sources, gradually reverting Raven's code changes by comparing it to Linux Doom sources. I targeted id Anthology Final Doom EXE as it was closest to linuxdoom sources. Eventually I got compiling EXE, but as expected it had lots of differences to original EXE files. Then I gradually fixed all the differences and got EXE that identical to original EXE by behaviours. Once I covered both revisions of Final Doom, NY00123 volunteered and also covered a lot more Doom revisions down to prototype v1.666. This also includes Chex Quest.

Very impressive showing considering not just one, but several versions were recreated. And based on Anthology gurantees the latest version, so its a good one to have as a reference point.

I feel efforts like this are incredibly understated, but they are among the most important contribtions to Doom.

 

On 1/29/2022 at 1:48 PM, nukeykt said:

 

Meanwhile I decided to try to do the same for Strife executable using restored Doom code. As Strife source code was never released, I had to rely on reverse engineering of original EXE file. After finishing initial reversing resulted EXE had some differences to original EXE. Eventually after lots of trial and error and not without some help from NY00123 we eventually got EXE that identical to original EXE (up to usual garbage data between string literals and differences due to __LINE__ macro).

Paging @Quasar here considering a similar reverse engineering effort was undertaken for Strife VE. Perhaps he or someone else on the team may find this useful, or perhaps they have additional pointers?

On 1/29/2022 at 1:48 PM, nukeykt said:

As original release of Doom this does not include proprietary DMX code. You can use APODMX replacement library instead to get complete GPLv2 compatible codebase.

From what i understood from NY00123, APODMX utilizes a modified Apogee Sound System. Are there are any actual differences between APODMX and DMX itself?

 

Also, what's the plan with these executables? You say that they together from a complete GPLv2 codebase. Could those be used in situations that now still rely on propetairy Doom2.exe, such as FreeDoom?

 

If that's the case, how can we differentiate between Doom2.exe and its GPL-equivalent? DoomNew has a differing name and so does PCDoom, but how would those revisions be called to differentiate them from the original executables?

[Gibbon]

This is very impressive indeed, I'm assuming this needs a rather recent version of DJGPP to compile?  Since I tried on my DOS development box which has a DJGPP from 1998 and that died at your makefiles.

[nukeykt]

9 hours ago, Gibbon said:

This is very impressive indeed, I'm assuming this needs a rather recent version of DJGPP to compile?  Since I tried on my DOS development box which has a DJGPP from 1998 and that died at your makefiles.

Watcom compiler and Turbo assembler are needed to compile these sources. See notes-restoration.md file for recommended compiler versions.

 

9 hours ago, Redneckerz said:

Would it be useful to have the original Doom version on NeXT computers, called NeXTDoom to study at? Or were you already aware of that one?

 

Here is a ZDoom thread with more details.

I'm aware of its existence. but I don't have much desire/experience on reversing NextStep apps.

[nukeykt]

Quote

So if i get this correctly, this is a recreated source, but not a reverse engineering effort for Doom atleast, correct?

Very impressive showing considering not just one, but several versions were recreated. And based on Anthology gurantees the latest version, so its a good one to have as a reference point.

Some reverse engineering work was involved actually. Heretic for example rewrote video subsystem completely, so I had to reverse engineer it instead. Also comparison between original and reconstructed EXE for the most part was done by using dissassembler output.

 

9 hours ago, Redneckerz said:

From what i understood from NY00123, APODMX utilizes a modified Apogee Sound System. Are there are any actual differences between APODMX and DMX itself?

 

Also, what's the plan with these executables? You say that they together from a complete GPLv2 codebase. Could those be used in situations that now still rely on propetairy Doom2.exe, such as FreeDoom?

 

If that's the case, how can we differentiate between Doom2.exe and its GPL-equivalent? DoomNew has a differing name and so does PCDoom, but how would those revisions be called to differentiate them from the original executables?

Yeah, there're some substational differences between Apogee SS+APODMX and DMX. APODMX does not implement all the DMX features (FM double voices, CODEC/ENSONIQ support, GSS sounds, etc.), but it should be good for general use.
Good question. I guess it could be called PCDoom again, heh. Actually it started as PCDoom-v3, but then I suggested NY00123 to include this to gamesrc-ver-recreation instead.

[NY00123]

As I wrote in the related thread beforehand, reversing Doom was something I thought about, but the lack of original Doom sources for DOS was the main blocker. Sure, I could start, and if done correctly, get to some point; The biggest problem, as usual, would probably be that differences from the original codebase for DOS would lead to a different order of global variables as a part of the BSS (i.e., variables which aren't explicitly initialized).

 

At least there isn't much of a need for me to do it at this point. ok, I technically still can, but as expected, I currently don't have an incentive.

 

On 2/1/2022 at 3:23 PM, Redneckerz said:

Also, what's the plan with these executables? You say that they together from a complete GPLv2 codebase. Could those be used in situations that now still rely on propetairy Doom2.exe, such as FreeDoom?

 

If that's the case, how can we differentiate between Doom2.exe and its GPL-equivalent? DoomNew has a differing name and so does PCDoom, but how would those revisions be called to differentiate them from the original executables?

 

At least from my point of view, what these code bases aim to do is grant access to reconstructed code for differing versions of games and libraries. This can be very useful for source ports inspired by Chocolate Doom, emulating the features of specific game versions in other ports, or even just studying the technical differences.

 

Regarding the names, so far, I haven't given any unique name. For source ports, it makes sense to use separate names of ports in order to differentiate them by features. Here, however, you have gamesrc-ver-recreation, and within it, there are differing trees which are used for recreating executables with behaviors that mostly match originals. Sometimes, these are 100% the original exes if appropriately built (say for multiple Wolf3D versions). So for something like Doom, the closest matching name I may currently think of is really "Vanilla Doom".

 

If, on the other hand, you referred to the use of APODMX, that's a good question. I'm really, really careful of making any promise, but a specific situation might change at some point (emphasis on the last few posts): https://github.com/chocolate-doom/chocolate-doom/issues/639

 

Regardless, for now, APODMX is an option, so maybe PCDoom/PCHeretic/PCHexen/PCStrife can work; Albeit PCHeretic is longer than 8 characters. So, maybe PCDoom/PCTic/PCHex/PCStrife? Not that I give this a high priority (at least for Heretic or Hexen), heh.

 

Even then, it's only the sound library which is replaced; The Doom/Heretic/Hexen/Strife code remains 100% identical, outside of possible differences stemming from differing compiler or linker outputs.

 

18 hours ago, nukeykt said:

Some reverse engineering work was involved actually. Heretic for example rewrote video subsystem completely, so I had to reverse engineer it instead. Also comparison between original and reconstructed EXE for the most part was done by using dissassembler output.

 

Indeed. It's not just for Doom. For other games and libraries which I worked on, like Wolfenstein 3D, I also had to repeatedly compare executables, at least while they weren't sufficiently matching; Comparing disassembler outputs is a good way of doing this. It tends to be easier when there isn't missing code that I need to recreate (e.g., a whole function), but there are situations in which this is required.

[Madmaster0083]

I heard of strife when the developers of vavoom reverse engineered the thing. Its very cool to finally see that the source codes for doom and strife are fully reconstructed.

[Redneckerz]

On 2/2/2022 at 12:18 AM, nukeykt said:

Some reverse engineering work was involved actually. Heretic for example rewrote video subsystem completely, so I had to reverse engineer it instead. Also comparison between original and reconstructed EXE for the most part was done by using dissassembler output.

 

Yeah, there're some substational differences between Apogee SS+APODMX and DMX. APODMX does not implement all the DMX features (FM double voices, CODEC/ENSONIQ support, GSS sounds, etc.), but it should be good for general use.
Good question. I guess it could be called PCDoom again, heh. Actually it started as PCDoom-v3, but then I suggested NY00123 to include this to gamesrc-ver-recreation instead.

Is Heretic's video subsystem that much different from Doom's? Since Heretic is often described as ''Doom in a fantasy jacket'' and Hexen being the game where a lot of extensions were introduced, can you say something about what the differences are between Heretic's and Doom's video subsystem?

 

Regarding APODMX: Noted, so its more of a hybrid system in that sense. Are the features now missing in APODMX from DMX patented or otherwise excessively difficult to implement in a GPL fashion?

 

I mean, if its called PCDoom-v3, it makes it perfectly clear what it's heritage is :P

 

On another note. Most, if not all Doom versions are now recreated. What are your thoughts about DeHacked, giving its place in history? Have you had any ideas on recreating that aswell? I mean, the DHE source is available, so the recreation part is less... needed, but in general, what are your thoughts there/

On 2/2/2022 at 7:03 PM, NY00123 said:

At least from my point of view, what these code bases aim to do is grant access to reconstructed code for differing versions of games and libraries. This can be very useful for source ports inspired by Chocolate Doom, emulating the features of specific game versions in other ports, or even just studying the technical differences.

That i can see perfectly. But being that they are recreations, this does open the door to, say, an easier platform to turn things standalone.

 

Take @OpenRift's efforts into making REKKR compatible with DOS, for instance. DeHacked could be used to make a new Doom2.exe utilizing its DoomHack function, but that executable technically can't be shared because it does modify iD's executable. Granted, id Software has had a lean approach to this and generally does not care that much (Considering you will need an IWAD anyway to use that executable), its still a liability.

 

But if you were to use a recreated executable that is under the GPL, would DeHacked still work? Would a libre executable be possible and thus make it easier for REKKR to be a native DOS game without restrictions?

 

I am also tagging @Doomkid here for this side-tangent because i feel a recreated source under the GPL provides greater flexibility than any Doom2.exe built from source code release since that cannot include DMX and the built code is still id Software-made. But with your recreated code that is different but achieves the same thing, that legalese restriction is gone now, if i am correct?

On 2/2/2022 at 7:03 PM, NY00123 said:

Regarding the names, so far, I haven't given any unique name. For source ports, it makes sense to use separate names of ports in order to differentiate them by features. Here, however, you have gamesrc-ver-recreation, and within it, there are differing trees which are used for recreating executables with behaviors that mostly match originals. Sometimes, these are 100% the original exes if appropriately built (say for multiple Wolf3D versions). So for something like Doom, the closest matching name I may currently think of is really "Vanilla Doom".

That name would be perfectly apt, but that is also already a general descriptor for stock Doom. Chocolate Doom deviated on this in a clever way by referring to a specific taste and it being for modern computers. These recreated versions are still for DOS - Maraakate used DoomNew for his build with proper DMX support, so how can these be deviated?

 

Perhaps... VDoom? So you have VDoom 1.9, VDoom2 1.9 and so forth... There isn't a port named like it, its elegant though but it does not exactly highlight its the stock Doom, except recreated.... VADoom? Or just PCDoom?

On 2/2/2022 at 7:03 PM, NY00123 said:

So, maybe PCDoom/PCTic/PCHex/PCStrife? Not that I give this a high priority (at least for Heretic or Hexen), heh.

I mean that would work just fine :P I know this isn't high priority, but the results of your work should be obvious to anyone - Calling it Vanilla Doom would both confuse people, and in my eyes it diminishes the effort shown on display here.

[SaladBadger]

50 minutes ago, Redneckerz said:

Is Heretic's video subsystem that much different from Doom's? Since Heretic is often described as ''Doom in a fantasy jacket'' and Hexen being the game where a lot of extensions were introduced, can you say something about what the differences are between Heretic's and Doom's video subsystem?

Yes, it is. The core difference is that Doom uses a planar video mode commonly called mode X, whereas Heretic uses a linear video mode, the stock mode 13h. This change does have a few downsides, like removing the ability to do double buffering in hardware and the low detail mode, but is potentially faster since the drawing code doesn't need to specify what banks it should be writing to.

 

Additionally the multiple software framebuffers scheme that Doom had isn't present at all in Heretic. Functions like I_Update are also considerably different. And now that I'm looking at it closer, the update scheme is a lot different, not using the concept of a "dirty box" like in Doom.

[OpenRift]

Nukey, you sir are an absolute gigachad of reverse-engineering. Like seriously, this is awesome. 

 

I think what I'm most curious of is if using APODMX in the compile will still emulated all the quirks of vanilla Doom's MUS format. Because if so, that could be a big help for emulating those quirks in Chocolate Doom's MIDI system.

 

Also, this could be a great basis for a fully functional DOS EXE for Sigil, as @xttl's SIGEXE while great in singleplayer, has issues when trying to run multiplayer.

Edited February 6, 2022 by OpenRift

[CounterOfDefeat]

so source code is not original?

[OpenRift]

2 minutes ago, CounterOfDefeat said:

so source code is not original?

The released Doom source is based on the Linux Doom source code, yes.

[nukeykt]

41 minutes ago, OpenRift said:

I think what I'm most curious of is if using APODMX in the compile will still emulated all the quirks of vanilla Doom's MUS format. Because if so, that could be a big help for emulating those quirks in Chocolate Doom's MIDI system.

It doesn't, Apogee Sound System uses MIDI as native music format, thus if input music is in MIDI format APODMX will send it to ASS as is. For MUS music it converts it to MIDI under the hood.

[OpenRift]

1 minute ago, nukeykt said:

 It doesn't, Apogee Sound System uses MIDI as native music format, thus if input music is in MIDI format APODMX will send it to ASS as is. For MUS music it converts it to MIDI under the hood.

Ohhh, okay. Thanks for the clarification.

[NY00123]

23 hours ago, Redneckerz said:

That i can see perfectly. But being that they are recreations, this does open the door to, say, an easier platform to turn things standalone.

 

Take @OpenRift's efforts into making REKKR compatible with DOS, for instance. DeHacked could be used to make a new Doom2.exe utilizing its DoomHack function, but that executable technically can't be shared because it does modify iD's executable. Granted, id Software has had a lean approach to this and generally does not care that much (Considering you will need an IWAD anyway to use that executable), its still a liability.

 

But if you were to use a recreated executable that is under the GPL, would DeHacked still work? Would a libre executable be possible and thus make it easier for REKKR to be a native DOS game without restrictions?

 

I am also tagging @Doomkid here for this side-tangent because i feel a recreated source under the GPL provides greater flexibility than any Doom2.exe built from source code release since that cannot include DMX and the built code is still id Software-made. But with your recreated code that is different but achieves the same thing, that legalese restriction is gone now, if i am correct?

 

I assume that distributing a modified exe was mostly a concern for id before the game was open-sourced, and later, because of DMX, if there was any. But with having not just Linux Doom, but also the reconstructed sources (and if it matters, a DMX replacement), I don't think there should be a problem anymore.

 

I didn't even think about applying .deh files with DeHackEd itself to any exe made via gamesrc-ver-recreation. From what I was reading, DeHackEd detects the game version by the exe size, so it's already expected to fail due to the lack of DMX or the relevant DOS/4GW stub. Even if these weren't a concern, there's more that could break. As long as everything the .deh file tells DeHackEd to change is exactly at the expected location in the exe, I think that patching will generally work, but this isn't necessarily the case. For instance, as written beforehand, global variables which aren't explicitly initialized in the C code might be ordered differently.

 

Generally speaking, I thought about gamesrc-ver-recreation more in terms of education, as well as the ability to use the code in ports to modern platforms, mostly ones inspired by Chocolate Doom.

 

23 hours ago, Redneckerz said:

That name would be perfectly apt, but that is also already a general descriptor for stock Doom. Chocolate Doom deviated on this in a clever way by referring to a specific taste and it being for modern computers. These recreated versions are still for DOS - Maraakate used DoomNew for his build with proper DMX support, so how can these be deviated?

 

Perhaps... VDoom? So you have VDoom 1.9, VDoom2 1.9 and so forth... There isn't a port named like it, its elegant though but it does not exactly highlight its the stock Doom, except recreated.... VADoom? Or just PCDoom?

 

I can't speak for other examples for DOS. DoomNew is indeed a DOS port which can use DMX, but it also has its own deviations, like support for the SimulEyes VR goggles. So, it makes sense for it to use a bit different take on the Doom name (or possibly NEWDOOM.EXE, the original name of the exe as outputted by the Watcom Linker in id Software).

 

What's in gamesrc-ver-recreation, on the other hand, generally aims to be not more than plain source code recreations. This is why I mentioned "Vanilla Doom", because that's really what you technically get (or at least, close enough).

 

If you're still looking for a name, I guess that something like "a part of gamesrc-ver-recreation" should work.

 

[Gibbon]

Still. I think a GPL port should at least be buildable with open source and free compilers. It kind of defeats the point of it if you need to use proprietary and 'questionably' obtained compilers to build it.  DJGPP and it's assembler would be nice and the porting process to it wouldn't be too difficult.

 

Also, doesn't the original EULA apply here?  Decompiling the original exes (which are still sold) I think is not totally legal.  A clean room reverse engineer is better.  I mean, this would be like decompiling and making a GPL binary for Doom 2016.

 

Not trying to be a party pooper.  But it's a legitimate question.

Edited February 6, 2022 by Gibbon

[Redneckerz]

35 minutes ago, NY00123 said:

I assume that distributing a modified exe was mostly a concern for id before the game was open-sourced, and later, because of DMX, if there was any. But with having not just Linux Doom, but also the reconstructed sources (and if it matters, a DMX replacement), I don't think there should be a problem anymore.

I don't think so either (Because distributing a modified DeHacked exe in general was never a issue so far: The /idgames archive forbade illegal Doom2.exe's because of this nature, but i agree, with the recreated source, this should (technically) be no problem anymore.

 

Perhaps as a representative Sponge could join in to confirm? Then again i don't want to take away his attention from his main work.

Quote

I didn't even think about applying .deh files with DeHackEd itself to any exe made via gamesrc-ver-recreation. From what I was reading, DeHackEd detects the game version by the exe size, so it's already expected to fail due to the lack of DMX or the relevant DOS/4GW stub. Even if these weren't a concern, there's more that could break. As long as everything the .deh file tells DeHackEd to change is exactly at the expected location in the exe, I think that patching will generally work, but this isn't necessarily the case. For instance, as written beforehand, global variables which aren't explicitly initialized in the C code might be ordered differently.

I guess the only way to find out is to test these recreated sources against some heavy hitting DeHacked wads and see where it stings. That is, if you are interested in seeing that tested.

 

From what i know DeHacked looks at a Doom executable by its file size and its SHA stamp. But don't quote me on that one.

Quote

Generally speaking, I thought about gamesrc-ver-recreation more in terms of education, as well as the ability to use the code in ports to modern platforms, mostly ones inspired by Chocolate Doom.

If that's the case then ill hereby tag @Gibbon considering his Sprinkled Doom work which extends Chocolate with Doom32 limits. Maybe support for the APODMX sound system is useful here?

Quote

I can't speak for other examples for DOS. DoomNew is indeed a DOS port which can use DMX, but it also has its own deviations, like support for the SimulEyes VR goggles. So, it makes sense for it to use a bit different take on the Doom name (or possibly NEWDOOM.EXE, the original name of the exe as outputted by the Watcom Linker in id Software).

I mean.. that could work as NewDoom. Or NewVanilla. I get that what you are getting is Vanilla Doom if they are compiled, but could you tell the recreated Doom2.exe apart from the original that way? Unless you go in depth, you don't. But NewDoom (Lets call it for now) does have some differences.

 

(Full disclosure: I basically want to highlight these recreations at the Wiki but i need to know what they are for. For educational purposes, ofcourse, but could they work as drop-in replacements for Doom2.exe and there by be a libre executable? That sort of thing.)

 

[Gibbon]

4 minutes ago, Redneckerz said:

From what i know DeHacked looks at a Doom executable by its file size and its SHA stamp. But don't quote me on that one.

If that's the case then ill hereby tag @Gibbon considering his Sprinkled Doom work which extends Chocolate with Doom32 limits. Maybe support for the APODMX sound system is useful here?

I mean.. that could work as NewDoom. Or NewVanilla. I get that what you are getting is Vanilla Doom if they are compiled, but could you tell the recreated Doom2.exe apart from the original that way? Unless you go in depth, you don't. But NewDoom (Lets call it for now) does have some differences.

 

For me to consider any dependency, it must be buildable and functional on Windows, Mac, Linux, BSD, Raspbian (RPI3) and Solaris.

[NY00123]

13 hours ago, Redneckerz said:

I don't think so either (Because distributing a modified DeHacked exe in general was never a issue so far: The /idgames archive forbade illegal Doom2.exe's because of this nature, but i agree, with the recreated source, this should (technically) be no problem anymore.

 

Perhaps as a representative Sponge could join in to confirm? Then again i don't want to take away his attention from his main work.

 

I'm not sufficiently familiar with idgames' history, and I currently still have a total of 0 direct uploads to idgames, so I'm not that familiar with specific rules. Is the restriction of distributing original Doom exes still in effect?

 

Outside of Final Doom, the last DOS version of doom2.exe is also available with shareware v1.9. The exes might not be allowed due to already being a part of other archives (and since required storage may get somewhat larger as multiple copies of the same exe get uploaded).

 

Also, generally speaking, I think that people will still prefer to let a mod be available with more than a standalone exe, be it a .deh file or source code.

 

13 hours ago, Redneckerz said:

I mean.. that could work as NewDoom. Or NewVanilla. I get that what you are getting is Vanilla Doom if they are compiled, but could you tell the recreated Doom2.exe apart from the original that way? Unless you go in depth, you don't. But NewDoom (Lets call it for now) does have some differences.

 

(Full disclosure: I basically want to highlight these recreations at the Wiki but i need to know what they are for. For educational purposes, ofcourse, but could they work as drop-in replacements for Doom2.exe and there by be a libre executable? That sort of thing.)

 

If it's about the Wiki, Nuke.YKT recently add a stub via this URL: https://doomwiki.org/wiki/Gamesrc-ver-recreation

I might create an account and add on my own, as there's information that might otherwise not really be known.

 

13 hours ago, Gibbon said:

For me to consider any dependency, it must be buildable and functional on Windows, Mac, Linux, BSD, Raspbian (RPI3) and Solaris.

 

Right now, I'm not aware of a port of apodmx to platforms differing from DOS.

What was ported to other platforms was the Apogee Sound System, as a part of at least a few Build Engine source ports, but probably also ROTT. JFAudioLib might be simpler to start with, while the code from EDuke32/NBlood supports OPL emulation and other additions. But it'll probably still not be something you can plug-in and get to immediately work with not more than a few minor changes. PC Speaker output will probably also not be functional for Doom, if the interest exists; That is, unless this was implemented for a ROTT source port.

Edited February 7, 2022 by NY00123

[OpenRift]

5 hours ago, Redneckerz said:

From what i know DeHacked looks at a Doom executable by its file size and its SHA stamp. But don't quote me on that one.

 

This is true, but also if you look in DEHACKED.INI near the bottom, you'll see something like this:

# The following are all optional, and are included only in the hopes that
# they might be used to fend off future Doom versions, if any more pop
# up.

# Doom version #
#        0 for Doom 1 1.666
#        1 for Doom 2 1.666
#        2 for Doom 2 1.7, 1.7a
#        3 for Doom x 1.9
#        4 for Ultimate Doom 1.9
#        5 for Final Doom 1.9 revision 1 (original, buggy)
#        6 for Final Doom 1.9 revision 2 (id anthology, fixed)
#        7 User defined
#
# Leave unset for autodetect.
#version = 6

# The size of the user-defined Doom exe file.
#size = 715493

# These are the offsets for the various data sections...
#thingoff   = 677472
#soundoff   = 645924
#frameoff   = 650396
#spriteoff  = 649844
#ammooff    = 638872
#weaponoff  = 638904
#textoff    = 691064
#cheatoff   = 642244
#textlength = 24072

I'm not entirely sure, but my guess is that you could theoretically set the file size, and various offsets for the different data sections manually and it could work with a compile of the recreation. I could be wrong though.

[NY00123]

15 hours ago, OpenRift said:

I'm not entirely sure, but my guess is that you could theoretically set the file size, and various offsets for the different data sections manually and it could work with a compile of the recreation. I could be wrong though.

 

Yeah, this seems to be the case. As I wrote earlier, if everything is matching the original exe in layout and size, including also DOS/4GW and DMX, then no change is expected to be needed; Otherwise, The exe size and offsets will have to be adjusted, at the least.

 

I do wonder how stable will this be. If I didn't mention it, I learnt that Watcom C (at least a version used for Heretic) may generate a bit different code even just by defining an unused environment variable; Yes, its output seems to partially depend on the environment, even if rarely.

 

My conclusion is that if anybody wants to use gamesrc-ver-recreation as a base for a DOS port of Doom, it might be better to include a proper .deh file loader, just like the various ports to modern platforms.

[OpenRift]

By the way, is the code in a state currently where it could be compiled? Or is it not ready for that yet?

 

EDIT: Scratch that, I should've read a bit closer.

Edited February 7, 2022 by OpenRift

[OpenRift]

On 2/1/2022 at 5:59 PM, nukeykt said:

Watcom compiler and Turbo assembler are needed to compile these sources. See notes-restoration.md file for recommended compiler versions.

Keep getting an error that says:

Can't recreate Doom EXE, you need a compatible version of
DMX headers under ..\dmx. You also need a compatible version of
the DMX library, again under ..\dmx. See makefile for more details.

It continues to say this even though I already have the required files located in ..\dmx. This also brings up a whole lot of other questions as well. How should my folders be structured in relation to Watcom, TASM and the src?

Edited February 8, 2022 by OpenRift

[Blzut3]

On 2/6/2022 at 1:49 PM, Gibbon said:

Also, doesn't the original EULA apply here?  Decompiling the original exes (which are still sold) I think is not totally legal.  A clean room reverse engineer is better.  I mean, this would be like decompiling and making a GPL binary for Doom 2016.

Your equivalence doesn't quite work since a majority of the code involved was officially released GPL be it Linux Doom, Heretic (which if we want to go down the rabbit hole one could even question if Raven had the proper sign off to release the parts of the Doom engine not covered by Linux Doom as GPL), or indirectly via SVE.  Otherwise I do believe that you would be correct that this style of reverse engineering would result in code that can only have a license assigned to it by the original rights holder.  Of course that's just strictly speaking, realistically I can't imagine anyone in their right mind splitting hairs over this.

 

It is good that you think about these things though, since far too often I see people shaming leaked source code and praising non-clean room reconstructed code despite that from what I can tell they should basically be the same legally.

[nukeykt]

5 hours ago, OpenRift said:

So notes-restoration.md says you need Turbo Assembler 3.1 for compiling. I can't seem to find it anywhere. Anyone know where I should look?

 

Also, where could I get my hands on the DMX sound library? Is there even a way to get a license for it anymore?

TASM is part of Borland C.

 

DMX code was leaked some time ago. Original link gone shortly after it became known. This post has mirror of dmx.zip.
https://www.doomworld.com/forum/post/1521395

[OpenRift]

2 minutes ago, nukeykt said:

TASM is part of Borland C.

  

DMX code was leaked some time ago. Original link gone shortly after it became known. This post has mirror of dmx.zip.
https://www.doomworld.com/forum/post/1521395

Thanks, though I just figured those parts out not long after lol. I updated my post with a different question.

[nukeykt]

did you put files in dmx37 subfolder? so lib file path will be ..\dmx\dmx37\lib\dmx_r.lib

[OpenRift]

Just now, nukeykt said:

did you put files in dmx37 subfolder? so lib file path will be ..\dmx\dmx37\lib\dmx_r.lib

Yep, I did.

I should ask though, is this relative path in relation to DOBUILD.BAT, Watcom or TASM?

[nukeykt]

relative to DOBUILD.BAT. In my setup I have 2 folders: one for watcom and one for doom.

In watcom folder I have 9.5b + TASM.EXE in BINW folder. In doom folder I have 2 folders: doom tree and dmx.

Watcom is mounted on C drive and Doom on D drive.

Thus DOBUILD.BAT is located at D:\DOOM\DOBUILD.BAT, dmx_r.lib is at D:\DMX\DMX37\LIB\DMX_R.LIB