08/09/2008 @22:37:16 ^01:33:36

Yeah I haven't felt like writing much recently. In order to fill a silence here's some thoughts on demo compatibility, and PrBoom's complevels. I suppose it could be considered a followup to a previous post.

Demo playback versus total emulation

Compatibility level has two interpretations, which I have dubbed "weak" and "strong":

• Weak: Emulate enough of the bugs of the emulated engine to allow demos recorded by it to be played back; or
• Strong: Behave as much like the emulated engine as possible.

I believe PrBoom initially defined complevels using the weak interpretation. On the other hand PrBoom-plus greatly favours the strong interpretation.

Recording demos in old formats

The weak interpretation is only concerned with demo playback. A third point on the sliding scale might be:

• Emulate enough of the engine's bugs in order to record demos that it can play back.

Achieving 100% recording compatibility with old engines is, I believe, prohibitively difficult. It's not impossible - PrBoom-plus is pretty close - but it comes at a cost. Code becomes full of ugly hacks, is unmaintainable, and is impossible for a casual source reader to follow.

As examples, consider that for doom2.exe you have to worry about array overflows and uninitialised variable problems; or for true boom.exe-compatibility, you have to bring back its friction code, which is so awfully written that Killough ripped it out of MBF despite being fully aware of the consequences.

Two orthogonal compatibility systems

As I said before, allowing recording of old demo formats means you can end up recording broken demos if your emulation is not 100%. These demos might play in PrBoom but fail in the engine that it's supposed to be emulating, or run in an old version but fail in the latest.

If you want to play back such demos you need to tell the engine to emulate a previous version's bad emulation. The current way of doing this in PrBoom-plus is by adding something like "-emulate 2.2.6" on the command line (the actual demos themselves are indistinguishable from real ones recorded in the same format - there's no way to tell a doom2.exe demo wasn't recorded with doom2.exe)

Thus a second, orthogonal, compatibility level system has evolved. You effectively have a matrix of compatibility levels crossed with old version numbers. And with about 17 complevels and a couple of dozen old engine versions, you can imagine the potential number of combinations that have to be handled.

and then there is -doom95 and -exe chex

Non-sync-sensitive compatibility options

Some features in newer engines don't affect demo compatibility.

MBF sky transfers are the obvious (and controversial) example. As a purely cosmetic effect they don't affect demo compatibility at all. So, unless you really, really care about strict compatibility with an old engine executable, you might as well just allow them without any messing about with complevels.

I think it should be left up to the map author - if he is comfortable with using a sky transfer in a Boom map and is aware of the consequences, let him. After all, I would argue those consequences are extremely minor.