ZDoom backwards compatibility flamewar

Old demos would never works on ZDoom/GZDoom.
If you want, just using ChocolateDoom or PRBoom.

It DOESN'T work even you say 'developer doesn't care' and just let you looks like an *******. :p

The demo issue is not really because they don't care, but because maintaining demo compatibility with previous versions is simply impossible with ZDoom's development goals. New features are added, bugs are fixed, architecture is streamlined, all things that would break sync. If the code had to contain exception clause and in effect keep all previous iterations of the codebase behind if switches, it would be a massive headache, bloated, and impossible to maintain.

That's because you have no clue about the work being involved.

Maintaining demo compatibility is a major effort and highly counterproductive with extending the engine. It's no secret that this isn't the focus of ZDoom development. The engine wouldn't be where it is if we were to maintain demo compatibility.

Demo compatibility would mean that every single piece of code ever written has to be maintained, every bug preserved and every optimization optioned. It's just way too much work.

Yes, you might say that Eternity manages but on the other hand I wonder where Eternity might be today if Quasar had ditched demo compatibility early on.

So bitch all you want, it won't change. It's not about caring but about prioritizing one's time. Maintaining demo compatibility would mean that we'd have not much time doing anything else anymore.

Never_Again said:

Neither fraggle nor e6y have trouble maintaining their codebases while introducing new features, fixing bugs and streamlining the architecture.dysfunctional programming of the demo-related code of these ports.

ORLY?
Here, an example. Read e6y's posts.

>... so according to this, Boom, and all its derivatives, should support
walkover generalized crusher triggers.

Of course it should, but it does not. We cannot change history. We just
want to be a good compatible port.

>and how would it break compatibility ?
If you mean to fix it in new complevel, then it will not break
compatibility, because old prboom will not able to play new demos. And it
is already bad. Plus nobody should use "no complevel" mode. If you mean to
fix it with "complevel 9" (mostly using complevel for demo recording on
Boom levels) - it will never happen, because old prboom will not able to
play demos recorded by new prboom and vice versa

>No ... but you can fix past mistakes.

It is not prboom way. At least it is not my vision of prboom way. All such
doom/boom bugs should not be estimated as bugs at all. They are Doom's
quirks, they are Doom (Boom in case of this topic). In any case, I am sure
it will be fixed for 2.6.x for new demo version code, but I do not know
will it happen ever or not. Ask RjY :)

So, define "no troubles"; because it seems to mean "no troubles, we just won't do any of that stuff".

Here we have two different features: one is demo compatibility, another is working generalized crushers. They are incompatible. ZDoom's approach focuses on modding features and chooses to fix the bug; PrBoom+'s approach focuses on preserving demo compatibility and chooses not to fix the bug for the time being. It will be fixed eventually, but later, because to avoid ending up with ten gazillion complevels they want to wait to be sure to have caught up all existing bugs yet and fix them all at once, instead of fixing them as they crop up.

Neither approach is better or worse than the other. Both ports fill a different niche and the available variety can cater to everyone's whims. But asking ZDoom to preserve demo compatibility is as ridiculous as asking PrBoom to support ZDoom modding features.

The only way for zdoom is new demo format. "What you see is what you save" instead of "what you press is what you save". Prboom 2.3.x had such system (ViddSys), but I even do not know about completeness of this feature.

With the current state, demo support in zdoom can be dropped at all easily. It does not work even with the same version almost always I tried (RemainIII, Eternal IV Return From Oblivion). So, I do not try to record with zdoom anymore, even when I strongly need it.

entryway said:

The only way for zdoom is new demo format. "What you see is what you save" instead of "what you press is what you save". Prboom 2.3.x had such system (ViddSys), but I even do not know about completeness of this feature.

Such a demo recording method would be as useless because you'd have to save far too much stuff and worse, keep the system up to date with each change to the engine. It had been discussed several times on the ZDoom forum but each time the same conclusion was reached: Not worth it.

With the current state, demo support in zdoom can be dropped at all easily. It does not work even with the same version almost always I tried (RemainIII, Eternal IV Return From Oblivion). So, I do not try to record with zdoom anymore, even when I strongly need it.

Why don't you report it then? I know that demo sync bugs are very hard to find but if you know anything how to break a demo Randy and I need to know about it.

Graf Zahl said:

Why don't you report it then?

Just because of

I know that demo sync bugs are very hard to find

Still, if we don't know about them, we can't fix them. Of course knowing about them is no guarantee that they'll get fixed either.

Graf Zahl said:

Why don't you report it then?

Easily.

1. gzdoom -record 2
2. Take the chainsaw in your hands and kill all the monsters on the level.
3. Quit.
4. gzdoom -playdemo 2
5. Press <Win> key during movement.
6. Return to gzdoom with mouse.
7. Enjoy with desynch.

~10 years old bug :)

Never_Again said:

It doesn't concern me whether it changes or not. All I wanted was to get the record straight. I have no problem with (g)ZDoom but I have an allergy to BS.
diversifying the brand.

And I have an allergy to people who don't know much but think they know everything better. That'd be you in this case. :P

Prove me wrong and I'll be willing to listen to you. (Yeah, I know it won't happen...)

Never_Again said:

Neither fraggle nor e6y have trouble maintaining their codebases while introducing new features, fixing bugs and streamlining the architecture.

For what it's worth, I agree with Graf Zahl. Demo sync is really difficult to maintain, and the amount of effort that entryway and I have had to put into making our ports play Vanilla demos properly is far from trivial. In fact, the whole point is that Chocolate Doom/PrBoom(+) DON'T add lots of new features is what allows the demo compatibility that they have to be possible.

Vanilla demo compatibility is a nice thing to have, but it's not straightforward; it's very, very difficult. Even with the relatively small amount of features that PrBoom adds (compared to eg. ZDoom), if you look through the source code, you'll find it littered with demo compatibility checks. It certainly doesn't make for a very nice codebase this way, and I don't blame Randy or Graf Zahl for not wanting to have to maintain something like that. That kind of thing isn't part of the aims of (G)ZDoom, which (in my eyes) aims to expand the Doom source code in new ways by adding new features.

So it isn't "BS" as you say. There are plenty of source ports that let you watch Vanilla demos (including my own); if you want to watch a demo, use one of them. But it's not fair to criticize ZDoom for not supporting demos and it's certainly not easy to do. If you do want to criticize them in this way, please don't use my name to do it.

Never_Again said:

Those generalized walkover crusher Boom specials never worked in any Boom version, so for all practical purposes they do not exist and are de facto not part of Boom spec. That other ports choose to implement them is their prerogative. To paraphrase e6y, prBoom-plus does not engage in revisionism. It never makes you go "WTF? I just killed a Spider Mastermind with one BFG shot!" or marvel at how easy a level becomes because that corpse-on-a-stick decoration is blocking the Cyber's rockets. When you start prBoom-plus you know you're going to see DOOM, not somebody's idea-of-the-month-of-what-DOOM-could-have-been-had-it-been-released-today.

Well, it's great. You've established that you don't care fixing bugs or introducing new features (working generalized crushers falls in at least one of these categories), so ports that do that are not for you. The ports that you will be interested in include PrBoom and Chocolate Doom, maybe Eternity; but not ZDoom/GZDoom, Skulltag, Vavoom, etc. Diff'rent strokes and all that.

I could paraphrase you and dismiss faithful-to-the-original ports with snide comments like "it never makes you go "WTF? I just shot an SSG blast right through that demon and it didn't hurt it" or marvel how that imp three meters below you is preventing you from jumping down from your ledge" but wouldn't that be stupid and fallacious?

You should browse through PrBoom's or Eternity's code some day. Here's an excerpt from Eternity:

      if(demo_version >= 335)
         cmd->actions = *demo_p++;
      else
         cmd->actions = 0;

      if(demo_version >= 333)
      {
         cmd->look  =  *demo_p++;
         cmd->look |= (*demo_p++) << 8;
      }
      else if(demo_version >= 329)
      {
         // haleyjd: 329 and 331 store updownangle, but we can't use
         // it any longer. Demos recorded with mlook will desync, 
         // but ones without can still play with this here.
         ++demo_p;
         cmd->look = 0;
      }
      else
         cmd->look = 0;

See that? At least 335 levels for demo versions! All the ancient code kept around.
If it were ZDoom, this code fragment would be just that:

      cmd->actions = *demo_p++;

And note that even then, Eternity is not excessively concerned with demo compatibility. It's important, but not primordial. A demo from an old level with FraggleScript will be broken now, since FS was removed; and as the comments said an old demo with mlook won't work either.

Demo compat is a valuable feature and it's great that there are ports available that maintain it; but it's also a big burden on the code and it's also great that there are other ports that focus on other things.

That example is pretty tame, there are much more complex examples. PrBoom emulates bugs in Boom and MBF for example, so that demos recorded in those ports will still play back properly. Go look at p_spec.c and search for "comp". It's really a tribute to entryway (and the authors of PrBoom, MBF and Boom before him) that PrBoom+ plays back all those demos correctly. But I really don't blame Graf Zahl for not wanting to go to that effort; I don't think I would have the patience either. With Chocolate Doom, things are easier - at least I only have to maintain compatibility with one binary - Vanilla, and the behavior of the game is unchanged, so no conditional checks are necessary.

More to the point, this kind of backwards compatibility is something that is almost impossible to retrofit into an existing codebase. You can't just "add Vanilla demo playback" - it's something that has to be a design goal from the start and carefully preserved, always adding conditional checks to use the old behavior when playing an old demo. I dare say it would be almost impossible to add to ZDoom now.

fraggle said:

PrBoom emulates bugs in Boom and MBF for example, so that demos recorded in those ports will still play back properly.

PrBoom+ emulates bugs in PrBoom/+. If you recorded doom2 compatible demo with prboom and resulting demo is incompatible with doom2.exe, but incompatibility was fixed in next versions of prboom+ you are still able to watch incompatible compatible demo with "-emulate ver" command line switch, heh.

I'd *love* to *optionally* support blockmap and tracer clipping fixes in Eternity, but as Graf Zahl has mentioned before, doing it alongside compatibility retention is nigh impossible without incurring what is called "code explosion."

The branches or entire separate modules that would be needed would dirty up the code to the point where maintenance and modification would become a true horror.

Or at least that's how it seems so far. I am still toying with ideas at times.

I also agree with Graf on this one. G/Zdoom aren't ports for oldskoolerz, and vanilla demo comp would significantly increase zdoom's executable size.

On a side note, demo comp is completely unrelated to distance fading effects in hardware accelerated modes, so how the conversation flew from talking about emulating software effects to demo comp, I'll never know...

Same from the other side here:

I'd *love* to have demo compatibility. But the price would be too high.

SoM said:

On a side note, demo comp is completely unrelated to distance fading effects in hardware accelerated modes, so how the conversation flew from talking about emulating software effects to demo comp, I'll never know...

It happens on occasion...

Graf Zahl said:

That's because you have no clue about the work being involved.

Maintaining demo compatibility is a major effort and highly counterproductive with extending the engine. It's no secret that this isn't the focus of ZDoom development. The engine wouldn't be where it is if we were to maintain demo compatibility.

Demo compatibility would mean that every single piece of code ever written has to be maintained, every bug preserved and every optimization optioned. It's just way too much work.

Yes, you might say that Eternity manages but on the other hand I wonder where Eternity might be today if Quasar had ditched demo compatibility early on.

So bitch all you want, it won't change. It's not about caring but about prioritizing one's time. Maintaining demo compatibility would mean that we'd have not much time doing anything else anymore.

Most of this post explains why I gripe about Odamex being difficult to work on without busting some demo I've never heard of before that worked in some previous revision.

As a dev, it is such a major drain on my motivation because adding a feature/bugfix here breaks something there. :(

RTC_Marine said:

As a dev, it is such a major drain on my motivation because adding a feature/bugfix here breaks something there. :(

Yeah I don't really get why Odamex and Eternity bother with vanilla demo compatibility, seems like something you can never get 100% working, and there are other ports which do it much better (it is almost their raison d'etre).

Odamex has a client/server architecture, which means a better way of creating demos should be possible (storing the messages from server to client, a la the Quake engines).

andrewj said:

Yeah I don't really get why Odamex and Eternity bother with vanilla demo compatibility, seems like something you can never get 100% working, and there are other ports which do it much better (it is almost their raison d'etre).

Odamex has a client/server architecture, which means a better way of creating demos should be possible (storing the messages from server to client, a la the Quake engines).

I think we initially did it to get a close vanilla experience (at the moment, its close enough imo)

Network demos is in the pipeline

Eternity has high compatibility already and always has had it. To strip it out would be at least as much work as retaining it currently represents. Odamex on the other hand has tried to go from near-0 to decent compatibility, and that has been a difficult road from everything I've seen of the process.

Eternity is a highly compatible port because that's the kind of port I want to create and use. I love watching demos in EE.

Odamex having something that at least feels old school seems good enough to me -- I'm not sure that vanilla demo compatibility is really all that important in a multiplayer-focused engine in the first place.

Who would honestly expect (g)zdoom to have demo comp. Thats not what its for. Its like expecting microwaves to cook your thanksgiving dinner. You want demo comp, theres Pr+ and Chocolate Doom. You want glammer and scripts, theres (g)zdoom. Easy to remember.

For ZDoom demo compatibility - what if a "demo recording exe" was released that was intended to be used for recording ZDoom demos? When a new version of ZDoom is released and you want to record a demo, just use the "demo recording exe" so that people wouldn't have to download each version of ZDoom that was used to record each demo. You wouldn't have to update the "demo exe" so that compatibility wouldn't be broken. Sure, it wouldn't fix all the demos that have already been recorded, but if people started just using one version of ZDoom for recording (ex: a demo exe) then it would make recording/watching demos easier, right?

And what about new features?

Besides, this would have to be maintained the same as if the code were in the main program. So nothing gained, nothing lost.

New features could be added to the main program like usual, and if someone makes a map intended for demo recording they could design/test it with the demo exe - or if they want to use new features, they could just design it for the main program and tell people to record with the main program.

I dunno, I couldn't think of a better way to prevent demo incompatibility without the programmers doing way more work.

Would you have to maintain the code in a demo exe? I just figured you could release it and then just forget about it and let people use it if they wanted to record a demo, so that all demos would come from the same exe. If people complain about demo incompatibility, you could just say "use the demo exe" and "design your map for the demo exe".

TimeOfDeath said:

If people complain about demo incompatibility, you could just say "use the demo exe" and "design your map for the demo exe".

Already done. The "demo exe" is called prboom+.