Current Doom source ports - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Current Doom source ports

Pages (2): « 1 [2]

Author

All times are GMT. The time now is 22:50.

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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.

01-12-06 09:34 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Grazza
Inventor of "Y Y" to quit

Posts: 11784
Registered: 07-02

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.

01-12-06 10:23 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5141
Registered: 08-00

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 :/

01-12-06 19:45 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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.

01-12-06 21:06 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Grazza
Inventor of "Y Y" to quit

Posts: 11784
Registered: 07-02

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]

01-13-06 00:29 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5141
Registered: 08-00

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 ;)

01-21-06 06:41 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

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 ;)

code: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;
  }
}

01-21-06 08:37 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Da Spadger
Member

Posts: 276
Registered: 01-06

Doomsday, Zdoom and Skulltag. :]

01-21-06 12:36 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

TheDarkArchon
Forum Staple

Posts: 2319
Registered: 08-04

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

__________________
* insert completely and utterly useless nonsense here that nobody will ever read ever *

01-21-06 14:56 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5141
Registered: 08-00

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.

01-22-06 22:41 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Grazza
Inventor of "Y Y" to quit

Posts: 11784
Registered: 07-02

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.

01-22-06 23:03 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

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

01-23-06 07:57 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

kristus
Megablast!

Posts: 10272
Registered: 07-00

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

01-23-06 11:50 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5141
Registered: 08-00

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.

01-23-06 18:46 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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.

01-23-06 18:57 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5141
Registered: 08-00

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.

01-23-06 19:27 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

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.

code: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

Last edited by entryway on 01-23-06 at 20:27

01-23-06 20:04 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote