PrBoom Updates

[myk]

cph said:
UAC_DEAD works in 2.4.0. The demo plays back fine with -complevel 0.

Apparently I marked the comp_666 fix for complevel 0 (doom 1.2 compat) only. So that's the one that works.

What other changes does that level make? I'm assuming level 0 doesn't really play almost any v1.2 demos, as I recall it had some odd quirks, like you were pushed to a side while recording, and the format was kind of different, and that not long after 1.2 the format stabilized and most changes of the "versions" refer to map design or fixes. DOOM v1.9 had to main differences with The Ultimate DOOM; the 666 tag and the behavior of Lost Souls when hitting floors and ceilings. So 0 is for v1.666 to v1.9, and perhaps ealier. While 1 is the same except it's missing something, and 3 is for fully updated stuff. Point is, though, it's better to use distinctions like PrBoom+ eventually used where you can mix the engine finctionality with the IWADs, since for the most part most all the v1.9 engines can run an assortment of IWADs. For example, demos can have "The Ultimate DOOM" functionality and be for DOOM II, or Final DOOM.

Quasar said:
Actually some of those among us -- myself included -- do value ports that can run more than 50% of the idgames archive dating from before 2000. I'm sure it has been tempting to all of us to just rip out the compatibility, but then we all might as well use zdoom right?

Lots of (ignorant) "port" users are indeed uploading wads that they persent as Boom or limit removing or even "vanilla" compatible that are in effect as buggy on the engines as the old wads were. There was crap then, we have it now, it's just a bit different.

[Grazza]

The "standard" uac_dead is here (works with Registered doom.exe 1.9 and is the one used for all demos that I'm aware of).

It seems there are two distinct tag 666 compat issues.

One is it being made monster-specific on the maps where it applies at all (e.g. only barons trigger it on E1M8). This change occurred for Ultimate Doom. Note that uac_dead.wad works fine (as does uac_dead.lmp) if you use Doom2.exe 1.9 instead of Ultimate Doom's Doom.exe. (Not surprising given that Doom2.exe 1.9 is identical to Doom.exe 1.9)

The other is the tag only working on specific maps, rather than earlier ones in E1. I wasn't aware of this one (i.e. that boss deaths could trigger it on other maps in early versions), or of any maps where it is relevant, and am not sure where it came in.

(As an aside, I presume the keen codepointer works on all Doom maps, at least in version 1.9 onwards. I haven't tested this, and don't know of any wads that use this - it would need to be implemented with dehacked.)

As myk indicates, in Prboom+, there are three separate "1.9" complevels: for Doom 1.9/Doom2 1.9, Ultimate Doom and Final Doom. This enables the user to override the autodetect if he so wishes, and seems the best solution. It would also reduce confusion if the complevels in the "official" and "plus" branches matched one another, at least in the 0-11 range. See this post for further info. In case it's not clear, the difference between 5 and 6 is that 6 uses descrambling code in order to play back unconverted Tasdoom demos.

cph said:

linedefs triggering actions on tag 0

Actually, I believe this is a lot more common in modern maps than in older ones - especially if people make their maps in Doombuilder and only test them in Zdoom. Indeed, this is the reason for one of the "compatibility with common mapping errors" options in Prboom+.

[Graf Zahl]

Grazza said:

(As an aside, I presume the keen codepointer works on all Doom maps, at least in version 1.9 onwards. I haven't tested this, and don't know of any wads that use this - it would need to be implemented with dehacked.)

Yes, the Keen code pointer does not depend on the map and neither on the type of the calling object. And yes, there are maps that use this:

Eternal Doom MAP07 uses a few hidden Keens to open some doors and Operation Arctic Wolf uses Dehacked to put it on one boss that causes a door to open when you kill him.

But since this code pointer is handled correctly in most source ports (Legacy being the exception) there are no problems to be expected.

[Grazza]

I was referring to Doom(1) maps, and wanted to mention this point just to make sure it didn't get overlooked (or clobbered) in whatever is done to support different tag 666 behaviour in support for earlier Doom(1) versions.

[myk]

Grazza said:
I was referring to Doom(1) maps, and wanted to mention this point just to make sure it didn't get overlooked (or clobbered) in whatever is done to support different tag 666 behaviour in support for earlier Doom(1) versions.

It's not restricted to DOOM II (I've tested it.)

[cph]

Quasar said:
...this BossDeath fix .... I was under the previous understanding that it was any monster could activate the effect on any ExM8 map, not any E1Mx map -- very big difference here. I have editing tutorials from AGES ago which clearly state that BossDeath (of course then known only as "magic codepointer #1") only worked on ExM8 maps. Were they wrong?

I was just guessing at the weekend, trying to get my copy of uac_dead working, which turned out not to be an original copy. I assume that your understanding is right, unless anyone says otherwise, and will return to any-boss at any-ExM8 for the next release.

Grazza said:
As myk indicates, in Prboom+, there are three separate "1.9" complevels: for Doom 1.9/Doom2 1.9, Ultimate Doom and Final Doom. This enables the user to override the autodetect if he so wishes,...It would also reduce confusion if the complevels in the "official" and "plus" branches matched one another...

Yes, I started doing per-engine levels for PrBoom 2.3.0, which is much cleaner than my original scheme in 2.2.x. Most of the work for 2.4.0 was moving this into the stable codebase. It appears than Prboom+ has used something like the 2.3.x scheme but has added more levels - the extra ones look sensible, so I will try to converge on the same numbers if possible.

myk said:
What other changes does [complevel 0] make?

2s middle textures don't animate (certain early pwads use this, e.g. dmspace). The only thing -complevel 0 changes that affects demos is the 666 tag - I'm not trying to support v1.2 demos, only v1.2 pwads. So -complevel 0 just happens to be useful for this uac_dead demo, because you'll have to wait for 2.4.1 so I can enable it for doom_19 compatibility.

[Quasar]

BTW, the original version of Aliens TC was also affected by this problem now that I think about it. The Queen Alien was made from the Baron of Hell. But using Ultimate DOOM v1.9, killing the Queen Alien on E2M8 would do nothing, and you never got to see the end sequence without cheating somehow.

IIRC, I had to fix this in my new version of Aliens TC fixed up for modern ports by turning the Cyberdemon into a Queen Alien as well, and then fixing E2M8 to use the Cyber instead of the Baron.

I had previously assumed that the BossDeath pointer had simply been misunderstood by early wad authors and they just assumed that any of the monsters that use it would work on any of those maps. Now that I reconsider it, it's silly to think they didn't test it, and that it really did work back then.

[Jon]

cph said:

Okay, and what PWAD are you using - my copy on UAC_DEAD isn't even on E1M8, so the demo doesn't touch it.

I've encountered copies of UAC_DEAD on E1M1, too, but I don't think any of them actually worked with the original DOOM.EXEs. I may crack open DOSbox to confirm this.

cph said:

Hmm, so the opinion is that the 666 linedef change occured at between doom/doom2 1.9 and ultdoom 1.9? I had assumed (not having done any research) it was after 1.666.

Yes. I've confirmed this by experiment with the original EXEs, but I may need to repeat the experiment, as I don't know where I put the results :) It's my belief that the function was untouched until they extended it to add E4 support.

Edit: the original patch I submitted to you (against 2.2) used 1.666 compatibility level because there wasn't one for 1.9 vs. UD1.9 -- the 2.3 patch in sf.net's tracker attempts to add this comp level but doesn't do all the required changes.

[Jon]

Quasar said:

BTW, the original version of Aliens TC was also affected by this problem now that I think about it. The Queen Alien was made from the Baron of Hell.

So it was, well remembered!

[cycloid]

cph said:
Yes, I started doing per-engine levels for PrBoom 2.3.0, which is much cleaner than my original scheme in 2.2.x. Most of the work for 2.4.0 was moving this into the stable codebase. It appears than Prboom+ has used something like the 2.3.x scheme but has added more levels - the extra ones look sensible, so I will try to converge on the same numbers if possible.[/B]

how about, instead of using an arbitary int to select complevel use a string:

complevel "doom1.2"
complevel "doom1.6"
complevel "doom1.9"
complevel "doom2"
complevel "boom1.1"

#define COMP_DOOM1_2 2

...

if( !strcmp( sCompLevel , "doom1.2" ) )
{
	giComplevel = COMP_DOOM1_2;
}
else
...

would avoid confusion (apart from, heh, the fact that here i've set doom2 and doom1_9 as seperate complevels)

also, i can confirm, via some doom2 sourcecode investigation in a recent other thread of mine that the commander keen death pointer is different from the other 666 specials in that it

1. creates a linedef object
2. assigns it a tag of 666
3. calls the door function with "door open" and a pointer to the linedef

therefore the engine has no way of knowing that the player didnt activate the "open door 666" instruction via, say, flicking a switch. so yes, it works for any monster, on any map

[entryway]

cph said:

you'll have to wait for 2.4.1

Till next year?

[Jon]

entryway said:

Till next year?

Some of us have jobs...

[entryway]

Jon said:

Some of us have jobs...

Really?

[Quasar]

Take the routine from Eternity's e_lib.c called E_StrToNumLinear -- it's great for that kind of thing ^_^

[cph]

entryway said:
Till next year?

Next week, possibly.

cycloid said:
how about, instead of using an arbitary int to select complevel use a string...

complevel was never really meant as a public interface; it is for my debugging use, and getting the very few demos to work where the compatibility can't be autodetected. But I suppose as people do need it for recording doom1.9 demos, and this seems to be actually used by some people, I should make it a bit more user-friendly. Easy to do.

[entryway]

Don't forget to correct this bug:

[-] Boom bug: desyncs after using the key for switching to SSG directly with demo compatibility. This bug is present in current Eternity too.

*** D:\andre\prg\prboom-2.4.0\src\g_game.c	Sun Apr 02 13:18:08 2006
--- D:\andre\prg\prboom-2.4.1\src\g_game.c	Thu Apr 06 11:41:45 2006
*************** void G_BuildTiccmd(ticcmd_t* cmd)
*** 397,402 ****
--- 397,403 ----
          gamekeydown[key_weapon6] && gamemode != shareware ? wp_plasma :
          gamekeydown[key_weapon7] && gamemode != shareware ? wp_bfg :
          gamekeydown[key_weapon8] ? wp_chainsaw :
+         !demo_compatibility && //e6y
          gamekeydown[key_weapon9] && gamemode == commercial ? wp_supershotgun :
          wp_nochange;

*** D:\andre\prg\prboom-2.4.0\src\p_user.c	Sat Apr 01 13:15:58 2006
--- D:\andre\prg\prboom-2.4.1\src\p_user.c	Thu Apr 06 11:40:10 2006
*************** void P_PlayerThink (player_t* player)
*** 343,348 ****
--- 343,349 ----
  
      if (demo_compatibility)
        { // compatibility mode -- required for old demos -- killough
+       newweapon = (cmd->buttons & BT_WEAPONMASK_OLD)>>BT_WEAPONSHIFT;//e6y
        if (newweapon == wp_fist && player->weaponowned[wp_chainsaw] &&
          (player->readyweapon != wp_chainsaw ||
           !player->powers[pw_strength]))

*** D:\andre\prg\prboom-2.4.0\src\d_event.h	Sat Apr 01 13:15:58 2006
--- D:\andre\prg\prboom-2.4.1\src\d_event.h	Thu Apr 06 11:40:49 2006
*************** typedef enum
*** 95,101 ****
    BT_CHANGE       = 4,
  
    // The 4bit weapon mask and shift, convenience.
! //BT_WEAPONMASK   = (8+16+32),
    BT_WEAPONMASK   = (8+16+32+64), // extended to pick up SSG        // phares
    BT_WEAPONSHIFT  = 3,
  
--- 95,101 ----
    BT_CHANGE       = 4,
  
    // The 4bit weapon mask and shift, convenience.
!   BT_WEAPONMASK_OLD   = (8+16+32), //e6y
    BT_WEAPONMASK   = (8+16+32+64), // extended to pick up SSG        // phares
    BT_WEAPONSHIFT  = 3,

[fraggle]

cycloid said:

how about, instead of using an arbitary int to select complevel use a string:

complevel "doom1.2"
complevel "doom1.6"
complevel "doom1.9"
complevel "doom2"
complevel "boom1.1"

This is FYI how Chocolate Doom does it. I figured it was a sensible interface.

[Quasar]

Oh no, more weapon issues ::bangs head into wall::

[Grazza]

cph said:

But I suppose as people do need it for recording doom1.9 demos, and this seems to be actually used by some people, I should make it a bit more user-friendly. Easy to do.

Actually quite a lot of people use it - pretty much everyone who uses Prboom to record, and anyone who wants an easy way to set the behaviour to a particular type without having to modify all the settings individually. And since 2.3 (and recent changes in -plus), everyone who wants to watch a non-standard demo.

Please don't remove the numerical complevels - this would cause confusion and probably errors. However, it would certainly be nice to have the option of using a more user-friendly text description of the complevels, especially as these would presumably remain OK even when the numerical versions changed. Thus to get Doom2.exe compatibility you could use either -complevel 2 or -complevel doom2_19 (e.g.).

BTW, on that last point, it might be logical to match the text complevel labels to those used internally (in g_game.c: doom2_19, ultdoom, finaldoom, etc.).

[myk]

I don't even see why changing from numbers to tags matters or helps. The levels are explained in the documentation, and that is enough for any user who cares to use them, in addition to being textually more economical (if you want to change the default in the CFG or the current level in the command line all you modify is a digit.)

[cycloid]

myk said:
in addition to being textually more economical (if you want to change the default in the CFG or the current level in the command line all you modify is a digit.)

[sarcastic comment about saving 5 bytes]

[fraggle]

myk said:

I don't even see why changing from numbers to tags matters or helps. The levels are explained in the documentation, and that is enough for any user who cares to use them, in addition to being textually more economical (if you want to change the default in the CFG or the current level in the command line all you modify is a digit.)

What happens if cph wants to add a level supporting eg. Doom 1.1?

[entryway]

Never happens :)

[myk]

Heh.

fraggle said:
What happens if cph wants to add a level supporting eg. Doom 1.1?

Are there wads that work with v1.1 and not v1.2, or is that possible?

I guess he could add some level between others... which would force a restructuring (again.)

[CODOR]

myk said:

I don't even see why changing from numbers to tags matters or helps.

I think it would, mainly because the numeric compatibility levels change in every major release of PrBoom (e.g. MBF compatibility was 7 in 2.2 and 2.3, but it's 9 in 2.4). With text strings one could avoid having to check README.compat every time they want to test a level or record a demo while emulating a previous version (assuming they haven't memorized the numeric values already)...

[myk]

CODOR said:
(assuming they haven't memorized the numeric values already)

In retrospect maybe "user friendliness" is confusing; indeed a player that commonly uses the engine will memorize the values he uses often, while more casual users may find version or variant names more clear, or a coder may find these consistent and more modifiable. Thus Grazza is seemingly wise in urging to keep the old values if the new method is added.

Additionally "-complevel" is pretty long in itself, and refers to an actual "level", while a tag would be a version or variant name. Maybe -ver or -exe could be added as an alternate command (as a synonym.)

[funduke]

myk said:

(...) users may find version or variant names more clear, or a coder may find these consistent and more modifiable.

That counts for me. It would help me to memorize.

Greetings
Funduke

[fraggle]

myk said:

Heh.

Are there wads that work with v1.1 and not v1.2, or is that possible?

I'm just using this as an example.

I guess he could add some level between others... which would force a restructuring (again.)

Exactly. If you use symbolic names, you can add in new levels whenever you want without this being a problem. In the current system, restructuring as a result of inserting a value somewhere results in existing users having to re-learn the values all over again.

Besides, using meaningless numerical values for levels like this is entirely unintuitive. I don't know why anyone would rather remember a number that has no correspondence to its meaning over a descriptive symbolic value. This goes for both "common" and "casual" users.

Basically it makes infinitely more sense to use symbolic values.

[proff_fs]

Because the doomworld staff is either sleeping, not checking their mail or otherwise occupied I post this here.

PrBoom 2.4.1 released.

Changes from v2.4.0 to v2.4.1
- PrBoom demos are now recorded with high-precision turning (like the "Doom v1.91" hack that is floating around)
- when both -nodraw and -nosound are supplied, then no graphics will be initialized and no windows opened
- add ultdoom compatibility level, and bring compatibility levels into line with Prboom+
- screenshots now use correct palette in software mode
- screenshots now in PNG format on Linux/Unix where available
- suppress use-supershotgun key in compatibility mode
- removed obsolete video related code
- fix screenshots on 64bit systems
- fix comp_666

Get it from http://prboom.sourceforge.net

[funduke]

Thank you!
This fast development is cool!
:)
Greetings
Funduke