Sooo, why doesnt GZDoom support replays? Or accurate compatibilities for that matter (closed: fatally consumed by derail that is not worth the time to prune)

[Flytrap]

Or comp level oddities like the wall running at 16:27 in decino's video https://www.youtube.com/watch?v=XFZFNE0a82w

 

 

[Gez]

GZDoom allows to make maps that are massively larger than vanilla limits, with 3D floors, portals, and tons of other effects. To make those things work, some bugs had to be fixed. Fixing these bugs led to wallrunning no longer existing.

 

Now we can always go talking about adding more compatibility options, more branching in the code so that the old bugs will still be there when wanted but that's more complexity, makes things harder to maintain, and increases the risk of seriously breaking modern maps (those that use GZDoom-exclusive features) for the sake of playing old maps (those that can be played in other ports like DSDA-Doom). Eventually, the question will end up boiling to "why isn't GZDoom actually DSDA-Doom?" and the answer will be "for the same reason that DSDA-Doom isn't actually GZDoom"...

[Flytrap]

2 hours ago, Gez said:

GZDoom allows to make maps that are massively larger than vanilla limits, with 3D floors, portals, and tons of other effects. To make those things work, some bugs had to be fixed. Fixing these bugs led to wallrunning no longer existing.

 

Now we can always go talking about adding more compatibility options, more branching in the code so that the old bugs will still be there when wanted but that's more complexity, makes things harder to maintain, and increases the risk of seriously breaking modern maps (those that use GZDoom-exclusive features) for the sake of playing old maps (those that can be played in other ports like DSDA-Doom). Eventually, the question will end up boiling to "why isn't GZDoom actually DSDA-Doom?" and the answer will be "for the same reason that DSDA-Doom isn't actually GZDoom"...

Okay, but for demo replayability you need 1:1 compatibility right? I think most ports support demos right out of the box, so, supporting it is a binary choice. Yes or no. So the few small things that are breaking demos on GZDoom, why cant they just be toggleable options like everything else?

They could just make it a one or the other thing. You have 'these' turned on, there you cant make your map larger than 'this'. Why wouldnt that work?

[Moustachio]

It would work, but unless you would like to write & bug-test those cases yourself, I don't think there's any interest in the community right now to add more compatibility settings to GZDoom. I certainly would love for GZDoom to have 1:1 vanilla compatibility for the sake of playtesting, but I think that falls way out of the scope of GZDoom's development focus. Since the base code is already very different from vanilla Doom's, it would be more work to add compatibility back in than to add new features to GZDoom.

[No-Man Baugh]

I do think it would be cool if GZDoom started to support cross-version demo compatibility (like you can't even record a demo in v4.11.0 and play it back in v4.11.1it just won't work), but it's clear that Demo support isn't in zdoom dev's interest right now, especially compared to mod compatibility. honestly I was surprised when I found out you can record and playback demos at all in GZDoom

 

As for supporting demos recorded in Vanilla, Boom, MBF? even I think that's a big ask, the ports that support demo playback are built from the start with the goal of perfect demo compatibility in mind, and even some Boom-based ports like Doom-Retro and Nugget-Doom nearly eschew that goal in favor of more features. So when you have a port as feature rich and fundamentally different as GZDoom: forget it

[LuciferSam86]

It's not in the project scope, I would say. There are other ports fitted for such thing. 

[Blzut3]

3 hours ago, No-Man Baugh said:

I do think it would be cool if GZDoom started to support cross-version demo compatibility (like you can't even record a demo in v4.11.0 and play it back in v4.11.1it just won't work), but it's clear that Demo support isn't in zdoom dev's interest right now, especially compared to mod compatibility. honestly I was surprised when I found out you can record and playback demos at all in GZDoom 

I think even the other GZDoom devs forget it's there, but demos actually can be useful for debugging from time to time.  Since it's literally just a recording of inputs if there's a bug that happens occasionally they can be used to reproduce it.  Also more or less demos and multiplayer are the same feature in GZDoom (and any other port that uses the traditional model for the net code).

[hobomaster22]

3 hours ago, Flytrap said:

Okay, but for demo replayability you need 1:1 compatibility right? I think most ports support demos right out of the box, so, supporting it is a binary choice. Yes or no. So the few small things that are breaking demos on GZDoom, why cant they just be toggleable options like everything else?

They could just make it a one or the other thing. You have 'these' turned on, there you cant make your map larger than 'this'. Why wouldnt that work? 

There a ton of reasons, but it's not technically feasible even if it was something the developers wanted to do. It switched from fixed point to doubles a long time ago and that alone is going to make the physics different enough to not match.

[D4NUK1]

GZDoom literally use a different code to make the physics and movement diferent to support stuff like mods, jumping and a lot more.

 

There's various threads with really good information about this topic, here on Doomworld and zoom forums, and even answer by devs why it's really out of the scope to make a demo compatible GZDoom with all the new changes.

 

 

Something possible would be a FORK of GZDoom that would be made for demos support, something that will need to change it's adapt the physics to translate the vainilla demo for the GZDoom Demo fork and hopefully maintain the necessary stuff, even throwing away GZDoom mods and many thing's more, I personally don't think the main devs would make this, but if a scene of devs make something like this they can be the change with a lot of trouble of how that will be made.

[Blzut3]

49 minutes ago, D4NUK1 said:

Something possible would be a FORK of GZDoom that would be made for demos support, something that will need to change it's adapt the physics to translate the vainilla demo for the GZDoom Demo fork and hopefully maintain the necessary stuff, even throwing away GZDoom mods and many thing's more, I personally don't think the main devs would make this, but if a scene of devs make something like this they can be the change with a lot of trouble of how that will be made.

One could even call it Eternity Engine or Odamex. :P

[Gez]

13 hours ago, Flytrap said:

Okay, but for demo replayability you need 1:1 compatibility right? I think most ports support demos right out of the box, so, supporting it is a binary choice. Yes or no. So the few small things that are breaking demos on GZDoom, why cant they just be toggleable options like everything else?

They could just make it a one or the other thing. You have 'these' turned on, there you cant make your map larger than 'this'. Why wouldnt that work?

GZDoom supports demos, it supports its own demos, and that's all.

 

In doing so, it carries the proud tradition of vanilla Doom, which is demo-incompatible across version -- try playing a 1.2 demo in 1.9, or vice-versa, if you don't believe me.

 

Anyways, those "small things" are not so small, such as changing from floating point maths back to fixed point maths...

 

One thing to consider is how setting changes can break maps. For example: in vanilla, any line with a special will block use. When you use the "use" action, the game actually fires a sort of short-ranged hitscan and looks at which line it crosses. As soon as it crosses a line with a special, it stops going further. It doesn't look at whether this is actually a "use" special or not. So if you have a line with a special in front of another line with a special, you cannot activate the second because you'll be stopped by the first. If the first is a scrolling texture and the second is a door, then you can't open the door. In Boom, this is fixed, the code actually checks whether the player can activate the special instead of just checking for the existence of a special.

 

Now, regularly, there are GZDoom bug reports about doors that don't work in such or such map and it turns out that the player was using "Doom" compat settings with a Boom or ZDoom map, and the change I describe above is why they had the "bug".

 

The more bugs and issues you reintroduce, the more spurious bug reports you'll have to deal with because people will keep forgetting they set compatibility to vanilla and are surprised their GZDoom map glitches like crazy.

[LexiMax]

19 hours ago, hobomaster22 said:

There a ton of reasons, but it's not technically feasible even if it was something the developers wanted to do. It switched from fixed point to doubles a long time ago and that alone is going to make the physics different enough to not match.

 

Even before then, there were enough physics differences between vanilla and ZDoom to cause issues.  There were even differences between different versions of ZDoom.

 

 

ZDoom's priorities are mod-ability and a reasonable amount of backwards compatibility, enough to pass the sniff test for the average player.  1:1 bug compatibility is not a goal, and in some cases not even desirable - especially when you start delving into some of the strangeness of complevel 9 and 11.

Edited October 15, 2023 by LexiMax

[Graf Zahl]

The ship for demo compatibility had sailed years before the very first GZDoom was even released. Even back then in 2005 the changes were already big enough to make going back impossible.

 

Even though to the uninitiated demo compatibility may look like a small thing it is not. Of all features it is the one that requires the most constant care and imposes the most restrictions on what you can change. Maintaining demo compatibility essentially means you cannot fix anything, and if you do you need to handle the original way as well. It means you cannot enhance certain aspects of the game that require changing in a way that cannot handle both methods. In Doom this even extends to the intermission screens which get controlled by in-game key input so if you make changes there, you cannot play multi-level demos.

 

[Shepardus]

If you want to support vanilla demos you'll need to replicate bugs like the one where things take blast damage multiple times due to the order of the blockmap list getting shuffled that are quite specific to the way it was implemented, not to mention all the other fun stuff in just that video alone, or other stuff like this weird quirk with the arch-vile that I'm not even going to try to describe, which is also dependent on line-of-sight checks working exactly the same, which is hard when all the coordinate stuff has been changed from fixed point to floating point. Good luck supporting all that while also maintaining compatibility with mods.

[Graf Zahl]

Or something like all the block iterators working on global variables which means they can stomp onto a previous instance if called recursively, which can actually happen with how Doom operates. But with DECORATE this became a serious stability issue and had to be addressed - I wonder how this may affect MBF21, which should have the same problem, but this time in ports which CANNOT fix it!

 

The list of such gotchas is endless.

 

[Flytrap]

22 hours ago, Graf Zahl said:

The ship for demo compatibility had sailed years before the very first GZDoom was even released. Even back then in 2005 the changes were already big enough to make going back impossible.

 

Even though to the uninitiated demo compatibility may look like a small thing it is not. Of all features it is the one that requires the most constant care and imposes the most restrictions on what you can change. Maintaining demo compatibility essentially means you cannot fix anything, and if you do you need to handle the original way as well. It means you cannot enhance certain aspects of the game that require changing in a way that cannot handle both methods. In Doom this even extends to the intermission screens which get controlled by in-game key input so if you make changes there, you cannot play multi-level demos.

 

Well, shit.

So, basically as time goes on the two halves of the community are going to drift further apart?

The halves of 'it has to be 1:1 with vanilla' and the 'im going to take the doom engine's concept and push it to max'

[Shepardus]

11 minutes ago, Flytrap said:

Well, shit.

So, basically as time goes on the two halves of the community are going to drift further apart?

The halves of 'it has to be 1:1 with vanilla' and the 'im going to take the doom engine's concept and push it to max'

Not really, if anything stuff like MBF21 has bridged the gap somewhat.

[Flytrap]

Just now, Shepardus said:

Not really, if anything stuff like MBF21 has bridged the gap somewhat.

How does MBF 21 compare in relation to the other common ones like normal MBF, Boom, vanilla?

[DeetOpianSky]

It would seem DSDA is moving toward supporting GZDOOM maps to some extent with the implementation and future expansion of UDMF support.

Though they would obviously play differently for the reasons described throughout the thread demos may well be possible.

Does anyone know if VKDOOM is looking at demo compatibility workarounds in it's roadmap?

[plums]

3 minutes ago, Flytrap said:

How does MBF 21 compare in relation to the other common ones like normal MBF, Boom, vanilla?

Check out what @MObreck is doing with MBF21's Dehacked:

 

 

You can't do special 3D geometry with MBF21, and it's certainly not as flexible as DECORATE (much less ZScript), but it's definitely possible to make new enemies etc. far beyond what you could with Boom. DSDA is also working on supporting *some* features of UDMF maps, though I have no idea what the scope of that endeavour is.

 

Another thing bridging the gap is that it's much more feasible to speedrun GZDoom etc. maps the way you would any other game on youtube/twitch/etc. than it was 10 years ago -- see myhouse.wad speedruns. It is kind of a different ethos to speed demos especially for something like myhouse which had a big impact outside of the normal Doom community, but if someone was really interested in speedrunning whatever GZDoom map they really liked, they have other avenues than just making a demo. Map playtesting/commentary seems much more commonly done through streaming than FDAs (demos) etc. these days.

[Dark Pulse]

1 hour ago, Flytrap said:

Well, shit.

So, basically as time goes on the two halves of the community are going to drift further apart?

The halves of 'it has to be 1:1 with vanilla' and the 'im going to take the doom engine's concept and push it to max'

It's basically a tradeoff no matter how you slice it. If you want vanilla accuracy, you cannot have flexibility. If you want flexibility, you cannot have vanilla accuracy.

 

You could have something that gets you most of the way there (and that's exactly what GZDoom does), but 1:1 compatibility is simply impossible without imposing a lot of things - various engine bugs and quirks, using the same sort of calculations the original game did, etc. All a demo file really is, after all, is a log of keypresses per engine tic; the fact enemies do the same moves and actions is achieved not by logging that information in the demo file, but by starting the game from an absolute fixed state whenever a demo is recorded. There is thus no need to keep track of enemy movement, health, etc. because the RNG rolls (another thing you'd have to keep for 1:1 demo compatibility - vanilla has a pseudorandom RNG table while GZDoom will roll true RNG) would be exactly the same if the exact same action was done on the exact same tic.

 

Mind you, this only matters for the most part if you want to record a demo that can be played back on the original executable or something like Chocolate Doom. Other source ports could have different demo formats that are a bit more robust, but the same basic thing applies: Eventually there's enough updates that you just can't support the older files anymore.

 

It's not like a modern game engine where all that information is stored in the demo file itself. A vanilla Doom demo is literally "Okay, let's start the level tic counter at zero and the RNG Table at the first entry, start recording keypresses!" That's literally it. It's basically a gigantic hack.

 

Even between different versions of the vanilla engine, the demo will screw up - an easy-to-demonstrate example is if you have Heretic. The demos were recorded with the original 1.0 executable, and were never updated, replaced, or re-recorded during the game's release history. Quoth the wiki:

Quote

[T]wo of them go out of sync in version 1.2 as well as Shadow of the Serpent Riders. The first demo makes it to the crossbow and begins shooting at a torch before being slashed to death by Sabreclaws. The third demo goes out of sync almost immediately, the player starts running into walls, shooting at the ceiling and never leaves the starting room.

 

Edited October 16, 2023 by Dark Pulse

[Professor Hastig]

9 hours ago, Flytrap said:

Well, shit.

So, basically as time goes on the two halves of the community are going to drift further apart?

The halves of 'it has to be 1:1 with vanilla' and the 'im going to take the doom engine's concept and push it to max' 

 

No. I wouldn't say that.

Yes, there are a few people constantly repeating nonsense as if GZDoom is essentially an engine that 'also plays Doom', nothing could be further from the truth.

Yes, it has changed a lot, but the core is still the same movement logic, the same approach to rendering and even extensive support of common render hacks used in vanilla maps.

 

It is unfortunate that demo compatibility has become some gold standard ports are expected to adhere to. The result of this is that we have a large group of ports that barely manage to distinguish themselves from each other outside of superficialities, and a handful of outliers that are more daring.

 

Look at the inflation of demo compatible ports and then examine where they try to distinguish themselves. Eternity is the only one of these which has somewhat broken the boundaries of these strict confines, but it had to pay the price of somewhat high code duplication to retain the original vanilla logic and also make the needed changes for portal support etc.

On the other side, the ZDoom family has virtually been the only game in town for extended feature sets. Other ports came and went but none managed to break through, mainly because the developers eventually lost interest before they were mature enough to compete. Helion is virtually the first port in a long time that tries to break new ground with its radical render overhaul to focus on performance.

[Flytrap]

On 10/17/2023 at 7:37 AM, Professor Hastig said:

 

No. I wouldn't say that.

Yes, there are a few people constantly repeating nonsense as if GZDoom is essentially an engine that 'also plays Doom', nothing could be further from the truth.

Yes, it has changed a lot, but the core is still the same movement logic, the same approach to rendering and even extensive support of common render hacks used in vanilla maps.

 

It is unfortunate that demo compatibility has become some gold standard ports are expected to adhere to. The result of this is that we have a large group of ports that barely manage to distinguish themselves from each other outside of superficialities, and a handful of outliers that are more daring.

 

Look at the inflation of demo compatible ports and then examine where they try to distinguish themselves. Eternity is the only one of these which has somewhat broken the boundaries of these strict confines, but it had to pay the price of somewhat high code duplication to retain the original vanilla logic and also make the needed changes for portal support etc.

On the other side, the ZDoom family has virtually been the only game in town for extended feature sets. Other ports came and went but none managed to break through, mainly because the developers eventually lost interest before they were mature enough to compete. Helion is virtually the first port in a long time that tries to break new ground with its radical render overhaul to focus on performance.

Okay, i did give Helion a look and those performance numbers are IMPRESSIVE! I am deffinitely giving it a try!

[banjiepixel]

On 10/17/2023 at 8:37 AM, Professor Hastig said:

Yes, there are a few people constantly repeating nonsense as if GZDoom is essentially an engine that 'also plays Doom', nothing could be further from the truth.

Yes, it has changed a lot, but the core is still the same movement logic, the same approach to rendering and even extensive support of common render hacks used in vanilla maps.

 

Technically GZDoom is closer to being more of a Hexen engine with tons of original upgrades. It's all very "ship of Theseus"-like situation as GZDoom is still based on Doom code but the limitations of the original code have been broken to the point of the actual original Doom features becoming just very small part of the whole package.

 

On 10/17/2023 at 8:37 AM, Professor Hastig said:

It is unfortunate that demo compatibility has become some gold standard ports are expected to adhere to. The result of this is that we have a large group of ports that barely manage to distinguish themselves from each other outside of superficialities, and a handful of outliers that are more daring.

 

Demo compatibility isn't limiting innovation like you seem to think. It is the general trend for source ports to be demo compatible but even just for the source port having a stable demo support with itself would go a long way. People don't like new versions of source port breaking things made with previous version, this has been the biggest issue with GZDoom, both with the demos and even with many mods, old stuff can get so easily broken.

 

On 10/17/2023 at 8:37 AM, Professor Hastig said:

On the other side, the ZDoom family has virtually been the only game in town for extended feature sets. Other ports came and went but none managed to break through, mainly because the developers eventually lost interest before they were mature enough to compete. Helion is virtually the first port in a long time that tries to break new ground with its radical render overhaul to focus on performance.

 

The thing is that how much there is actual need or demand for extended feature sets outside of ZDoom forks? Advanced stuff made for ZDoom family are popilar but between that and more classic players that do care about demo compatibility, there exists a very small niche audience. That is true reason why we get the bleeding edge innovation of ZDoom based ports and very minor innovation of more classc style ports but there is the big gap of almost nothing happening between.

 

It is hard for developers to keep their interest when either GZDoom or DSDA-Doom can cover already almost every Doom playing or mapping need a person can have. Most popular type of source port outside of those 2 are literally more retro focused ports and for exampie, something like Doom Retro doesn't even have demo compatibility yet also seems to be decently popular and was even included in Delta Touch.

[Edward850]

On 10/17/2023 at 6:37 PM, Professor Hastig said:

Eternity is the only one of these which has somewhat broken the boundaries of these strict confines, but it had to pay the price of somewhat high code duplication to retain the original vanilla logic and also make the needed changes for portal support etc. 

Don't believe everything GZDoom developers overemphasize. All things considered the duplication needed is relatively minor, and the portal code didn't really conflict with this at all. You do need to be careful and pay attention to what you're updating, but it's not like Eternity has two duplicated blockmap routines or anything like that.

[baja blast rd.]

On 10/16/2023 at 4:11 PM, Flytrap said:

Well, shit.

So, basically as time goes on the two halves of the community are going to drift further apart?

The halves of 'it has to be 1:1 with vanilla' and the 'im going to take the doom engine's concept and push it to max'

 

No because those aren't real categories; it breaks down very nuancedly, more like several groups rather than two halves. Even if you do simplify it into two, those groups aren't an accurate simplification either (lots of classic port players don't insist on 1:1 vanilla behavior otherwise deh and mbf21 wouldn't be so popular; and lots of GZDoom players are very conservative and aren't trying to push stuff to the 'max', with some even circling around to vanilla-like preferences). Additionally, some people also belong to multiple groups because not everyone has one playstyle.

[Professor Hastig]

4 hours ago, banjiepixel said:

 

Technically GZDoom is closer to being more of a Hexen engine with tons of original upgrades. It's all very "ship of Theseus"-like situation as GZDoom is still based on Doom code but the limitations of the original code have been broken to the point of the actual original Doom features becoming just very small part of the whole package. 

 

That "very small part of the whole package" is the core of the engine. Yes, numerically it is small but in terms of importance it's what still defines the engine.

 

 

4 hours ago, banjiepixel said:

 

Demo compatibility isn't limiting innovation like you seem to think. It is the general trend for source ports to be demo compatible but even just for the source port having a stable demo support with itself would go a long way. People don't like new versions of source port breaking things made with previous version, this has been the biggest issue with GZDoom, both with the demos and even with many mods, old stuff can get so easily broken.

 

I think it does, because the 'innovation' of demo compatible ports is inevitably a lot more limited. And if it is just some weird thing as not changing the monster kill counter because demo sync of the intermission screen depends on it.

Of course you are correct with things breaking being a problem, but that's an inevitable reality in all software development, even with the greatest care something can go wrong or some seemingly benign change can have some catastrophic butterfly effect because people unknowingly depend on some quirk without even realizing it. That goes especially for hobbyist projects that do not have a QA department to catch most problems early.

 

 

4 hours ago, banjiepixel said:

 

The thing is that how much there is actual need or demand for extended feature sets outside of ZDoom forks? Advanced stuff made for ZDoom family are popilar but between that and more classic players that do care about demo compatibility, there exists a very small niche audience. That is true reason why we get the bleeding edge innovation of ZDoom based ports and very minor innovation of more classc style ports but there is the big gap of almost nothing happening between.

 

That's not the issue. The issue is that due to the perceived importance of demo compatibility only few people try these days.

 

3 hours ago, Edward850 said:

Don't believe everything GZDoom developers overemphasize. All things considered the duplication needed is relatively minor, and the portal code didn't really conflict with this at all. You do need to be careful and pay attention to what you're updating, but it's not like Eternity has two duplicated blockmap routines or anything like that.

 

It does duplicate the core collision functions, doesn't it? This is actually the very core of what makes Doom the game it is, as I mentioned above already.

 

[Edward850]

47 minutes ago, Professor Hastig said:

It does duplicate the core collision functions, doesn't it? This is actually the very core of what makes Doom the game it is, as I mentioned above already.

It's a bit of an abstract question, what do you define as core? But nothing I know of is really changed there. There's the added logic to handle portals, but that's only situational to portals.

[banjiepixel]

13 minutes ago, Professor Hastig said:

That "very small part of the whole package" is the core of the engine. Yes, numerically it is small but in terms of importance it's what still defines the engine.

 

GZDoom could be said to be several generations apart from the original Doom engine. It is mainly just a semantic issue but GZDoom is more of advanced Hexen engine with a Doom support than an actual Doom engine. Same executable runs Hexen, Heretic and Doom so GZDoom is more of a Hexen engine with backwards compatibility with Doom, especially since alot of it's defining advanced features are based on Hexen. Definitely still based on Doom but more closely connected to the Hexen engine than Doom. It's not meant to be negative thing that GZDoom defined to be different engine with Doom support, it is just more accurate and useful way to define things.

 

41 minutes ago, Professor Hastig said:

That's not the issue. The issue is that due to the perceived importance of demo compatibility only few people try these days.

 

Doom Retro seems decently popular without having demo compatibility, especially for a retro focused source port. It's less about demo compatibility being that important and more about most demo breaking source ports lacking killer features that would make them worth using despite not having demo compatibility. And again, why attempt making a new source port with more advanced features when GZDoom or other ZDoom based source ports are good enough for 99% of your demo support breaking needs? But guess it must those darn purists demanding demo compatibilty and killing any source port project that dares to break demo support for the sake of innovation and new features.

 

And GZDoom does owe alot of it's popularity to it's biggest killer app, Brutal Doom, and that was all about great accidental timing, something similar happening with other boundary breaking source ports is extremely unlikely, especially closer to classic gameplay style side of the Doom souirce port spectrum.

[Blzut3]

14 minutes ago, banjiepixel said:

And GZDoom does owe alot of it's popularity to it's biggest killer app, Brutal Doom, and that was all about great accidental timing, something similar happening with other boundary breaking source ports is extremely unlikely, especially closer to classic gameplay style side of the Doom souirce port spectrum.

I feel like this statement, while perhaps by raw number of users is true, ignores that (G)ZDoom was already in its position for somewhere around 5 years prior to Brutal Doom existing.  Most of the competition just dried up around 2005.  Conveniently also the year that Chocolate Doom came out, which I personally feel is also when the opinions on hard core vanilla compat shifted (which isn't to say there weren't people that cared the whole time, I just don't recall it being a big deal when I joined the community in 2003).