Differences between DOOM2.exe, TNT.exe, and Plutonia.exe

Been awhile since I've loged on. Anyway, does anyone know if there are any changes between the DOOM2.exe engine and those used for the final DOOM series (Evilution and Plutonia experiment)? The reason I ask is because I've noticed on plutonia that the scrolling walls move so much faster than in DOOM 2.

There are a number of differences between Doom2's Doom2.exe and the one for Final Doom.

The Final Doom exe was based on Ultimate Doom. So if you use it with Ultimate Doom, it supports episode 4, and has the altered tag 666 behaviour, and support for the specials on e4m6 and e4m8.

It also has Ultimate Doom's altered lost soul behaviour.

The Final Doom exe also introduced a teleporter bug that causes the player sometimes to teleport into mid-air. Although not too harmful, it's pretty obvious when playing or watching demos, so it's odd that it wasn't spotted.

Those are the things that affect demo sync (roughly 30% of existing demos desync if played back with the wrong exe - more for longer demos, less for shorter ones).

Thanks. But howcome the texture scroll special in plutonia moves so much faster than in either ultimate DOOM, Evilution, and/or DOOM 2? Was the source code for that altered in any way?

Mechanos said:

Thanks. But howcome the texture scroll special in plutonia moves so much faster than in either ultimate DOOM, Evilution, and/or DOOM 2? Was the source code for that altered in any way?

That's a map trick, actually; it's one that most modern editing tools aren't capable of replicating.

There are multiple linedefs all given the Scroll Texture special, all of which are referencing the same sidedef. That is to say, not using a tag, but actually saying "sidedef 1 is the front side of linedefs 1, 2, 3, 4, and 5".

There's another neat map trick that shows up in a few older wads that works in pretty much the same way. If multiple linedefs reference the same sidedef, and one of those lines is a switch, pressing that switch will change the texture on every linedef with the same sidedef.

It is a shame that modern map editors don't give the user manual control over sidedef compression. Could that be done with a DB2 plugin?

Creaphis said:

There's another neat map trick that shows up in a few older wads that works in pretty much the same way. If multiple linedefs reference the same sidedef, and one of those lines is a switch, pressing that switch will change the texture on every linedef with the same sidedef.

It is a shame that modern map editors don't give the user manual control over sidedef compression. Could that be done with a DB2 plugin?

I think the Snap to Grid or the Merge Geometry are able to control to put 2 linedefs at the same spot. hawkwind did this while testing my map to fix a bug, I noticed that he made 2 lines with the same spot with different faces.

Hmm, DB does indeed not support such hacks - I'd never even thought of that to be honest! It's amazing what you can do with this engine.

@ C30N9:
That's not the same thing, though. This is several sidedefs all in different places, optionally even with different textures (I think), that are all referencing the same linedef number in the map data.

esselfortium said:

@ C30N9:
That's not the same thing, though. This is several sidedefs all in different places, optionally even with different textures (I think), that are all referencing the same linedef number in the map data.

WTF?? Linedefs reference sidedefs, not the other way round. And sidedefs specify textures, so if two lindefs share a sidedef, the they have the same texturess.

esselfortium said:

That's a map trick, actually; it's one that most modern editing tools aren't capable of replicating.

There are multiple linedefs all given the Scroll Texture special, all of which are referencing the same sidedef. That is to say, not using a tag, but actually saying "sidedef 1 is the front side of linedefs 1, 2, 3, 4, and 5".

Wow, I never knew about this.

The inventiveness of Doom mappers still surprises me after all these years. There's always another trick you can pull.

Differences between versions that I know about (from looking at the Chocolate Doom source):

• Ultimate/Final exes play DEMO4 in their demo loop, original 1.9 only plays up to DEMO3. This causes Final Doom to bomb out because tnt.wad/plutonia.wad don't have a DEMO4 lump. However, there is apparently a second Final Doom executable that fixes this.
  
  
• Ultimate Doom executable tries to show a lump named HELP1 for the help screen, Final Doom executable tries to show a lump named HELP, original 1.9 executable shows HELP for doom2.wad, HELP2 for doom.wad. Only the original 1.9 executable shows two help screens when "Read this!" is selected from the menu.
  
  
• Original 1.9 executable shows the blinking skull on the first help screen at 280, 185 for doom.wad, 330, 165 for doom2.wad. Ultimate and Final Doom executables always show the skull at 330, 175.
  
  
• In the original 1.9 executable, a cyberdemon/spider mastermind dying on level 8 of any episode can trigger the "boss end" special effect for that episode (lowering floor on episode 1, end of level for episode 2/3). In the Ultimate/Final Doom executables, it has to be a specific monster on a specific episode: Barons on episode 1, Cyberdemon on episode 2, Spider mastermind on episode 3 or 4. This is what caused UAC_DEAD.WAD to stop working in Ultimate Doom.
  
  
• Lost souls can "bounce" off the floor in Ultimate and Final Doom.
  
  
• In the Final Doom executable, when you teleport your Z position isn't set, so you can end up "dropping" in mid-air.
  

Heh these are quite breaking incompatibilities even within "vanilla" Doom. Makes it almost moot to refer to "vanilla" as one, solid, indivisible entity.

The linedef/sidedef trick sounds neat, I was aware that linedefs could index arbitrary sidedefs at load time by looking at the code, but I couldn't imagine a situation where there wasn't a 1:1 mapping (aside from a-posteriori sidedef compression).

I don't recall if editors such as e.g. DEU actually allowed you to set the two separately, or it's one of those tricks you can only do with direct hex editing or a deserialized version of the level, such as the classic DoomED.

You can accelerate the scrolling so much that it actually goes in reverse. (If instead of moving one unit per tic, it moves 63 units per tic, and the texture is 64-pixel wide, it'll look like it's moving -1 units per tic, or moving the other way around.) That effect was used in at least one wad.

Maes said:

I don't recall if editors such as e.g. DEU actually allowed you to set the two separately, or it's one of those tricks you can only do with direct hex editing or a deserialized version of the level, such as the classic DoomED.

DEU did let you fiddle with that sort of thing I think, because it was possible to create lines that referenced nothing by selecting two vertices and pressing INSERT. You'd have select the lines that make up a sector and press insert again to make the sector come into existance, and I'm pretty sure that was what handled the sidedefs too.

tempun said:

WTF?? Linedefs reference sidedefs, not the other way round. And sidedefs specify textures, so if two lindefs share a sidedef, the they have the same texturess.

Right.

Gez said:

You can accelerate the scrolling so much that it actually goes in reverse. (If instead of moving one unit per tic, it moves 63 units per tic, and the texture is 64-pixel wide, it'll look like it's moving -1 units per tic, or moving the other way around.) That effect was used in at least one wad.

Also right. I remember the demo wad you're talking about (though I don't remember its name). This effect has to be used sparingly, though, as it uses up 63 of the 64 available texture scroll lines.

You could manually specify sidedef and sector references in DEU, even after having created everything the normal way.

tempun said:

WTF?? Linedefs reference sidedefs, not the other way round. And sidedefs specify textures, so if two lindefs share a sidedef, the they have the same texturess.

Okay, I got it backwards.