Benchmark for Boom testing

[doom2day]

Which is the best benchmark program for testing levels for if they are truly boom compatible? Boom is the first to come to mind, but not many people that I know of (just stereotypes and myself) use boom anymore. Is MBF a good start?

[Maes]

PrBoom comes to mind.

[John Smith]

If you're really fucking serious about it being straight boom compat, then obviously you need to use Boom itself. Otherwise just use PrBoom.

[RjY]

Many thanks for taking the time to test your levels properly.:) I would also recommend PrBoom or PrBoom-Plus if running Boom itself is too much of a hassle.

If you do use one of them, you could try putting "-complevel 9" on the command line, which will force all the correct compatibility options to be set (that's how I've been doing my cc3 map)

[chungy]

Yeah, PrBoom has full Boom compatibility afaik, but it does have extra features of its own so you'll need to set the compatibility level to test true Boom compatibility.

[myk]

In addition to PrBoom(+) with the compatibility level 9, you can use PrBoom v2.02, which is a plain port of Boom to Windows.

[doom2day]

And monsters are unaffected by wind/current in boom?

[printz]

I don't think monsters are affected by wind or current...

But by gameplay, isn't PrBoom practically MBF?

[Quasar]

PrBoom does include most features from MBF, but I'm guessing that they can be disabled via use of the complevel feature (??).

I can't recommend Eternity as a perfect way to test Boom maps because we do fix some Boom bugs unconditionally; for example, the one that can cause raise-by-lower-texture lines to raise by the height of the AASTINKY/AASHITTY texture if one or more sidedefs in the sector are set to have no texture. We also have different behavior of sector colormaps (see the "disco" room in BOOMEDIT.WAD to see the difference; in virtually all other existing maps this makes no difference though).

A majority of Boom maps should work identically in Boom, MBF, PrBoom, and EE. Those that don't will usually operate "within tolerances." As long as you're aware of the differences, you could actively design around them.

[printz]

Quasar said:

we do fix some Boom bugs unconditionally; for example, the one that can cause raise-by-lower-texture lines to raise by the height of the AASTINKY/AASHITTY texture if one or more sidedefs in the sector are set to have no texture.

Hey, aren't some maps designed with that "bug" in mind? What if they raise the wrong way? You'd probably screw the compatibility.

[myk]

printz said:
What if they raise the wrong way?

Use another engine to play those wads, such as PrBoom, which is made with an emphasis on its compatibility modes. Otherwise Eternity supports all the Boom features and makes sure any usual Boom wads will work with it.

But by gameplay, isn't PrBoom practically MBF?

It's basically MBF if you use MBF compatibility, basically Boom if you use Boom compatibility, and so on. Used plainly (without any compatibilities) it applies a number of fixes none of the engines it provides compatibility with have. It also lacks a couple of things MBF has, like DOOM beta support and OPTIONS lump support. There's also WinMBF, that Quasar ported, for MBF compatible wads.

[Quasar]

So far I'm unaware of any such maps. If one comes to light, I'll see about providing some method of dealing with it :) Some things are better not messed with unless they actually become a problem.

It was in fact the opposite situation that prompted me to fix it in the first place. Someone had been testing the map in PrBoom, which already fixed the problem, and then complained that it was broken in Eternity. So I fixed it. In fact, that particular bug *MAY* have been fixed in BOOM v2.02. MBF was based on BOOM v2.01 with a few v2.02 features thrown in at the very last minute, so there are possibly still some v2.02 tweaks missing from EE.