By what criteria you decided so I dunno. Okay. Then dsda-doom is not doom anymoaaaaar. Becuase modurn mbf21 soyce ports grow on bloat that turn them into something that ZDoom is able for 20+ years, but not compatible with ZDoom
Seems an emotional bad faith take, but I'll bite. The criteria for "hurr durr Vanilla" is how the game engine behaves. Given the same input, no matter how long the recording, you get the same output.
From the UZDoom source code:
C++:
if (ReadInt32 (demo_p) != FORM_ID) // g_game.cpp:2992
{
const char *eek = "Cannot play non-" GAMENAME " demos.\n";
...
if (singledemo) I_Error ("%s", eek);
}
If a recording is a .lmp, error out. That's ZDoom's solution to accuracy; we don't validate it anymore.
Lee Killough is the guy who wrote the original MBF. He left this long comment explaining how he rewrote MBF's friction code in order to retain compatibility, or "stay Vanilla".
UZDoom's playsim/p_spec.cpp:
C++:
// killough 8/28/98:
//
// Completely redid code, which did not need thinkers, and which put a heavy
// drag on CPU. Friction is now a property of sectors, NOT objects inside
// them. All objects, not just players, are affected by it, if they touch
// the sector's floor. Code simpler and faster, only calling on friction
// calculations when an object needs friction considered, instead of doing
// friction calculations on every sector during every tic.
//
// Although this -might- ruin Boom demo sync involving friction, it's the only
// way, short of code explosion, to fix the original design bug. Fixing the
// design bug in Boom's original friction code, while maintaining demo sync
// under every conceivable circumstance, would double or triple code size, and
// would require maintenance of buggy legacy code which is only useful for old
// demos. Doom demos, which are more important IMO, are not affected by this
// change.
Right beneath that? [RH] - Randy Heit the tranny.
C++:
// [RH] On the other hand, since I've given up on trying to maintain demo
// sync between versions, these considerations aren't a big deal to me.
Not a big deal to ZDoom, the whole compatibility thing, by its own admission.
How do the Chocolate, Boom (PrBoom, dsda), or MBF (Nugget, Woof) ports all agree that they're playing the "same Doom", or the 2026 expanded version of "Vanilla Doom"? You play a .lmp recording in it, which is a series of inputs the player makes on every tic, and you get the same output. They all share the same random-number table, the one that came with Doom. They all use the same integer-based physics. They all store things in the same hard-coded tables.
How is MBF21 still "Vanilla Doom"? It can be implemented, to spec, in any engine, without breaking compatibility of the original game engine.