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

Is this Mac/PC Doom source code on ebay legit?

Recommended Posts

9 hours ago, nukeykt said:

can confirm that DOS doom sources are legit. DMX (dmx37lib), makefile/newdoom.lnk, DEFS.INC are missing but can be grabbed from elsewhere, e.g. gamesrc-ver-recreation. Using watcom 9.5b and then removing debug data and appending dos4gw I got exes that are identical to original ones, byte-by-byte.

 

This archive is indeed far from the usual find for the average day; And, at least when it comes to DOS sources, it's great to see from Nuke.YKT that the files match the originals; A bit surprised to see that gaps between C string literals weren't the cause of differences in the output EXEs, but this might simply be a matter of luck (even with unmodified original sources that lack, e.g., changes to source comments or exact line numbers).

 

On the other hand, I won't speak for Nuke.YKT or others, but I'll probably still be quite careful with the contents; So far, my preference has been to refrain from directly having leaked sources within gamesrc-ver-recreation. The closest that I got to for Doom Engine games was making use of DMX; Even then, the DMX files are not in the public gamesrc-ver-recreation Bitbucket team page as of today.

Share this post


Link to post
27 minutes ago, Roebloz said:

(Also, I am 100% making a video on NEW.WAD, holy shit this is awesome)

It's already available on idgames, see above.

Share this post


Link to post
1 minute ago, Ludi said:

Looks like I'm gonna be eating my own foot for doubting.

 

Excellent news!

As you should. :) It's ok to be cynical but the problem is the attitude is less based in knowledge and more in good ol' common sense, which is.....reactive.

Share this post


Link to post
22 hours ago, Doom64hunter said:

There's something interesting to be gathered from the file listing of the midis:

 

 

Notice how the following filenames aren't actually present in Doom 2, according to the Doom Wiki: (https://doomwiki.org/wiki/Doom_II_music)

 

 

While at the same time, the following filenames are missing from the listing, which are present in Doom 2:

 

Hypothesis: MAP24 (THEDA3.MID), MAP26 (MESSG2.MID) and MAP27 (ROMER2.MID) had a music swap at the last second.

 

And as for MAP21 (COUNT2.MID), I'm guessing the music file was simply renamed from COUNTDN.MID to COUNT2.MID.

What's actually funny about this, is that these filenames were actually out in the open, and present in the released Macintosh port.

 

So uhhh, guess I'm 20 years late on this discovery.

Share this post


Link to post

@fabian Are you planning to look at the source code code and reference some of the sound functions to make Chocolate/Crispy Doom a bit more accurate, or would you rather stay away due to potential legal issues?

 

Or maybe the sound implementation is already as good as can be?

Share this post


Link to post
3 hours ago, Ludi said:

Looks like I'm gonna be eating my own foot for doubting.

 

Excellent news!

 

You shouldn't have pressed (X) to Doubt!

Edited by Midway64 : Replaced '.' with '!' to not sound angry.

Share this post


Link to post

image.png.76b8823ca15c68e296d2f98da5ed27cb.pngimage.png.80e5f964da71617a0324c8ad3ad112d5.png

 

Checked Doom II 1.7.sit archive, which appears to have v1.7 source code. And indeed after compiling it with right DMX version, I got exe that matches original v1.7 EXE byte-by-byte.
@NY00123 a while back figured out that v1.7 and v1.7a have only one difference: startup screen version number.
https://bitbucket.org/gamesrc-ver-recreation/doom/src/0e7f5b2cfa495f6675abdad7a3780107603f4fbc/d_main.c#lines-990
So I tried to correct header by appending "a" and recompile, and sure enough, I got exe that matches v1.7a byte-by-byte.

Share this post


Link to post
51 minutes ago, nukeykt said:

Checked Doom II 1.7.sit archive, which appears to have v1.7 source code. And indeed after compiling it with right DMX version, I got exe that matches original v1.7 EXE byte-by-byte.

@NY00123 a while back figured out that v1.7 and v1.7a have only one difference: startup screen version number.
https://bitbucket.org/gamesrc-ver-recreation/doom/src/0e7f5b2cfa495f6675abdad7a3780107603f4fbc/d_main.c#lines-990
So I tried to correct header by appending "a" and recompile, and sure enough, I got exe that matches v1.7a byte-by-byte.

 

I can mention now that I tried building the exes on my own. Instead of appending the matching dos4gw code, I rather compared to the original executables after stripping dos4gw. But otherwise, as in Nuke.YKT's case, the newly built exes were matching byte-by-byte, including also paddings between string literals.

 

The latter surprised me a bit as I mentioned earlier. I recall how even just the definition of one more environment variable could - albeit rarely - lead to Watcom C generating a function a bit differently, which was still enough in order to make it not match another exe. Regarding differences in string paddings, I suspect that it has more to do with the textual contents of the source code / compilation units, and not necessarily the comments.

 

To further add to what was explained by Nuke.YKT earlier:

- Watcom doesn't seem to accept sources using CR-formatted new lines. So, I converted these to LF.

- You might have to copy missing ASM files from a different directory that has them.

- For the 1.9 series, the DMX version is dmx37; Basically an older DMX version with the files from dmx37lib used with a higher priority IIRC. 1.7 and 1.7a use a modification of dmx34a.

- I actually didn't have to modify gamesrc-ver-recreation/doom/makefile or newdoom.lnk as currently present. I just had to create a directory matching the desired version (per the list in gamesrc-ver-recreation) and call wmake with appver_exedef being appropriately set, e.g., "wmake appver_exedef=DM19".

- I didn't even bother to rename the directories with the sources; They were simply present without a-prior renaming under (emulated) D: drives, while Watcom C 9.5b was at (emulated) location C:\CPP_95B in my case.

- For Doom 1.9 (not The Ultimate Doom tree which already covered these), the macro FRENCH had to be undefined in DOOMDEF.H, and a typo in HU_STUFF.C had to be fixed (comercial -> commercial).

- Two archives seem to match 1.7 (not 1.7a), even if the sole real difference is of one space character in R_DRAW.C. As mentioned by Nuke.YKT, changing 1.7 into 1.7a should be trivial.

Share this post


Link to post

The more people say that, the more likely it'll happen. Nobody be a NARC, please. Besides, it's a bit late now. It's out there, and people have downloaded it, it'll just resurface over and over.

Share this post


Link to post

So just to confirm I’ve understood: the included wads are not unreleased Doom maps or cut Master Levels, but likely PWADs grabbed for the internet to test the Mac port with?

Share this post


Link to post
10 minutes ago, Faceman2000 said:

So just to confirm I’ve understood: the included wads are not unreleased Doom maps or cut Master Levels, but likely PWADs grabbed for the internet to test the Mac port with?

Yes. Of the included WADs, NEW.WAD and G50.WAD were already available on idgames, and the other two were seemingly uploaded to another BBS but not to idgames itself. However, their text files are preserved, which indicate they are not cut levels.

Share this post


Link to post

According to one of the files in the email folder, it seems they had issues initially with allowing Mac and PC users to both run on the same multiplayer servers together. It seems the solution is both users have to have the same WAD file version. I was not aware there was any sort of cross-play between these versions. Can anyone confirm if this made it to the final release? 

Share this post


Link to post
17 minutes ago, Dynamo said:

Yes. Of the included WADs, NEW.WAD and G50.WAD were already available on idgames, and the other two were seemingly uploaded to another BBS but not to idgames itself. However, their text files are preserved, which indicate they are not cut levels.

I still find it likely that Deadlock is a cut Master Level, judging by the date on it compared to the idgames version and it being mentioned in this file Romero shared (it has no extension but you can still open it in a text editor).

Share this post


Link to post

Is there a way to mount the .ISO on Ubuntu without a Mac OS virtual machine?

Share this post


Link to post

Ehh no I don't think so.

You could try and extract the files inside the ISO then use one of those programs for those special formats the Mac uses.

Share this post


Link to post

I can't say too much about it but I can confirm that NEW.WAD's association with Doom's development resources predates the Mac version and has no relationship to it in particular. At least I know what it is now, that was driving me crazy previously.

Share this post


Link to post
5 hours ago, Individualised said:

Is there a way to mount the .ISO on Ubuntu without a Mac OS virtual machine?

 

Might this depend on the version of Ubuntu? With 20.04.6 LTS, I could right-click on the ISO and use the GNOME Disk Image Mounter. Alternatively, using the command "mount" with the switches "-o loop" also did the job, obviously with certain differences in behaviors (access permissions probably being the most obvious).

 

It's not impossible an additional package or more had to be installed for support of the filesystem, but I don't know the answer for this right now.

 

It still didn't seem to take care of file names using characters outside of ASCII. There are files using character 0xAA, and they couldn't be copied out of the mounted ISO in the usual manner. My guess being that the encoding in use was Mac OS Roman. But at least for the DOS sources I built exes from, this wasn't a problem for me.

 

btw, you can give unar (not unrar) a try in order to extract StuffIt (.sit) archives.

Share this post


Link to post
6 hours ago, Individualised said:

Is there a way to mount the .ISO on Ubuntu without a Mac OS virtual machine?

I think Ubuntu has native system drivers for it, But i am personally not gonna do anything cause this is a leak. I think it would be against ZeniMax and from what i hear ZeniMax isn't very friendly

Share this post


Link to post
5 minutes ago, Monocled said:

... and from what i hear ZeniMax isn't very friendly

 

Yeah, just ask Mick Gordon.

Share this post


Link to post
2 minutes ago, Zilch said:

 

Yeah, just ask Mick Gordon.

He's the composer for Doom 2019 and Doom: Eternals music right? What happened with him?

Share this post


Link to post

Honestly though, if you're scared of touching the leak, keep in mind the only ones that are at any risk (If any) are those hosting the files up for download. And if there's anything the Nintendo Gigaleak told us, is that even Nintendo (Who abuse their copyright whenever possible) haven't taken down the Gigaleak on archive.org.

 

So honestly I'd say to not worry too much.

Share this post


Link to post

I haven't had time to look at it, but comments and commented out code might have changed a bit compared to the 1.10 release. There seems to be some additional files. I am sure we'll see some quite thorough analyses. I would like to see more in detail what exact video modes and settings to set it up they used and if there are commented out earlier versions, since Doom and Heretic use different video modes. Carmack changed it to a mode x, but I think that was a problematic choice. Looking at Fast Doom and Heretic reviews, this mode was mostløy faster on fast computers, which were fast anyway. I think having a better fps on slower machine would benefit the game more than having 35fps instead of 30 on high-end machines. Hard to tell though, since I have no data on video card speeds back then, only some anecdotes.

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
×