Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  

PrBoom+ compatibility proposals

Recommended Posts

The -complevel parameter is a mess, so I have this proposal:

Add -gameversion from Chocolate Doom. This tells the game to behave like one of the games, regardless of which IWAD is loaded. It defaults to the appropriate IWAD if not specified. This has no effect on the demo version number (not that it ever did).

Archive the -complevel parameter and don't update it anymore unless necessary (such as if PrBoom were to need to add a level). Disable it for recording, leaving it only for playback.

Add a -comp or -compatibility parameter. This takes clear mnemonics instead of abstract numbers, such as:

1.2 (Doom v1.2)
1.666 (Doom v1.666)
doom (Doom v1.9)
doom-plus (Doom-plus, but adds intercepts 1024)*
doom-prboom (Doom "removing" limits instead of raising them)*
dosdoom (DOSDoom v0.47)
tasdoom (TASDoom)
boom (Boom v2.02)
boom_doom (Boom v2.02 Doom compatibility)
boom_prboom (Boom with PrBoom's higher limits)*
boom_2.01 (Boom v2.01)
lxdoom (LxDoom v1.4)
mbf (MBF v2.03)
prboom_2.1 (PrBoom v2.1.0)
prboom_2.1.1 (PrBoom v2.1.1 to v2.2.6)
prboom_2.3 (PrBoom v2.3.x)
prboom_2.4 (PrBoom v2.4.0)
prboom (Current PrBoom, default)

Default_compatibility_level would become Default_compatibility (using the above instead of numbers).

You can allow -longtics by making it modify the version number; 1.9 becomes 1.11, Doom-plus becomes whatever it needs to become (if it's 1.12 it could become 1.13).

* These need new version numbers. I wouldn't add "PrBoom" versions for MBF and the other compatibility levels because they are not really recording compatibilities (except maybe boom_doom?). The Doom-plus hack itself would be modified likewise, changing the demo version and raising the intercepts limit. I think it would be proper to keep most of the emulation on doom-prboom because it has mostly been applied to recorded demos and it is harmless. It can be disabled as usual on demos that didn't use it. Nonetheless, it would be wise to remove intercepts, though, because it is not reliable (during gameplay it depends on dynamic factors, and you don't want PrBoom to crash so it's not perfect emulation) and because you are already raising it in Doom-plus.

If people feel there is a problem with the length of the tags (on the command line), abbreviated names can be added for each, using few characters, like pr24 (prboom_2.4), d (doom), b (boom), b_d (Boom's Doom compatibility), d-p (Doom-plus), &c.

Limits (excluding "emulation") are best applied only during recording. During playback they can be ignored, which would make all the existing "limitless v1.9" demos play back fine.

Why do this?

  • The current system is not intuitive. Each number doesn't mean much in relation to what it represents.

  • The current system inhibits additions or corrections, because for organizational purposes it may require renumbering, as it has happened in the past. Boom compatibility was 5 for some time, and even 3 earlier on.

  • By using Doom and Boom compatibility levels the way they are now the engine is generating demos with "PrBoomisms". Their version says they are Doom or Boom yet they likely don't work in said engines. The only guarantee that they will work is if they worked during recording, and that is not possible to determine when the limits are gone. While stuff like VPOs are nearly static in a level, they still depend on what the player does. PWADs don't warn you they don't work in an engine so the demo may as well do so directly if it can.

  • Doom-plus as it is is only semi-useful, because once you make maps that are big or very populated, the very low intercepts limit makes them very unstable. Doom-plus itself is also generating demos with "Doom-plusisms" as described above for PrBoom.

  • You can do this in PrBoom+ without compromising behavior or compatibility with PrBoom. It would be up to Proff I suppose to implement it there, but I guess that's up to him.

Share this post

Link to post


I think the system in place is alright but I do like the sound of this as a good and reasonable way to both permit a higher degree of control and specificity while becoming more intuitive for the end user.

I'm sure you haven't forgotten there are 3 versions of 1.9 Doom\2 uDoom\95 & fDoom a user might wish to use with different iwads. Though yes there definitely should be some sort of overridable 'default' action taken for each iwad like Chocolate Doom. The simplest solution I could come up with was my suggestion to have something like this in the config...

default_complevel_for_doom.wad		2
default_complevel_for_doomu.wad		3
default_complevel_for_doom2.wad		2
default_complevel_for_tnt.wad		4
default_complevel_for_plutonia.wad	2
Also I don't know how exactly the 'tntcomp' code would be handled but it would be nice to be able to define a range of values in the config that 'tntcomp' will cycle though. For instance someone could set the config to skip all but complevel 2 and 3 and 9 so that typing 'tntcomp' only cycles through the defined 3 levels to make launching a game and setting its complevel in game even easier and obviously it's just for playing or practicing and not for recording.


P.S. If I may go off topic for just a moment. Hi myk, I just wanted to let you know that I've been a lurker on the the forums for years and you've always had helpful posts, knowledge and insights that I've enjoyed reading over the years. Well, I know it doesn't mean much but after our discussion in the other topic I thought I'd let you know. :)

Share this post

Link to post

Why would Plutonia and TNT use different complevel values? Didn't they share the same exe?

Share this post

Link to post

I thought I should have elaborated on my example.

You are right they normally should be the same but maybe you are a speed runner wanting to practice as if plutonia were a pwad to doom2 and its executable. I believe some COMPET-N demos only work in prboom if played under the doom2 complevel. I guess it acts as if you were running plutonia as a pwad or as if you renamed plutonia.wad to doom2.wad... either way its a level of control some might wish to have. The rest of us could just make them all 3 or 9 or whatever and toggle ingame with tntcomp.

Share this post

Link to post

It's cool to see some support for this.

One thing, HackNeyed; your suggestions still use complevels, while mine would deprecate these for -comp (or -compatibility) and the new name tags. With the new method the multiple defaults could be:

default_doom_compatibility		doom
default_ultimate_doom_compatibility	doom_prboom
default_doom2_compatibility		doom-plus
default_plutonia_compatibility		prboom
default_tnt_compatibility		boom
Personally, I'm not sure about multiple default compatibilities, though, because various people may prefer the simpler single default compatibility. Many use batch files or shortcuts (or Linux scripts or whatever) to set different compatibility modes for different WADs or games in progress, and this might depend on various other factors, and not just the IWAD used. You could have various ongoing games on the same IWAD but using different compatibility modes, because you're practicing for COMPET-N, because a PWAD requires it, because your friend wanted to coop under a certain behavior, and so on.

I hadn't thought of the the tntcomp cheat. Maybe it could be left more or less alone, adding the mnemonics as additional cheats. Typing "tntdoom" would switch to Doom compatibility, "tntboom" to Boom, "tntdoom_prboom" to "limitless" Doom, and so on. Else the short names suggested above could be used in some way (or in addition).

Hi myk, I just wanted to let you know that I've been a lurker on the the forums for years and you've always had helpful posts, knowledge and insights that I've enjoyed reading over the years.

Hey, thanks, and you're welcome!

Share this post

Link to post

I was only saying that a default complevel in the config was the simplest solution I could come up with for the current system. If it simply defaulted to the proper 1.9 version depending on the iwad when set or unspecified would be great. You could still allow variations such as doom2, udoom and fdoom to force a specific behavior in the config or comline if someone wanted to play TNT as if they were playing in doom95 (ie Ultimate Doom behavior). I use tntcomp alot and it becomes a pain just to 'go back' a few complevels though.

I really like where you are going with this though dealing with the 3 versions of 1.9 can get confusing so maybe change auto behavior from 'doom' to 'vanilla' or 'id' or '1.9' or 'iwad' or 'auto' or 'auto_1.9\iwad' or something to avoid confusion. Keeping it simple and intuitive for the user is of course the ultimate goal here so the naming convention must be simple yet very specific about what it does.

Share this post

Link to post

HackNeyed said:
I really like where you are going with this though dealing with the 3 versions of 1.9 can get confusing so maybe change auto behavior from 'doom' to 'vanilla' or 'id' or '1.9' or 'iwad' or 'auto' or 'auto_1.9\iwad' or something to avoid confusion.

That would be handled by -gameversion (as in Chocolate Doom). It needs be set only on rarer occasions, as generally it depends directly on the IWAD. With this method using a single default setting of "doom" would indeed give each IWAD its proper behavior (equivalent to current levels 2, 3 and 4).

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this