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

[viti95]

*Lump already discovered in Doom 0.4*

*Delete please*

 

[viti95]

On 9/19/2023 at 2:17 PM, viti95 said:

OUTOFMEM.DOG

 

 

After some investigation, this looks like an early version of DOOMERR found in Doom 0.4 (April 2, 1993)

 

[nivere5302]

3 hours ago, Roebloz said:

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.

 

Nintendo has taken down multiple copies of that data from archive.org. If there's any still up there then their legal team just aren't aware of it.

[esselfortium]

Last night I backported Killough's hashtable implementation for W_CheckNumForName (minus the namespacing) into Mac Doom II 1.0.2 and got a nice little bump in performance on my 68040 Mac II. (Still much room for improvement, but The Living End is noticeably less choppy compared to retail 1.0.3!) I don't think many other people on Doomworld have old 68040 Macs to try this on, but I've attached an archive containing the application and the modified w_wad.c file in any case. 

 

It looks like the 68k asm routines might have potential for optimization as well, though that one's a bit out of my depth. The 68k asm routines for column and span drawing were seemingly used as-is from a Carmack email in which he mentions that he didn't spend much time on them, that he doesn't consider himself a 68k expert, and that they "could certainly be improved". For anyone feeling particularly adventurous, that might be an interesting direction to dig deeper into.

DoomHashtablePatch.sit.hqx.zip

[Frenkel]

8 hours ago, viti95 said:

 

After some investigation, this looks like an early version of DOOMERR found in Doom 0.4 (April 2, 1993)

 

Commander Keen 4

[Individualised]

edit: post is redundant

Edited September 27, 2023 by Individualised

[viti95]

8 hours ago, Frenkel said:

Commander Keen 4

 

So ID Software reused the Commander Keen 4 error page, and modified it a bit replacing "Commander Keen" for "DOOM, bonepie". That's why it's talking about EMS, when DOOM doesn't use EMS memory at all.

[SaladBadger]

What I find weird is that I remember Wolfenstein had a screen that looked like the DOOMERR screen in Alpha 0.4/5. So they must have had a few different iterations of it.

 

no idea why they even bothered updating the screen when every extant version of Doom used protected mode where most of this doesn't matter, but they did.

[viti95]

20 minutes ago, SaladBadger said:

What I find weird is that I remember Wolfenstein had a screen that looked like the DOOMERR screen in Alpha 0.4/5. So they must have had a few different iterations of it.

 

no idea why they even bothered updating the screen when every extant version of Doom used protected mode where most of this doesn't matter, but they did.

 

True, it's very weird they were modifying/using an older version of this screen in Doom development. Wolf3D memory error screen is really similar to Doom 0.4:

 

[Frenkel]

2 hours ago, SaladBadger said:

no idea why they even bothered updating the screen when every extant version of Doom used protected mode where most of this doesn't matter, but they did.

 

The Doom Wiki suggests Doom started as a real mode DOS program.

[SaladBadger]

Honestly I wonder if there's any evidence of that. The particular message didn't exist in any of the alphas except for the press release beta, I think, and every alpha was running in protected mode. It is still a really weird thing to have an error message for, though, and I can potentially understand thinking it would be to ensure any texture can fit in a EMS page.

[zokum]

That Doomwiki entry could just be an idea by whoever added it. There is no source, nor is it discussed on the discussion page. The Doomwiki is great, but it does contain some obvious errors and other problems. This sounds like one of those additions. Doom has plenty of limits, often without any reason given. the 65.5k limit is most likely one of those static limits they added, which they thought was more than enough. I don't think people has claimed the same for the way the blockmap is addressed. The idea is most likely that if a texture is that big (64kib+), something has gone wrong. Getting errors fixed can be a bit of a chore since it often involves removing 'information' from the wiki.

[Professor Hastig]

Maybe they just used their screen buffer as temporary store in the beginning.

Drawing the conclusion that the limit comes from previous 16 bit development is a bit far fetched.

 

[zokum]

I think it's more likely that someone quickly cooked up that error screen under the assumption it would be needed. I can't quite see Carmack getting so far into the engine production that he wanted nice error screens made, but still used a 16bit memory model. When they looked at the specs they would target Doom at, they must have chosen 4 megabyte pretty early. I'm no DOS programmer, but 4 meg of ram and EMS sounds like a horrible idea. Carmack was fairly forward looking when it came to tech and used Nexts to develop on. Choosing 32bit and protected mode seems the logical choice. Maybe early in the dev. someone tried to anticipate what they would need, and made that screen instead of just twiddling their thumbs. Who knows, it's all guess work from my side.

[Quasar]

16 hours ago, zokum said:

That Doomwiki entry could just be an idea by whoever added it. There is no source, nor is it discussed on the discussion page. The Doomwiki is great, but it does contain some obvious errors and other problems. This sounds like one of those additions. Doom has plenty of limits, often without any reason given. the 65.5k limit is most likely one of those static limits they added, which they thought was more than enough. I don't think people has claimed the same for the way the blockmap is addressed. The idea is most likely that if a texture is that big (64kib+), something has gone wrong. Getting errors fixed can be a bit of a chore since it often involves removing 'information' from the wiki.

That line is from me, and there is not any actual limit there. It would allocate more than 64 KB if it didn't literally check, "is this going to be 64K?" and error out if it would be. Nothing about the code wouldn't work otherwise. I don't know that Doom itself was ever fully compiled as real mode and that probably deserves clarification, but it's quite likely this code was imported from somewhere (Shadowcaster/Raven Engine???) that was.

[Gez]

Looking at the code to try to figure out exactly what's happening, so please tell me if I'm getting something wrong here:

//
// R_GenerateLookup
//
void R_GenerateLookup (int texnum)
{
    texture_t*		texture;
    byte*		patchcount;	// patchcount[texture->width]
    texpatch_t*		patch;	
    patch_t*		realpatch;
    int			x;
    int			x1;
    int			x2;
    int			i;
    short*		collump;
    unsigned short*	colofs;
	
    texture = textures[texnum];

    // Composited texture not created yet.
    texturecomposite[texnum] = 0;
    
    texturecompositesize[texnum] = 0;
    collump = texturecolumnlump[texnum];
    colofs = texturecolumnofs[texnum];
    
    // Now count the number of columns
    //  that are covered by more than one patch.
    // Fill in the lump / offset, so columns
    //  with only a single patch are all done.
    patchcount = (byte *)alloca (texture->width);
    memset (patchcount, 0, texture->width);
    patch = texture->patches;
		
    for (i=0 , patch = texture->patches;
	 i<texture->patchcount;
	 i++, patch++)
    {
	realpatch = W_CacheLumpNum (patch->patch, PU_CACHE);
	x1 = patch->originx;
	x2 = x1 + SHORT(realpatch->width);
	
	if (x1 < 0)
	    x = 0;
	else
	    x = x1;

	if (x2 > texture->width)
	    x2 = texture->width;
	for ( ; x<x2 ; x++)
	{
	    patchcount[x]++;
	    collump[x] = patch->patch;
	    colofs[x] = LONG(realpatch->columnofs[x-x1])+3;
	}
    }
	
    for (x=0 ; x<texture->width ; x++)
    {
	if (!patchcount[x])
	{
	    printf ("R_GenerateLookup: column without a patch (%s)\n",
		    texture->name);
	    return;
	}
	// I_Error ("R_GenerateLookup: column without a patch");
	
	if (patchcount[x] > 1)
	{
	    // Use the cached block.
	    collump[x] = -1;	
	    colofs[x] = texturecompositesize[texnum];
	    
	    if (texturecompositesize[texnum] > 0x10000-texture->height)
	    {
		I_Error ("R_GenerateLookup: texture %i is >64k",
			 texnum);
	    }
	    
	    texturecompositesize[texnum] += texture->height;
	}
    }	
}

From my understanding, it goes through each column of the texture, and if there's at least one patch for this column, it adds the texture's height to the total size. When that rolling counter would exceed 65536, the error message triggers.

 

Now the problem is that we know there are some 1024x128 sky textures, e.g. in Final Doom, and they work, and 1024 × 128 is 131072, i.e. twice the 65536 limit. But they work just fine.

[Professor Hastig]

Look closer, it only checks columns with more than one patch. Skies never do that, they merely put 4 images next to each other.

 

[Light37]

Now that multiple people have been able to dig through the hundreds of files on that CD, is what's been posted in this thread the only unique material found that wasn't available before, or are there a lot more undocumented things that just haven't been reported here yet or someone taken the time to peruse? Thanks.

[OpenRift]

Jesus Christ how the hell did I MISS THIS???? This is some BIG news, I never thought we'd see an actual leak of the actual DOS source code.

 

 

...Oh, and the Mac source is nice too, I guess.

 

Mac Doom is fucking weird lmao

[MODSKILLTHISACCOUNTNOW]

I uploaded the file in archive.org a couple of months ago

[MODSKILLTHISACCOUNTNOW]

On 9/12/2023 at 10:42 PM, Ludi said:

Let's hope that legit or not, this is uploaded to the relevant archives.

https://archive.org/details/doom-source-mac

[MODSKILLTHISACCOUNTNOW]

I also uploaded the source codes in my Github:

https://github.com/fluddsskark/DOOM-Mac-src

https://github.com/fluddsskark/DOOM-DOS-src

[zokum]

I've forked it off to my own 1.7 branch. Ans I plan to clean up a bit and possibly back port some 1.10 changes.

[uhbooh]

Wow! This is an incredible find, I thought the DOS source code was lost forever!

[Light37]

From the sold listings, it looks like that seller listed another DOOM source code disc but the auction ended without any bids. Similiar contents I think, but with some additional Hexen code? Is the Hexen code something that hasn't been released? Does anyone know enough if anything looks different or wasn't included in the previous disc that was listed for sale from this guy?

https://www.ebay.com/itm/204589321124

[ETTiNGRiNDER]

AFAIK Raven didn't "sanitize" the Heretic/Hexen code they released to the same degree that id did with the Doom code, so there's probably less likelihood of any lost code to the game itself, though I suppose there could be things like cut WAD content or auxiliary libraries (though I believe DMX has also been recovered as far as missing libraries goes.)  Maybe Mac code since I don't think we ever got any of that for any of the games.

[Doom64hunter]

57 minutes ago, ETTiNGRiNDER said:

AFAIK Raven didn't "sanitize" the Heretic/Hexen code they released to the same degree that id did with the Doom code, so there's probably less likelihood of any lost code to the game itself, though I suppose there could be things like cut WAD content or auxiliary libraries (though I believe DMX has also been recovered as far as missing libraries goes.)  Maybe Mac code since I don't think we ever got any of that for any of the games.

The file listing on the page only has C and header files of the game, no libraries or Hexen assets.

The rest appears to be mostly the same as the one that was put on archive.org, so probably didn't miss too much.

[NY00123]

Regarding the described Hexen source tree - thanks to @nukeykt for checking:

 

The timestamps show this revision was last edited on Oct 15 1995. This date is also in the timestamp of CD version 1.0's executable, currently identified as "1.0r2" here: https://doomwiki.org/w/index.php?title=HEXEN.EXE&section=2#Older_versions_2

 

A separate source reconstruction of this version should exist in gamesrc-ver-recreation as of now. The main technical advantage of having access to the original sources would probably be ensuring BSS variables got ordered exactly as in the original 1995 executable; Albeit, it's probably possible to do the same with the reconstructed sources by manipulating extern symbol definitions, if one knows how to. Other than that, it's mainly about knowing more of the original code, if in variable names or source code comments.

 

https://www.doomworld.com/forum/topic/114031-restoration-of-differing-doom-engine-exe-revisions-also-done-for-other-games/

 

 

[Wadmodder Shalton]

Now if only someone could try and remaster/remake/reimagine, the five extra WADs that came with the source code leak, these are ENTERPRZ.WAD, G50.WAD, NEW.WAD, OOPS.WAD and TMPLDOOM.WAD, which were user-created maps that were presumably downloaded for the purposes of testing out the -file parameter and probably perhaps used to test the performance and features of the Classic Mac OS version developed by Lion Entertainment. 

[Light37]

On 1/9/2024 at 3:31 PM, NY00123 said:

Regarding the described Hexen source tree - thanks to @nukeykt for checking:

 

The timestamps show this revision was last edited on Oct 15 1995. This date is also in the timestamp of CD version 1.0's executable, currently identified as "1.0r2" here: https://doomwiki.org/w/index.php?title=HEXEN.EXE&section=2#Older_versions_2

 

A separate source reconstruction of this version should exist in gamesrc-ver-recreation as of now. The main technical advantage of having access to the original sources would probably be ensuring BSS variables got ordered exactly as in the original 1995 executable; Albeit, it's probably possible to do the same with the reconstructed sources by manipulating extern symbol definitions, if one knows how to. Other than that, it's mainly about knowing more of the original code, if in variable names or source code comments.

 

https://www.doomworld.com/forum/topic/114031-restoration-of-differing-doom-engine-exe-revisions-also-done-for-other-games/

 

 

 

I noticed that Hexen/Doom CD-ROM is back up on Ebay again, a little cheaper this time. I'm guessing no one bought it or had any sort of deal behind the scenes. Are you sure there's nothing useful on it? Still too high price for me, especially if there's nothing useful.

https://www.ebay.com/itm/204674362048

Either way, I'm going to keep watching his items, because if he's had that previous Doom source code CD-ROM and this one, there's no guarentee that he might not have something else in the future... It's just annoying sifting through all the other appliances parts and stuff each week just to spot something like this.