doom2.exe v1.9...1?!

No, John Carmack didn't get bored and go back to fix bugs in doom2.exe, but instead some hardcore doom2.exe deathmatchers decided to. Apparently all this time there's been a problem in the demo recording code that caused mouse precision to be lower than normal, and some enterprising hackers decided to fix the problem, resulting in an unofficial doom2.exe v1.91. If you didn't even realize that demo recording in doom2.exe had mouse precision problems, then this probably isn't for you, and if you did, then you probably knew about this already, so I don't even know why I am writing this. Anyways cph has another writeup explaining this bug and its fix in detail. I love you cph! Call me!

Great. I never noticed any difference myself...

How about you guys do some hacking on GLboom now, and make it play more like Doom2.exe? :-)

Darn... Don't get my hopes up like that. I think it would be super-cool if Carmack decided to dust off the old Doom source code and fiddle with it. Oh wait, that's how we got Doom 3. Never mind.

I used to record demos in doom(2).exe v1.9 all the time(use glboom now) and I never noticed any problem with mouse prediction...

geekmarine said:

Darn... Don't get my hopes up like that. I think it would be super-cool if Carmack decided to dust off the old Doom source code and fiddle with it. Oh wait, that's how we got Doom 3. Never mind.

Not even close.

MasterOFDeath said:

I used to record demos in doom(2).exe v1.9 all the time(use glboom now) and I never noticed any problem with mouse prediction...

Precision, not prediction.

Let me rephrase that...

THE MOUSE NEVER GAVE ME ANY PROBLEMS WITH DEMOS. :P

I noticed it long ago.
When recording you cannot adjust your angle pixel by pixel, only a few pixel by a few pixel. Because slow/very light turn moves are not taken into account like they are w/o recording.

I made a Doom 1.9.1 patch once actually.

see?? http://oregonstate.edu/~lloydo/dm191p.zip

all it does is restores the E1M4 swatstika. which makes movies of E1 unwatchable and multiplayer play on that map impossible to anyone who hasn't done the same.

Now if only Carmack WOULD tinker with 1.9...

JC? You reading this?!

You doom2.exe purists are friggin insane. INSANE I TELL YOU.

Actually, mad props to you people. I can't imagine the kind of dedication and hard work something like this would have taken to do.

I'll never use this, but that is awsome. It's interesting to know some of you still prefer the old DOS original. I don't run into them often.
So ya, if your looking for a good time (about 5 seconds) give me a ring too!!! ;)

Wow. I HAVE noticed low mouse precision while recording Doom 2 demos for COMPET-N. But I just assumed that the precision was lower in order to save space.

AndrewB said:

Wow. I HAVE noticed low mouse precision while recording Doom 2 demos for COMPET-N. But I just assumed that the precision was lower in order to save space.

Uh that IS why it was lower...

Usually when something is less elaborate simply for performance reasons, it wouldn't be referred to as "bug" or "problem."

That's like saying that JDoom fixed a bug in Doom that caused monsters to be 2D sprites.

Doom limited the number of visplanes for "performance reasons" so is visplane overflow not a "bug" or a "problem"?

http://dictionary.reference.com/search?q=bug&r=67
#

1. A defect or difficulty, as in a system or design.
2. Computer Science. A defect in the code or routine of a program.

If it's intentional, I don't see how you can call it a "defect."

AndrewB said:

If it's intentional, I don't see how you can call it a "defect."

In 1.9, when we play without recording, we have a clean handling mouse. Turn on recording, and the low end of the mouse precision disappears. Regardless of why id software did it this way, it's still a degradation from the ideal performance in-game. Especially in 2004, there is no good reason for the mouse handling to be deliberately damaged simply because the players have elected to record; one could also argue that the disk space problem wasnt big enough back in 1994 either, people can delete the demos they don't want to keep, right?

FYI: This problem with recording in 1.9 is the one reason that you do not see any Dominus demos from my August 2003 LANparty. Hopefully Dominus gets to a LAN one of these days and records some good games with 1.91 so we get some demos of his real game out there :>

--BahdKo

Fucking awesome!

The v1.91 article says:
Version 1.91 recordings are not being accepted for Compet-N at the time of this writing.

That would be an interesting addition, although I believe they'd have to be exclusive of 1.9 submissions, as playing without the limitation is easier and different. That is, v1.91 submissions would naturally be treated as a separate set of records.

Linguica said:
Doom limited the number of visplanes for "performance reasons" so is visplane overflow not a "bug" or a "problem"?

It's the result of a bug in a map if you're attempting to make a Doom map, or a problem if you're trying to make a map that exceeds Doom's limits.

Word usage is generally a question of bias; instead of arguing about the supposed validity of a term's proper usage we can often simply observe that we disagree in outlook.

BahdKo said:
Especially in 2004, there is no good reason for the mouse handling to be deliberately damaged simply because the players have elected to record; one could also argue that the disk space problem wasnt big enough back in 1994 either, people can delete the demos they don't want to keep, right?

Perhaps, although there's always historical considerations to take into account; the huge mass of demos in existence were created with the limitation, and to compare new demos to them properly or compete with them we need to use the limitation. That does not exclude the possibility of adding v1.91 demos for competition purposes, and that some people will be attracted only to these; but I don't think the efforts made by people using the original format should be disregarded because of this.

Had some God created us readily supplied with digital cameras we probably would not have developed the graphic arts as much as we have from the beginning of time in the way we have; hardly anyone would be a painter or sketch artist.

I'd rather select the format to use depending on the particular aim of the recording; if I'm genuinely trying to beat record set by someone that used v1.9, I'll use that too, while if I need to record a totally clean demo of a game, I'll use 1.91. It seems to me that v1.91 will be most beneficial for DeathMatch, whereas v1.9 will still be pretty relevant in regard to Single Player... although all this depends on what players choose to record.

myk said:

Perhaps, although there's always historical considerations to take into account <snip> I'd rather select the format to use depending on the particular aim of the recording <snip> It seems to me that v1.91 will be most beneficial for DeathMatch

Yeah, I agree with the points you made. Also, I expect Compet-N is not likely to adopt 1.91 into its main demo base because it would represent an advantage to the modern players that the past historical years of Compet-N have not had. I don't think you can realistically compare high-skill SP demos done with 1.91 with 1.9, the difference in performance is too significant. Seperate thing MAYBE, like you suggested in the other post, but not WITH the 1.9 demos. 1.91 was mainly done for us DMers. We did put right on the website for people to keep 1.9 around for historical reasons and Compet-N.

--BahdKo

Linguica said:

Doom limited the number of visplanes for "performance reasons" so is visplane overflow not a "bug" or a "problem"?

I wouldn't call it a bug or even really a problem, it's just an engine limitation. Just like I wouldn't call the refresh rate of 35fps, the limitation in the size of maps, or the lack of support for ROR bugs. You could argue they're limitations better off lifted, but bug to me corresponds to an unintentional error or oversight on the programmer's part.

Woot, this is great news, even though I don't really use doom2.exe much anymore.

It'd be neat if Indigo lag in LAN games were fixed, I'm not sure if that's doable through hex editing.

I don't think anyone has figured out the technical details of the lag, urhash. Got to do some research on that before someone can start working on a fix.

Waldon said:

I don't think anyone has figured out the technical details of the lag, urhash. Got to do some research on that before someone can start working on a fix.

Sounds like a job for..... CPH!!!!

Yeah... we definitely would have to understand WHY the lag happens. There would be a chance, maybe, of fixing it then. But it does sound like a hard thing to do in a hex edit, unless it's something small and silly.

--BahdKo

Wait, is the network code in Doom itself or in IPXSetup?

myk said:

Wait, is the network code in Doom itself or in IPXSetup?

It's all in Doom itself. IPXSetup just sets up the networking, and then doom just rolls with it.

mmph.

--BahdKo

The network code is split between ipxsetup and doom2. ipxsetup figures out the other nodes in the game and the player numbers, and it provides the low-level IPX code (which sits like a TSR program which doom2 calls). doom2 provides all the logic of the networking, like flow control, sequencing, retransmission.

I have a few ideas about the lag difference between nodes, and when I have enough dos/win computers around I will investigate a bit more.

So, in other words, ipxsetup.exe contains the IPX and doom2.exe contains the SPX.

It's a shame that the prboom team doesn't accept Paypal monies...