Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
leileilol

Is it possible to... (Heretic source)

Recommended Posts

...recreate Doom v1.2's source with Heretic's old changes against a (Linux)Doom 1.9?

Granted no DMX, but heh v1.2 demos playing back and official random pitch shifts. Maybe using Chocolate Doom or even the Heretic DOS source for it.

Share this post


Link to post

1.2 compatibility would be helped by looking at the Heretic source, but as Graf said, it wouldn't be a total solution.

The most important thing you COULD get from Heretic however is the old line-of-sight checking algorithm which uses a tracer-like approach instead of the BSP tree. It's the one that has the bug that causes monsters to see you through walls a lot. You would definitely need that for 1.2 demo compatibility.

Pitched sounds are a no-go however, because that function was implemented inside DMX. DOOM just tells the library what pitch at which to play the sound. Paul Radek broke this functionality somehow while upgrading the library to a higher sample rate sometime between 1.2 and 1.666. (Probably at least part of what prompted Romero to go on his famous "sound dork" rant on Usenet).

It would probably require reverse engineering to look for other possible changes. Of course after working on Strife, I know that's a task quite within possibility. I've even considered looking into some of the old DOOM exe's myself, but I'm too busy for it at present.

I do intend to reverse engineer Heretic 1.0 at some point though, to get the precise original behavior of the Mace spots that was changed in later versions.

Share this post


Link to post
Quasar said:

1.2 compatibility would be helped by looking at the Heretic source, but as Graf said, it wouldn't be a total solution.

The most important thing you COULD get from Heretic however is the old line-of-sight checking algorithm which uses a tracer-like approach instead of the BSP tree. It's the one that has the bug that causes monsters to see you through walls a lot. You would definitely need that for 1.2 demo compatibility.


I still find it puzzling that they rewrote the entire sight checking code instead of fixing an easy to reproduce and analyze bug. It took me less than half an hour to see what went wrong there...

Share this post


Link to post

Quasar said:
(Probably at least part of what prompted Romero to go on his famous "sound dork" rant on Usenet).

Whuzzat?

Share this post


Link to post

He's referring to a letter by John Romero which was posted in alt.games.doom by a guy who was forwarded the letter by somebody else. In the letter, Romero reprimands people for pirating Doom II, and then repeatedly insults Paul Radek ("sound code dork" / "sound dork", "a real shithead", "he's demonstrated [...] that he's incompetent") while describing GUS-related bugs in the sound code at the time.

Share this post


Link to post
Graf Zahl said:

I still find it puzzling that they rewrote the entire sight checking code instead of fixing an easy to reproduce and analyze bug. It took me less than half an hour to see what went wrong there...

Was there anything superior about the original sight checking code, or does it surprise you that they did a rewrite for something that was easy to fix?

Edit: Actually, it's probably pretty obvious, but I'm curious about the original sight checking code since you mentioned it.

Share this post


Link to post

The Green Herring said:
He's referring to a letter by John Romero which was posted in alt.games.doom by a guy who was forwarded the letter by somebody else.

Heh, thanks, TGH!

As for the sound pitch shifts, if he broke it, I commend his incompetence because it wasn't really a good feature :p

RTC_Marine said:
But.. meh

Especially considering we can run v1.2 on modern systems using DOSBox. Had there been no way...

Share this post


Link to post
Snarboo said:

Was there anything superior about the original sight checking code, or does it surprise you that they did a rewrite for something that was easy to fix?

Edit: Actually, it's probably pretty obvious, but I'm curious about the original sight checking code since you mentioned it.


The blockmap based code is significantly faster. Traversing the BSP for a sight check is not an efficient method - in particular on large maps.

That's the main reason why REJECT has far less effect in ZDoom than in many other ports.

Here's some 8-year old info from ZDoom's changelog:

- Tried putting back in the BSP-based sight checking code that was in the Linux Doom 1.10 source, and the result was quite surprising. Using the BSP to check sight was actually slower than using the blockmap, sometimes significantly so--Vrack 2 spent between 4 and 6 times as much time checking sight using the BSP as it did without. In the best case, the BSP routines were about as fast as the blockmap ones, so I took the BSP routines back out, because they offer no benefit over the Hexen code I had been using for some time now.



For anyone knowing how these algorithms work the results should not come as a surprise.


The bug in the blockmap code was that it missed a case. The blockmap is made out of squares. Now the code uses a trace from the looking actor to the one it checks against. When this trace crosses the edge of the square it continues in the next block. But they simply forgot the case when the trace crosses a corner into a diagonally adjacent block. When this happened the trace got 'lost', so to speak, and the sight check returned 'success'. There's one very obvious occurence of this bug in Doom's E1M3 which I used to debug the problem a few years back. The same bug is also present in the generic P_PathTraverse so it can also cause a hitscan to get 'lost'.

Share this post


Link to post

It also seems to happen very often on Heretic E2M8. It isn't unusual at all for one or more of the Maulotaurs in the central area to awaken "unprovoked" while you are running about in the outside ring.

I have also seen it happen with the Heresiarch on the Gibbet in Hexen.

The fact this bug is typically noticed with boss creatures who roar at full-volume lead me to call it the "Anywhere Moo" bug (since both Cyberdemons and Maulotaurs make sounds that are similar to a moo).

Just out of curiosity, what does the fix to it entail? I've looked at the ZDoom source in the past but I didn't grasp exactly what changed to fix it. Your description makes sense, but what does it look like?

Share this post


Link to post

Here's the relevant code from ZDoom's P_PathTraverse. It has changed a bit from Doom's original after the fix though:

	for (count = 0 ; count < 100 ; count++)
	{
		if (flags & PT_ADDLINES)
		{
			AddLineIntercepts(mapx, mapy);
		}
		
		if (flags & PT_ADDTHINGS)
		{
			AddThingIntercepts(mapx, mapy, btit);
		}
				
		if (mapx == xt2 && mapy == yt2)
		{
			break;
		}

		// [RH] Handle corner cases properly instead of pretending they don't exist.
		switch ((((yintercept >> FRACBITS) == mapy) << 1) | ((xintercept >> FRACBITS) == mapx))
		{
		case 0:		// neither xintercept nor yintercept match!
			count = 100;	// Stop traversing, because somebody screwed up.
			break;

		case 1:		// xintercept matches
			xintercept += xstep;
			mapy += mapystep;
			break;

		case 2:		// yintercept matches
			yintercept += ystep;
			mapx += mapxstep;
			break;

		case 3:		// xintercept and yintercept both match
			// The trace is exiting a block through its corner. Not only does the block
			// being entered need to be checked (which will happen when this loop
			// continues), but the other two blocks adjacent to the corner also need to
			// be checked.
			if (flags & PT_ADDLINES)
			{
				AddLineIntercepts(mapx + mapxstep, mapy);
				AddLineIntercepts(mapx, mapy + mapystep);
			}
			
			if (flags & PT_ADDTHINGS)
			{
				AddThingIntercepts(mapx + mapxstep, mapy, btit);
				AddThingIntercepts(mapx, mapy + mapystep, btit);
			}
			xintercept += xstep;
			yintercept += ystep;
			mapx += mapxstep;
			mapy += mapystep;
			break;
		}
	}
The 'case 3' is the missing stuff. Case 1 and 2 are handled in the original through 'if's. When case 3 is not there the trace will get lost with no chance of ever getting back on track which would cause an endless loop. That's where the 'for' loop came in. Apparently id had problems with the code hanging but never found the real cause so they just put a safety net around their broken algorithm so that it can terminate.

Share this post


Link to post
The Green Herring said:

He's referring to a letter by John Romero which was posted in alt.games.doom by a guy who was forwarded the letter by somebody else. In the letter, Romero reprimands people for pirating Doom II, and then repeatedly insults Paul Radek ("sound code dork" / "sound dork", "a real shithead", "he's demonstrated [...] that he's incompetent") while describing GUS-related bugs in the sound code at the time.


I remember when I discovered that post. I raged. id knew that DMX was shit, so I wonder why they decided to keep using it? Paul Radek made excuse after excuse for the reasons GUS kept messing up, to at one point saying to use GUS for music and Sound Blaster for Sound FX. At the same time.

A real shithead!

I've been looking for Paul Radek since Sept. 2008. I still can't find any trace of him other than those usenet posts and a few videogame-related material where DMX was used. It's as if he never was on the internet.

Share this post


Link to post
Csonicgo said:

id knew that DMX was shit, so I wonder why they decided to keep using it?

Probably the same reason that alot of invested commercial money is continued to be invested in lesser solutions - it's cheaper and quicker to continue with the current flawed solution than to start implementing another one from scratch.

I have often wished I could go back in time and hand Carmack the Boom source with the hashtable fix.

Share this post


Link to post
Csonicgo said:

I've been looking for Paul Radek since Sept. 2008. I still can't find any trace of him other than those usenet posts and a few videogame-related material where DMX was used. It's as if he never was on the internet.

Coincidentally, I did some searches a few weeks ago in the hope of finding Paul and asking him to GPL the DMX code. I found the name on a patent made by a company called "WMS Gaming Inc". It seems rather coincidental that his name (and it's a rather distinctive surname) appears on a MIDI-related patent filed by a gaming company, don't you think?

I found accounts for people named Paul Radek on LinkedIn and Facebook. The former is definitely the same Paul who works at WMS Gaming. The latter appears to be the same person; his location is listed as Chicago, which is where WMS is based.

I sent a message to the Facebook account asking if he was the same Paul Radek who wrote the Doom sound code, but never got any response. Unfortunately, LinkedIn doesn't allow you to send messages unless you upgrade your account to a paid account, so I can't try that.

I'm not going to link to the accounts I mention, though they can be found through a Google search. I'm going to assume that if he hasn't responded to my message, it either isn't him or he wants to be left alone.

Share this post


Link to post

In '94 Jim Dose made a decent DMX clone called ASS (Apogee Sound System), which had more of the same features DMX had and was released under the GPL also (with ROTT and Duke3D sources). It's too bad id never went under the Apogee belt for Doom to use that one heheh ;)

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
Sign in to follow this  
×