Map Compatibility Catagories Explained

[Quasar]

I was asked in a private message to clarify the various different compatibility catagories after a discussion in the newest /newstuff brought up the subject. I figured I'd post it here for everyone else too.

Note the distinction I make between the two different levels of Limit Removing isn't firmly established in the community, though I think it needs to be in the future due to the relative newness of seg limit extension, and the fact that not all ports that remove basic limits address this too.

Vanilla -- These are maps which are 100% compatible with the original DOS DOOM.EXE or DOOM2.EXE program. This is the most restrictive format and has severe limitations and is subject to working around petty bugs in the game engine. Chocolate DOOM plays 99.9% of these wads, and only wads from this catagory, as it attempts to emulate Vanilla exactly.

Limit Removing (Lv 1) -- These are maps that WOULD run in Vanilla DOOM except that they exceed static limitations such as the visplane limit, visible sidedefs limit, visible sprites limit, etc. Maps in this catagory do not use any new source-port specific editing features, and they do not have a seg, vertex, or sidedef count greater than 32767 (see Limit Removing (Lv 2) for that...). A "limit removing" source port is required to play most of these maps, although a great number of them can now be used with the unofficial DOOM v1.92 patch for DOS DOOM which expands some of the internal limits. Virtually all source ports will play maps in this catagory.

BOOM-Compatible -- The source port BOOM defined a new paradigm for DOOM editing. It was quickly decided that the BOOM feature set was a bare minimum that more or less all ports needed to support. These include such features as generalized line specials, deep water, conveyor floors, push/pull/wind/current, and various other tweaks and additions. BOOM-compatible ports generally make a big deal out of this, and include among many others MBF, PrBoom, SMMU, Eternity (my port), DOOM Legacy, and ZDoom. The latter two ports did not descend from BOOM directly, however, and therefore have a number of issues with their BOOM compatibility.

Limit Removing (Lv 2) -- This is a fairly new catagory which may or may not be combined with the others. Maps in this catagory require a limit removing port which goes even further and at least doubles the limit on segs, vertices, and sidedefs in a single map from 32767 to 65535. The main ports I know of that do this at the present are Eternity, PrBoom, and ZDoom (some others do also but I can't remember which at the moment...) This enables extremely large and/or detailed maps to be made. This change does not require any alteration to the WAD or map format; it's simply a hack known in programming as sign extension, and takes advantage of space that the original DOOM was simply wasting.

ZDoom -- Pretty simple. Maps that only run with ZDoom or one of its daughter ports such as ZDaemon or Skulltag. Maps which are meant to be BOOM-compatible but rely on ZDoom's idiosyncracies may be relabeled as ZDoom-only once disgruntled players discover they don't work properly in other ports.

[Doom_user]

One suggestion, since Boom-compatability can entail limit-removal level 1 or 2, wouldn't it make sense to split it into 2 levels as well?

Boom-compatible (Lv 1) < 32,768 segs
Boom-compatible (Lv 2) > 32,767 segs

[myk]

I think it can be rather misleading to attempt to define "categories" for wads, because in the end it all comes down to three things; the engine(s) used while making and testing the wad, how well the wad was tested, and the engines used by players.

The only true definition of a "vanilla" wad is a wad that runs fine on Doom. That is generally attained without issues by testing it to a reasonable degree using Doom (or Chocolate Doom). Other engines can be used but the more one deviates, the more necessary it should be to at least give it a run through with Doom or Chocolate.

The same thing goes for "boom". The ultimate test for Boom compatibility is Boom itsef (the v2.02 DOS build), although PrBoom v2.02, and the latest PrBoom or PrBoom+ (when used with compatibility level 9) will do a great job. Also, Quasar, you left Risen3D out of the picture (it's a JDoom offshoot with Boom support).

The "limits" are also engine specific, as there are not 2 levels, but as many as there are engines getting rid of or extending certain limits and not others. Good testing for different levels of extension, or the lack of are Doom (no limit extensions), Doom+ (limits extended up to where hacking the EXE without disturbing compatibility may allow), Boom (Boom limit extensions), Boom+ (more or less as Boom but with doubled segs limits), ZDoom (similar to Boom+, but deals differently with the levels in a way that allows it to bypass limits even more). I think Legacy is similar to Boom, but maybe even weaker in some respects (this might depend on the particular version.)

Quasar said:
ZDoom -- Pretty simple. Maps that only run with ZDoom or one of its daughter ports such as ZDaemon or Skulltag. Maps which are meant to be BOOM-compatible but rely on ZDoom's idiosyncracies may be relabeled as ZDoom-only once disgruntled players discover they don't work properly in other ports.

Note that ZDoom, ZDaemon and Skulltag have differences that may make levels tested only on them exclusive, or glitchy in the other two engines or other versions of themselves. Also, this can't be said only of ZDoom, as it applies to any engine. The problem comes up when any such engine is used to test a wad aimed to support some other engine. Using PrBoom to produce a Doom wad could fail miserably, especially if the right compatibility settings aren't enabled. All engines have idiosyncracies, which are basically any differences with other engines.

[Graf Zahl]

myk said:

I think Legacy is similar to Boom, but maybe even weaker in some respects (this might depend on the particular version.)

I wouldn't call Legacy Boom compatible. The missing voodoo doll support alone makes most Boom compatible maps unplayable.

And even though Legacy has implemented all Boom features on a superficial level there are considerable differences in the implementation of a few things which may also break a WAD on occasion or negatively affect its performance.

I haven't looked at the v2.0 source sufficiently yet to say whether this has changed or not.

[DaniJ]

You can also add Doomsday (all supported games) to the list of lvl2 limit removing ports. As of 1.9.0-beta4 all the internal map limits have been extended using discussed sign extension hack. So too have all the playsim related limits such as spechits, the find next floor algorithm etc.

1.9.0-beta4 also sees the initial steps to BOOM compatibility such as ANIMATED & SWITCHES support, fixed voodoo dolls, "push through" line flags and a bunch of other stuff.

The generalized linedefs, deep water etc are being intergrated at a more fundamental level so support for those is going to take a bit longer.

But we are on the way to full BOOM compatibility.

1.9.0-beta5 will see full support of all known GLNode formats too (v3 support is already present in beta4).

[myk]

Graf Zahl said:
And even though Legacy has implemented all Boom features on a superficial level there are considerable differences in the implementation of a few things which may also break a WAD on occasion or negatively affect its performance.

True, though I was referring to limits extensions (not features). I beleive I read they raised the sidedefs limit (or something like that) rather late or to a lesser degree, so even in regard to map dimensions/detailing it's been behind Boom somewhat (not sure how the code is currently, either).

[andrewj]

EDGE is another limit removing port, both Lv1 and Lv2, and BOOM compatibility is being worked on right now.

Lv2 limit removal also applies to level editors and node/reject builders (not very useful if your node builder chokes). glBSP supports Lv2 since version 2.10 (september 2004).

Graf Zahl said:

I wouldn't call Legacy Boom compatible. The missing voodoo doll support alone makes most Boom compatible maps unplayable.

I never knew that Voodoo dolls were so important, what are some good wads to test against?

[Graf Zahl]

Ajapted said:

I never knew that Voodoo dolls were so important, what are some good wads to test against?

Here's a few I know for sure:

Phobos: Anomaly Reborn
IC2004+2005
Community Chest 2
Demonized
Vrack 2+3

IC2005 has 45(!) voodoo dolls. VoodooScript is quite popular in Boom maps. ;)

[myk]

Ajapted said:
I never knew that Voodoo dolls were so important, what are some good wads to test against?

Plutonia's Map06 (Baron's Lair) uses one at the initial room to grant the Player weapons. Get under that box with skulls. So it's something that an id-released IWAD depends on to function properly.

[TheDarkArchon]

Not to mention the last level of Evilution.

[myk]

TheDarkArchon said:
Not to mention the last level of Evilution.

Right, the teleporter traps. That's even more serious.

[Hobbs]

Ajapted said:

I never knew that Voodoo dolls were so important, what are some good wads to test against?

It is indeed very important. Voodoo Scripting is often the easiest, best, or only way to get some complex shit done in Boom maps. And as pointed out even the IWADs use voodoo dolls, so the removal of voodoo dolls is pretty damaging.

[Quasar]

Of course this wasn't meant to be a comprehensive port compatibility list, so I didn't attempt to list every port that supports the various types of compatibility. You'd usually check out that sort of thing when starting to develop for the port.

Also, some of the levels are combinable. This is why I did not make up stuff like "Boom Compatible Lv2" because it's the same as Boom Compatible combined with "level two" limit removal. They're like flags.

A description of Eternity might be like this:

Vanilla|LimitRemoving|BOOM|LimitRemoving2

[Grazza]

Plenty of vanilla maps use voodoo dolls. Not just to kill the player, but to pick items up, telefrag monsters (including ones to trigger map specials), cross lines, etc.

I couldn't quickly find a listing of levels that feature them, but here are a few off the top of my head in addition to those already mentioned:

galaxia (a hazard)
plutonia map28 (picking up BFG for the players)
caesar (as spectators)
heroes e4m8 (to telefrag spider masterminds)
twins
hr map19 (right at the start and makes a huge difference)
eternal map26
awad map09 (lol)
av map25 (picking up invuls for the players)
nuts2 (not really used though)
ksutra map22 (not sure/can't remember what this one is here for, but the player can also reach it)
ksutra map24 (telefragging monsters and crossing exit linedef)
Some of shtbag's early maps (to pick stuff up), but I can't remember which

vile (Vile Flesh) map16 (the wad overall needs Boom, but uses no Boom specials)
cydreams map31 and map32 (OK, they're Boom maps, but the same idea could be used in a vanilla wad)

I agree that describing a category as "Boom compatible" is going to cause confusion if those maps can't be handled at all by Boom itself (i.e. Boom or Prboom 2.02, not current Prboom/-plus). I think this is a useful venture by Quasar, as these labels are useful and can be clearly and naturally defined. Most of them are also already in use (with a general consensus on what they ought to mean), so these clarifications of their meanings is especially useful.

Of course, there is always devil in the detail of a categorization. "Limit removing" generally relates to the extension of things like the visplane, sidedef and visprites limits. It is possible to find (and construct) maps that work perfectly well with Doom2.exe that are broken (partly or completely) by the removal of certain other things that could be regarded as a limit (e.g. STRAIN map07). But that's kind of nitpicky, and the general sweep is clear enough.

For an "enhanced Boom" category, you could perhaps use a term like "Boom features + extended limits".

I don't agree that all that should be stated is what a wad has been tested with. It makes sense to state what the intended port or port-type is, and what it has been tested with, together with mentioning anything that it will definitely fail with. This helps people decide for themselves whether to bother trying anything other than the listed exe(s), and also provides useful information about what settings may be needed.

As a final note, I'll mention that for demo recorders, the difference between "extended limits lv 2" and "Boom features + extended limits lv2" is particularly significant. Being able to record with vanilla behaviour is generally more pleasant than with Boom behaviour (e.g. live monsters don't get knocked off ledges; the PE/LS limit is in place).

[DooMAD]

Graf Zahl said:

I wouldn't call Legacy Boom compatible. The missing voodoo doll support alone makes most Boom compatible maps unplayable.

And even though Legacy has implemented all Boom features on a superficial level there are considerable differences in the implementation of a few things which may also break a WAD on occasion or negatively affect its performance.

I haven't looked at the v2.0 source sufficiently yet to say whether this has changed or not.

Voodoo dolls appear to be implemented in recent CVS alpha builds, although I haven't really tested it.

[Checkmate]

Grazza said:

I don't agree that all that should be stated is what a wad has been tested with. It makes sense to state what the intended port or port-type is, and what it has been tested with, together with mentioning anything that it will definitely fail with. This helps people decide for themselves whether to bother trying anything other than the listed exe(s), and also provides useful information about what settings may be needed.

True. The author knows the problem points and can go there quickly while using a port to test them out. Also, a subtle incompatability in a wad may not break it, but could dramatically change the experience without the player knowing it's an incompatability issue.

[Doom_user]

Something else that I was thinking about earlier, should the ability to display fsky simultaneously on the floor and ceiling be taken into account as a removed-limit? When I was running some tests recently, I noticed that Chocolate Doom (presumably Vanilla as well?), Eternity, and Legacy produced HOM while PRBoom and ZDoom rendered without problems. I haven't tested Doom 95 or Boom 2.02/PRBoom 2.02.

Do many maps even use this effect?

[myk]

Grazza said:
I don't agree that all that should be stated is what a wad has been tested with. It makes sense to state what the intended port or port-type is, and what it has been tested with, together with mentioning anything that it will definitely fail with. This helps people decide for themselves whether to bother trying anything other than the listed exe(s), and also provides useful information about what settings may be needed.

Not sure who you're disagreeing with, since no one said those things shouldn't be noted; they are in the text file as well ("advanced engine needed" and "may not run with"). My emphasis on testing is that it's newly added into the TXT template (and doesn't appear in the database TXT maker yet) and many people are unaware of it, and that it is a very empirical and straightforward piece of information, so it can be useful beyond what one could expect from any projections. "Advanced engine needed" can become outdated when more engines that can run said wad are released or updated, or the author may be mistaken, and "may not run with" is often incomplete, including only that which the author is aware of.

"Tested with" is very useful because as long as it's included with version and all, it provides objective information on what the wad can be more or less guaranteed to work as expected.

Quasar:
You'd usually check out that sort of thing when starting to develop for the port.

Not just that; someone who is a Risen3D user by preference could want to make a wad that is "Boom compatible", doing a lot of testing on Risen3D. He needs to understand the differences, but also in order to guarantee that it really is Boom compatible a very faithful port of Boom should also be used for testing, if not Boom itself. That's what there is to "compatibility". Likewise, any wad that aims to be a standard Doom wad (with or without extended limits) will be less buggy if tested on the most convenient engine to a degree (such as PrBoom comp level 2 or Doom+, or Chocolate or Doom). The author should (in order of importance in regard to compatibility):

• Guarantee it works on the "base engine" of choice.
  
• Make sure it works on his favorite engine.
  
• Make sure it works on other supposedly compatible engines the author is aware of, as far as possible, reporting any annoying comaptibility bugs if these get in the way. If he is really generous, also noting any issues some supposely compatible engines might have with the wad.

In short, Doom compatibility is defined by Doom v1.9, and Boom compatibility by Boom v2.02, and defining them as "categories" isn't too helpful because things get generic as opposed to specific. Other engines port or emulate these for better or worse, but only they can gurantee being what they are. With generalities (categories) people assume things, and thus make mistakes, with specifics (practical down to earth info) they can work them out. People that have been releasing buggy Boom or Doom compatible wads are already aware that there are things called Doom and Boom that have more or less features and restrictions, but in order to produce less glitches, they need to know what steps to take to reinforce or guarantee compatibility.

[cycloid]

it's worth remembering, in all this categorisation that whilst aiming for pure doom or bom compatibility is desirable some of us use windows ports as a preference. Personally my targets are either Chocolate Doom or WinMBF compatibility.

Though I am aware, for example, that my current winMBF targetted and tested project has issues with zDoom.