Favorite Source Port? (Multiple Choice Poll)

http://www.doomworld.com/links/?category=4
Some are dead, but two of the biggies, Doom Underground and Sir Robin are still there. To stay a tiny bit on-topic, both those sites list the minimum port requirements (if any) for each wad.

http://www.doomworld.com/10years/bestwads/ is useful too.

This thread mentions most of the other major ones.

For some of the older sites, Internet Archive might help. For instance: old gginc.org reviews (some missing though).

<3

Judecca said:
ZDoom works. I think it's gonna be my vanilla-ish port of choice.

Quoted for amusement's sake :)

I recently read a statement somewhere that Legacy was the most vanilla-ish port. I found that even more amusing! ;)

Graf Zahl said:

I recently read a statement somewhere that Legacy was the most vanilla-ish port. I found that even more amusing! ;)

How can I grab the plasmagun on MAP01 in ZDoom?
How can I slide in right directions only in ZDoom?
Zdoom isn't vanilla-ish port. It is obvious.

He never said ZDooM was close to vanilla DooM, only that he was amused when he heard that Legacy DooM was apparantly the most vanilla doom port.

I use skulltag for anything an everything on topic.

entryway said:
How I can grab the plamagun on MAP01 in ZDoom?

By doing it the same way it was originally intended: You jump to it from the lift. ;)

How I can slide in right directions only in ZDoom?

What do you mean by 'right direction'. Sorry for asking but even when there were no source port I never really cared about speedrunning tricks.

Zdoom isn't vanilla-ish port. It is obvious. [/B]

I never said that ZDoom is vanilla-ish but IMO Legacy is even less because it has changed some things that shouldn't have been changed at all.

Graf Zahl said:

By doing it the same way it was originally intended: You jump to it from the lift. ;)

heh. It is very comfortable!

What do you mean by 'right direction'. Sorry for asking but even when there were no source port I never really cared about speedrunning tricks.

Only on the north in most cases.

I never said that ZDoom is vanilla-ish but IMO Legacy is even less because it has changed some things that shouldn't have been changed at all.

Last version of the Legacy reboots my computer always when I start it. It is very comfortable also.
And thanks for support of legacy maps in your own port. Some legacy maps are very fine.

The most Vanilla-ish port thats really, truly, useful in todays community is PrBoom(+). Choco Doom wins being vanilla but fails stuff like the fact it still has limits and it doesnt have any sort of Win32 or Linux setup program. ZDoom is just that, its ZDoom, Doom with enhancements and extras that come with the Z label.

BTW that 10 years of Doom is a great place to get wads from 1994-2003, but doesnt cover up to today. The 11th and 12th cacowards is pretty good to get wads made since then, though even through all those lists there are some real gems you can (and will) miss if you dont look around.

11th Cacowards: http://www.doomworld.com/11years/
12th Cacowards: http://www.doomworld.com/12years/

HobbsTiger1 said:

The most Vanilla-ish port thats really, truly, useful in todays community is PrBoom(+).

But only if you switch off all the MBF extensions. Some of them are even more intrusive than the stuff ZDoom is doing.

Graf Zahl said:

But only if you switch off all the MBF extensions. Some of them are even more intrusive than the stuff ZDoom is doing.

PRBoom config saiz:
# Misc settings
default_compatibility_level 1

I think that turns off any intrusive MBF features. The problem with ZDooms compat options is they arent complete, and some nice ones arent there.

Hobbs: note the new compat levels in the latest prb+ (2 for Doom2.exe, 3 for Ultimate Doom). And with the latest version, it actually has slightly better demo compatibility (see the changelog) with vanilla than Chocolate-Doom does (though I presume fraggle will add the relevant new code to chocdoom soon enough).

Graf: If you use the cfgs provided with prb+, then these have all the MBF stuff turned off, so the "straight out of the box" settings are quite vanilla-like (not full demo compat, but close enough for most purposes). I'd prefer it if the engine defaults (i.e. what it chooses if it finds no cfg) were also the non-MBF options, but at least now unsuspecting users who just extract all the stuff from the zip and don't adjust the settings won't have the modified monster behaviour.

BTW, talking of compat options, the lost soul limit seems to be gone in recent (G)Zdooms. (Doom2 map09 is the easiest place to test the behaviour: with the limit, on HMP they should be able to produce 3 lost souls before hitting the limit, and on UV they shouldn't be able to produce any until 13 lost souls have been killed.)

Grazza said:

BTW, talking of compat options, the lost soul limit seems to be gone in recent (G)Zdooms. (Doom2 map09 is the easiest place to test the behaviour: with the limit, on HMP they should be able to produce 3 lost souls before hitting the limit, and on UV they shouldn't be able to produce any until 13 lost souls have been killed.)

Indeed. MAP09 is practically the only map where it matters and I haven't played that for a long time. I wonder how this happened. Now I have to track down the code change that made this option inoperable.

If it helps you track it down, Zdoom 2.0.96x is the same as GZdoom 0.9.22 in this respect. I recall the limit used to work in earlier Zdoom versions, but don't know exactly where it changed. However, it was always out by one (and this is again the case in 2.0.98): i.e. PEs would not produce a lost soul if there were already 20 or more in the map. The original behaviour was that they would not produce a lost soul if there were already more than 20 in the map.

BTW, there are other maps where the limit is pretty important too. Some where it just gets silly if there is no limit, and, for instance, the start of HR map19 makes deliberate use of the limit for a little set piece.

I am disappointed that cph's bug list has died. It was the only resource for us other port programmers to pick up and share demo comp fixes easily. The only other option is to run diffs on the whole source code between versions and possibly end up missing critical stuff even then :/

Grazza said:

If it helps you track it down, Zdoom 2.0.96x is the same as GZdoom 0.9.22 in this respect.

I know. It was broken when the function was expanded to shoot other things than Lost Souls. The next release due tomorrow will fix it.

Quasar said:

I am disappointed that cph's bug list has died. It was the only resource for us other port programmers to pick up and share demo comp fixes easily. The only other option is to run diffs on the whole source code between versions and possibly end up missing critical stuff even then :/

The changes in prb+ relating to (or that have an impact on) demo compatibility are described reasonably clearly in the changelog (and the code is commented - check for "e6y"), which should make them easier to track down. Here are the ones I am aware of that Eternity doesn't have:

• Emulation of Doom2.exe's behaviour if it is used to record on a map with Boom specials [2.2.6.22]
  
• Fix regarding MF_JUSTHIT behaviour (incompatibility introduced in MBF, and relevant to Hacx, where some demos desync without this fix - reasons not entirely clear, but presumably related to the dehacked patch) [2.2.6.22]
  
• Added dehacked support for Monsters infight (Monsters Infight = 221 means that monsters of the same type will infight whenever provoked) [2.2.6.23]
  
• spechits overflow detection and attemped emulation [2.2.6.22/24]
  
• REJECT overflow detection and emulation when possible [2.2.6.25]
  
• Complevels added for Dosdoom and Tasdoom (including code to unscramble the tasdoom demo format) [2.2.6.25]
  
• The ability to force a particular one of the vanilla complevels (Doom2, Ultimate Doom or Final Doom), rather than the engine choosing one based on the iwad in use [2.2.6.25]
  
• Compatibility option added to fix a bug in Boom's dehacked support in the processing of Max Health, so that it applies only to health potions [2.2.6.25]

I'm pretty familiar with the demos for which these are relevant, so if you'd like some testing done if you apply any or all of these, just ask. The source code for all the relevant versions is available at sourceforge.

Edit: Might as well list the stuff that addresses Prboom-specific issues too (just quoting from the changelog verbatim):

• [-] PRBoom issues: prboom uses monster_avoid_hazards setting from the cfg file when you are using -complevel 0 or -complevel 1. If you have this option set to 1 in your cfg, then you are at risk of getting desyncs in demos that feature crushers. (Dashiva) [2.2.6.11]
  
• [+] Added switch to force monster_avoid_hazards: -force_monster_avoid_hazards. It is meaningful for viewing doom-compatible demos recorded with "monster_avoid_hazards 1" in config (in cases of desyncs). [2.2.6.21]
  
• [-] PrBoom dehacked support: wrong processing of Bits parameter if its value is equal to zero. No more desync on HACX demos. [2.2.6.21]

Eternity doesn't have any mechanism similar to prboom's complevels so a few of those aren't applicable, but thanks for the list. It gives me some stuff to work on.

Question, though. How does the spechits overflow emulation function? If it's too complicated to explain here, gimme a link to your code for it and I'll check it out ;)

Quasar said:

Question, though. How does the spechits overflow emulation function? If it's too complicated to explain here, gimme a link to your code for it and I'll check it out ;)

boolean PIT_CheckLine (line_t* ld)
{
  ...
  // if contacted a special line, add it to the list
  if (ld->special)
  {
    // fraggle: spechits overrun emulation code from prboom-plus
    if (numspechit >= MAXSPECIALCROSS_ORIGINAL)
    {
      SpechitOverrun(ld);
    }
    spechit[numspechit] = ld;
    numspechit++;
  }
  return true;
}

// Code to emulate the behavior of Vanilla Doom when encountering an overrun
// of the spechit array.  This is by Andrey Budko (e6y) and comes from his
// PrBoom plus port.  A big thanks to Andrey for this.

static void SpechitOverrun(line_t *ld)
{
  int addr = 0x01C09C98 + (ld - lines) * 0x3E;

  switch(numspechit)
  {
    case 9: 
    case 10:
    case 11:
    case 12:
      tmbbox[numspechit-9] = addr;
      break;
    case 13: 
      crushchange = addr; 
      break;
    case 14: 
      nofit = addr; 
      break;
    case 15: 
      bombsource = (mobj_t*)addr; 
      break;
    case 16: 
      bombdamage = addr; 
      break;
    case 17: 
      bombspot = (mobj_t*)addr; 
      break;
    case 18: 
      usething = (mobj_t*)addr; 
      break;
    case 19: 
      attackrange = addr; 
      break;
    case 20: 
      la_damage = addr; 
      break;
    default:
      fprintf(stderr, "SpechitOverrun: Warning: unable to emulate"
      "an overrun where numspechit=%i\n",numspechit);
      break;
  }
}

Doomsday, Zdoom and Skulltag. :]

GZDoom, Skulltag, though I have most of the rest installed just in case.

Oh. So the spechits emulation could conceivably cause a segmentation violation to occur. Seems a little bit too much on the dangerous side to me, so I'm not sure if I'll go for it. I tend to believe that crashing bugs are where the line for compatibility has to stop.

I've played back something like 1000 demos with spechits overflow emulation on, without any crashes. So the risk seems pretty low, unless you were to construct a map specifically to bring about such a situation.

Quasar said:

Oh. So the spechits emulation could conceivably cause a segmentation violation to occur.

??

My favorit is Eternity, but I use most ports (where they're needed). My least favorit is Doomsday though.

entryway said:

??

Writing an absolute address (even one in your own codespace) into an "mobj_t *" variable could conceivably cause the game to crash, or even cause corruption of either of the heaps used by DOOM (the C heap or the zone heap). Or, even trying to access the pointer may cause a "segmentation violation" error to occur, which means a program tried to access memory in a segment it has not been allocated (a process far too complicated to explain here ;)

However, it MAY be that those mobj_t * variables, despite being overwritten, are never used again after the point of the corruption without first being overwritten with new, proper values. If so, then it's crash-safe after all. I'll look into it, as it's worth supporting if it makes a difference in several demos.

I think it is safest to ignore these addresses and simply not write to them. They can't produce any meaningful results. If they get overwritten when in use it will crash. There is no way the engine can recover from this.

That, too, is an option, and a perfectly valid one from any point of view if the variables are indeed overwritten before being used again.

Quasar said:

Writing an absolute address (even one in your own codespace) into an "mobj_t *" variable could conceivably cause the game to crash, or even cause corruption of either of the heaps used by DOOM

Thanks for the tip.

static void SpechitOverrun(line_t *ld)
{
  int addr = 0x01C09C98 + (ld - lines) * 0x3E;

  switch(numspechit)
  {
    case 9: 
    case 10:
    case 11:
    case 12:
      tmbbox[numspechit-9] = addr;
      break;
    case 13: 
      crushchange = addr; 
      break;
    case 14: 
      nofit = addr; 
      break;
    default:
      fprintf(stderr, "SpechitOverrun: Warning: unable to emulate"
      "an overrun where numspechit=%i\n",numspechit);
      break;
  }
}

It should suffice for all known cases of overflow

Chocolate Doom, Eternity, and ZDoom. (occasionally Skulltag).