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)

[Graf Zahl]

1 hour ago, banjiepixel said:

The implication is pretty heavily that no one should be playing Doom like it was in 1993, and by extension, this comes with implication of there being something wrong with other old games being played in their original or era accurate form. You know, that pretty typical GZDoom user attitude.

 

Considering that half of your posts are preaching the gospel of vanilla Doom itÄs not really surprising that you see the same annoying attitude when others just state their preference.

 

1 hour ago, ebrl said:

Anyway. GZDoom sets out to fix absolutely everything it thinks need fixing, at the cost of straying away from the original Doom engine in matters both big and small. It is its own engine and it can do pretty much anything, including running Doom wads not designed for GZDoom to a degree of accuracy that's acceptable enough for most people. It is not compatible with anything except itself and it is a price it was always willing to pay - a price that is now basically irrelevant anyway given its position as, I assume, the most popular way to play Doom today by an overwhelming margin. I really don't understand why some GZDoom fans get so defensive, treating this as some sort of fight, given that if it was a fight, it would be one that they won comfortably ages ago.

 

There we go again with posting alternative facts as long as they support your narrative. :(

 

[LexiMax]

And this is why arguing over things that are preference based is useless.  Not only are they non-falsifiable, but they derail conversations into a ditch, because people just keep responding to the preference flame-war.

 

Besides, there are actual problems that are worth solving that go beyond mere personal preference.  For example, it's kind of silly that KDIKDIZD needs to resort to hacks like this to communicate issues with certain settings.

 

Edited October 19, 2023 by LexiMax

[Graf Zahl]

How would you solve this? I consider blocking the hardware renderer not an acceptable option for anything, even if some mod goes out of its way trying to enforce it.

 

 

[Individualised]

Is this our "let's shit on GZDoom" thread for the month? Aren't you all bored of this now?

 

A lot of the discussion in these threads seems to be intentionally antagonistic. There may as well just be a "GZDoom Feedback/Criticism" thread now.

Edited October 19, 2023 by Individualised

[LexiMax]

9 minutes ago, Individualised said:

Is this our "let's shit on GZDoom" thread for the month? So many words being put in other people's mouths, even by well respected community members. I'm disappointed. Aren't you all bored of this now?

 

There's a disappointing lack of nuance and de-escalation in this thread, and quite frankly you're not being particularly helpful on this front by throwing blame at one particular side of this conversation.

Edited October 19, 2023 by LexiMax

[Edward850]

15 minutes ago, Graf Zahl said:

How would you solve this? I consider blocking the hardware renderer not an acceptable option for anything, even if some mod goes out of its way trying to enforce it.

 

 

Why is the default assumption the most extreme? No all you'd need to do is either have the hardware render use the software palette and colourmapping in such scenarios that require custom colour mapping.

Or just handle fullbright automation differently, as that's all that particular scenario needs.

[Jayextee]

Unfortunately, that's how these things go. I use GZDoom, it's fine. It does play DOOM, and was easy to set up. I've a shortcut setup so I can right-click any WAD and send it right to GZD. It's good like that. And actually a safe default.

 

On the other hand, I'm apparently one of these 'vanilla purist' stawpeople because if I can run a thing in Chocolate DOOM then I absolutely will, and even my limit-removing sourceport of choice is prBOOM+ @35fps running in a mere 640x480. I do not really like the way DOOM looks in high resolution.

There's nuance. Which side of the fence gonna come at me for it? ;P

[hobomaster22]

25 minutes ago, LexiMax said:

And this is why arguing over things that are preference based is useless.  Not only are they non-falsifiable, but they derail conversations into a ditch, because people just keep responding to the preference flame-war.

 

Besides, there are actual problems that are worth solving that go beyond mere personal preference.  For example, it's kind of silly that KDIKDIZD needs to resort to hacks like this to communicate issues with certain settings.

To be fair KDIKDIZD is a gigantic pile of hacks and is a pretty extreme edge case.

[dasho]

32 minutes ago, LexiMax said:

 

Just run through it backwards omg

[Dark Pulse]

2 hours ago, LexiMax said:

 

I think our company did a fine job on the 2021 Quake remaster.  It comes with updated models, smooth animations and even new sets of levels that would be impossible on 1996 hardware.

 

Guess what kind of texture filtering it defaults to.

 

Yeah, this wasn't a knock at you guys at all (personally I can't stand Quake without smoothed model animations). It's me saying that unless one is going to take a absolute purist approach with no improvements at all, making an argument of "there is a way it was intended to be experienced" is silly, especially once you get up to stuff like Quake, and it was directed at banjiepixel's assertion, not intended to be a criticism of the remaster. I mean, if we really got into the weeds of it, Chocolate Doom isn't purist either, thanks to stuff like that magnified screen resolution, reliance on SDL, and so forth.

 

For example, in terms of Quake, which is the "true" experience - the original DOS executable? WinQuake? Quakeworld? GLQuake? Different people would say all of these options. By a purist logic, 75% of them are automatically wrong.

 

One can make an argument that this way or that way is right, but to me, whatever makes the game enjoyable for you is the right way to play. Even if that means high-rez texture packs and 3D models.

[Individualised]

20 hours ago, LexiMax said:

 

There's a disappointing lack of nuance and de-escalation in this thread, and quite frankly you're not being particularly helpful on this front by throwing blame at one particular side of this conversation.

I actually agree. I posted that in frustration. I apologise.

Edited October 20, 2023 by Individualised

[Graf Zahl]

1 minute ago, Dark Pulse said:

For example, in terms of Quake, which is the "true" experience - the original DOS executable? WinQuake? Quakeworld? GLQuake? Different people would say all of these options. By a purist logic, 75% of them are automatically wrong.

 

That's a very important question.

My experience with the original software renderer was quite frustrating.

Back in 1997 when I got Quake I had to play it in 320x200 with some screen borders to get enough performance to have a smooth frame rate. It was not fun and I didn't play far.

That changed when I got my Voodoo card half a year later. Suddenly I was able to play the game at smooth frame rates with a much higher screen resolution, and it was infinitely more fun playing it that way.

 

 

[Flytrap]

I like GZDOOM. Its my port of choice, mostly because of the really great mouselook, but i just wish they'd turn off the texture filtering by default. if they wanna play like that i dont care, but it being a default setting is the biggest problem with the engine.

The reason i even wanted demo support is because having pre-recorded demos play in the background when i load a wad and fiddle with the settings is really cool. I am not actually going to record demos myself.

 

I tried helion, the performance is very impressive, but i cant live without being able to change options in game.
I tried eternity as suggested by @TheHambourgeois but because im a mouselook player i cant really use that. It feels extremely weird and disorientating to use mouselook on eternity.

I tried other engines aswell but i cant recall them right now off the top of my head

[No-Man Baugh]

@Flytrap Have you tried Odamex? it's mainly a multiplayer port, but it's also a pretty good candidate for some conservative vanilla/boom/mbf fun complete with demo playback on the title screen

 

It's based off of ZDoom (late 90's ZDoom v1.22 fwiw) but aims closer to a PRBoom or Woof with it's mod support, but has software rendering only, I hope the distortions caused by vertical mouselook isn't what put you off of eternity

[ebrl]

1 hour ago, hobomaster22 said:

To be fair KDIKDIZD is a gigantic pile of hacks and is a pretty extreme edge case.

Even more than an edge case, KDIKDIZD is the definition of "vanilla as a mapping flex".

[banjiepixel]

8 minutes ago, Graf Zahl said:

Considering that half of your posts are preaching the gospel of vanilla Doom itÄs not really surprising that you see the same annoying attitude when others just state their preference.

 

How is simply trying to correct misconceptions of GZDoom users preaching gospel of vanilla Doom? You do seem to be projecting pretty hard, just like some other GZDoom people here. I simply stated what your implication seemed to be. It definitely could had been by accident but as a person with your level of status here, you really should be more careful with your words.

 

5 minutes ago, Dark Pulse said:

It's me saying that unless one is going to take a absolute purist approach with no improvements at all, making an argument of "there is a way it was intended to be experienced" is silly, especially once you get up to stuff like Quake, and it was directed at banjiepixel's assertion, not intended to be a criticism of the remaster. I mean, if we really got into the weeds of it, Chocolate Doom isn't purist either, thanks to stuff like that magnified screen resolution, reliance on SDL, and so forth.

 

First thing you did was strip all the nuance from my assertion. Maybe what I said for little bit too high concept for people here but point was that diffrent ways to play Doom lead to different experiences and optionally the way we play matches the content we play and creator intend as close as possible. Basically you can use hammer on a screw but the end result will be different compared to using hammer on nail or screwdriver on a screw. Strict purism was never the point.

 

28 minutes ago, Dark Pulse said:

For example, in terms of Quake, which is the "true" experience - the original DOS executable? WinQuake? Quakeworld? GLQuake? Different people would say all of these options. By a purist logic, 75% of them are automatically wrong.

 

Technically all official versions are automatically the "correct" version, and that is with using purist logic. Things actually only get more complicated when unofficial stuff enter the picture. But then again, there is no wrong way to play. But ideally the way we play does imitate a official release and follows creator intend as closely as possible. Playing boardgames with house rules is perfectly fine but straying from official and recommended rules can lead to very different unintended results. It is more appropriate to play by the official rules because they are the more tested and refined experience.

 

One great thing about demo compatibility is that it can be used pretty easily to comfirm that the engine can technically follow the official rules with perfect or atleast very high accuracy. This makes it very highly appropriate that a demo compatible engine is used to play a community made map that was designed for the official ruleset.

 

That is the last thing I am going to say about that and I hope I made what I actually meant finally clear.

 

But back to the topic, I have been wondering for some time why GZDoom doesn't have a stripped demo compatibility mode, basically what I mean is that engine would temporarily disable every demo breaking feature so atleast the default IWAD demos could play in the main menu background like in the original games. I also would prefer the vanilla demos to play in the main menu background even if they would desync instantly. I would assume that the support for vanilla demo format is still there and the playpack is just blocked because many variables are different and vanilla demos will obviously desync instantly.

[LexiMax]

4 hours ago, Dark Pulse said:

Yeah, this wasn't a knock at you guys at all

 

To be clear, no offense was taken.  I was attempting to point out by example that it is indeed a spectrum, not a binary, and that texture filtering is not an obvious improvement for assets of Doom and Quake's provenance in the same way that things like widescreen support and higher framerates are.

 

If you prefer filtering, that's a valid preference.  But I think it's a bad default.

Edited October 20, 2023 by LexiMax

[coderamen]

30 minutes ago, LexiMax said:

 

To be clear, no offense was taken.  I was attempting to point out that it is indeed a spectrum, not a binary, and that texture filtering is not an obvious improvement for assets of Doom and Quake's provenance in the same way that things like widescreen support and higher framerates are.

 

If you prefer filtering, that's a valid preference.  But I think it's a bad default.

Based. Also, I have a question for you, esteemed madam. What is everything you have worked on doon-wise?

[Dark Pulse]

2 hours ago, banjiepixel said:

First thing you did was strip all the nuance from my assertion. Maybe what I said for little bit too high concept for people here but point was that diffrent ways to play Doom lead to different experiences and optionally the way we play matches the content we play and creator intend as close as possible. Basically you can use hammer on a screw but the end result will be different compared to using hammer on nail or screwdriver on a screw. Strict purism was never the point.

Okay, you once more mention the "creator intent" again. But that is not what GZDoom is about, it is about expanding beyond what the creator intended, so in that sense, one is barking up the wrong tree if they are expecting that. It's an engine that can play games made for the Doom engine, but its primary purpose is to do more than just that. In a sense, the fact it can play those games is somewhat more of a "it can also do this."

 

If you want something close to vanilla, simply put, you don't play GZDoom, you play something like Chocolate Doom if you really want things close, or if you want something a little more expanded, PrBoom or something based off that. But even those will have some differences, and not just under the hood, but rendering as well.

 

We are no longer in an era where the CPU renders the game scene in software; we really haven't been doing that for easily 25 years now, and the last game I can specifically remember that had software rendering even as an option (and it was an addon, not the default) was UT2003/UT2004's Pixomatic Renderer. Everything nowadays is assuming hardware acceleration (even the internet - WebGL!), and that means that how it is experienced can differ. Furthermore, once we hit the 2000s, games would start having multiple rendering paths - DirectX was the standard for years on Windows, OpenGL was often also supported and occasionally the main renderer, and nowadays Vulkan is definitely upending things. Each of those could render the scene with subtle differences - ideally they don't, but in practice, the pipeline does vary, and the only true way to be 100% sure what you put in is what you get out is to renderer it in software (hence why MAME, for example, isn't hardware-accelerated).

 

So basically, "as the creator intended" sailed a long time ago - long before GZDoom, in fact, considering ZDoom was doing all this (and indeed, rendered in 8-bit software!) back in the early 2000s. The engine has simply diverged, and it is no longer in a state where it would be vanilla-compatible enough to run demos. It hasn't been since... well, ever, as far as I know.

 

2 hours ago, banjiepixel said:

Technically all official versions are automatically the "correct" version, and that is with using purist logic. Things actually only get more complicated when unofficial stuff enter the picture. But then again, there is no wrong way to play. But ideally the way we play does imitate a official release and follows creator intend as closely as possible. Playing boardgames with house rules is perfectly fine but straying from official and recommended rules can lead to very different unintended results. It is more appropriate to play by the official rules because they are the more tested and refined experience.

 

One great thing about demo compatibility is that it can be used pretty easily to comfirm that the engine can technically follow the official rules with perfect or atleast very high accuracy. This makes it very highly appropriate that a demo compatible engine is used to play a community made map that was designed for the official ruleset.

 

That is the last thing I am going to say about that and I hope I made what I actually meant finally clear.

Then... GZDoom does that just fine. You can play those games in them, you can beat those games with them, and you can turn off the bells and whistles like SSAO or texture filtering. I believe the only thing you can't do is to make it run in 320x200 (well, maybe in a window), although given that would be quite small on a 1080p monitor, much less a 1440p or 4K one, a scale just might have to be acceptable.

 

The simple fact is that most casual players can't even tell that anything changed. They have no idea about wallrunning or thingrunning (GZDoom has compatibility options to re-enable stuff like this). They have no idea about the various bugs and quirks of the engine. Unless you know things on a deeply technical level, deeper than most people do, the simple fact is that GZDoom... plays Doom, and plays it just fine.

 

By that logic, if you can do 95% of what the original game did and not notice a difference, you are very much playing it "by the creator intent." Especially when most of that remaining 5% is still stuff you can manually toggle if you really need to get closer.

 

2 hours ago, banjiepixel said:

But back to the topic, I have been wondering for some time why GZDoom doesn't have a stripped demo compatibility mode, basically what I mean is that engine would temporarily disable every demo breaking feature so atleast the default IWAD demos could play in the main menu background like in the original games. I also would prefer the vanilla demos to play in the main menu background even if they would desync instantly. I would assume that the support for vanilla demo format is still there and the playpack is just blocked because many variables are different and vanilla demos will obviously desync instantly.

Because some of the changes are fundamental. For example, the vanilla engine, coordinates are fixed-point, where a 32-bit value is split into a 16-digit integer and a 16-bit fraction. Thus, the vanilla engine can only express values between -32767 and 32768, inclusive, with up to 16 digits of a fraction - but anything that is outside of those literally cannot be possible.

 

This fixed point coordinate system, for example, is also why slime trails happen in the original engine:

Quote

Within the map, vertex coordinates are only stored as integers. In normal map editing, vertices may only be placed at integer coordinates. During BSP building, however, lines may need to be split into segs at a location that has non-integral coordinates. The BSP builder ends up having to chop a significant amount of precision out of the coordinates of its generated vertices, and as a result, segs may end or begin far short of where they need to be placed for a mathematically correct BSP. This results in an open subsector, and the flat of the subsector will bleed out at the location of the offending vertex.

The only way this would be solvable would be if you could make vertexes placed on fractions of a unit, but the original engine does not allow that. If you change it (as GZDoom has, moving to floating point coordinates), you just broke demo compatibility, because you changed a fundamental, underlying assumption of the engine - movement now completely differs, so the old assumptions no longer work properly. Hardware rendering also solves this as a simple fact of necessity (all polygons must be closed for a valid hardware renderer to even work), but of course, that is also away from what the original game did.

 

As I said earlier, demos in Doom are really a very ugly hack. Basically, they only work because the vanilla engine does the following whenever a demo is recorded or played back:

• Set the game tic counter to 0. This will affect things like Revenant tracers, which choose which firing mode happens based upon if the tic in which it is fired is odd or even.
• Set the RNG table to start at its first entry. RNG calls naturally happen a bunch, both from the player, the monsters, and the level itself (light blinking, etc.).
• If recording, start storing keypresses; if playing back, play back the stored keypresses from the demo LMP.

That's it. That's all demos are - a series of keypresses (and it can't even record every possible input - accessing the menu is a 100% surefire way to cause a desync, for example). Enemies only move the exact same way and do the exact same actions, damage rolls happen the exact same way, and anything that is RNG-based happens identically only because the engine starts from a fixed state every time you record or playback a demo. Indeed, the demo doesn't store information about what enemies do, what projectiles are active, or the level state at all! They do store some info (game version, episode/map, skill level, if the game is multiplayer or not, some parameters like -fast, -respawn, or -nomonsters), but otherwise all a demo in Doom is, is literally a keypress log that the engine plays back.

 

This is why it's not really possible to "temporarily disable every feature." The underlying engine is fundamentally different, and demos are literally just a keypress log. If everything is not EXACTLY the same - and they wouldn't be (for example, the aforementioned change to floating point coordinates, or the fact that GZDoom no longer uses an RNG table of any sort) - the demo will simply not work right. Graf decided that's simply not a priority he wishes to pursue or deal with since that would force him to not be able to do other features he would like to do, but other engines can and do indeed do that.

 

49 minutes ago, LexiMax said:

To be clear, no offense was taken.  I was attempting to point out that it is indeed a spectrum, not a binary, and that texture filtering is not an obvious improvement for assets of Doom and Quake's provenance in the same way that things like widescreen support and higher framerates are.

 

If you prefer filtering, there's nothing wrong with that.  But I do think it's bad as a default setting.

Personally, I agree, but Graf does not. And considering that there ARE plenty of people who would otherwise complain about Doom's blocky, pixelated graphics, it's kind of a "damned if you do, damned if you don't" scenario. Turn it off and you please the purists but then people less used to such old games will complain it looks like crap. Turn it on and generally those people will not notice that nearly as much, but older fans may start screaming it's sacrilege.

 

There is no one setting that will please everyone out of the gate, but thankfully, it's a relatively short hop, skip, and jump to set it to whatever filter your heart desires, or turn it off completely.

[Edward850]

38 minutes ago, coderamen said:

Also, I have a question for you, esteemed madam. What is everything you have worked on doon-wise?

A helpful Doomwiki page reveals all. https://doomwiki.org/wiki/Lexi_Mayfield_(LexiMax)

 

18 minutes ago, Dark Pulse said:

As I said earlier, demos in Doom are really a very ugly hack. Basically, they only work because the vanilla engine does the following whenever a demo is recorded or played back: 

• Set the game tic counter to 0. This will affect things like Revenant tracers, which choose which firing mode happens based upon if the tic in which it is fired is odd or even.
• Set the RNG table to start at its first entry. RNG calls naturally happen a bunch, both from the player, the monsters, and the level itself (light blinking, etc.).
• If recording, start storing keypresses; if playing back, play back the stored keypresses from the demo LMP.

This isn't a hack in any way, shape or form. It's a rather common practice to do playback and multiplayer this way for many games (and to note, this is also just how Doom does multiplayer, somehow that's been forgotten in this thread), even modern games. Heck, this is how current fighting games work even now, a sequence of inputs are transmitted and a deterministic playsim runs them back with some additional logic to roll back frames based on the input latency between the opponents. Doom using this concept to record a demo is not only not far fetched, but actually extremely standard. I also wouldn't be surprised if every RTS works this why (at least all the mainstream ones I know do), any other network model would be rather troublesome to scale.

 

Computers are just math machines running large algorithms, and games are nothing if not large algorithms determining a sequence of rules. Not a hard concept to follow that you can repeat those rules identically with the same input.

Edited October 20, 2023 by Edward850

[Dark Pulse]

1 hour ago, Edward850 said:

This isn't a hack in any way, shape or form. It's a rather common practice to do playback and multiplayer this way for many games (and to note, this is also just how Doom does multiplayer, somehow that's been forgotten in this thread), even modern games. Heck, this is how current fighting games work even now, a sequence of inputs are transmitted and a deterministic playsim runs them back with some additional logic to roll back frames based on the input latency between the opponents. Doom using this concept to record a demo is not only not far fetched, but actually extremely standard. I also wouldn't be surprised if every RTS works this why (at least all the mainstream ones I know do), any other network model would be rather troublesome to scale.

 

Computers are just math machines running large algorithms, and games are nothing if not large algorithms determining a sequence of rules. Not a hard concept to follow that you can repeat those rules identically with the same input.

Yeah, I get that, but what I mean is that basically demos rely on setting the engine to a fixed state and that it doesn't store any sort of info about the playsim at all - no positional information, no level information (other than what map to run on - I'm talking stuff like "enemies are here," etc.) and the RNG stuff is reliant on the fixed state and the fact there's an RNG table (since true RNG would make correct playback impossible without storing what the RNG-rolled values were in the demo file). Obviously there's little to no element of randomness to a fighting game or an RTS, or indeed, almost any other shooters. Even by the time we got to Quake, player shots did a fixed amount of damage. That's absolutely not the case in Doom, and so without that fixed start state, since it's not stored in the demo file itself, there'd be no way to know if this pistol shot should do 5 damage or 15, because it's the RNG table that determines that, or if a Revenant missile is homing or dumb, because it's the current tic that decides that. Naturally, this is also a large part of why ZDoom (and GZDoom) can't play vanilla demos, especially since some of those key elements, like the RNG table, are missing, while others such as the movement logic got changed entirely.

 

Hence, while on the technical side there's nothing unusual about it, in other games, demos can store values like that - Doom's does not. That's why I consider Doom demos as something of a hack in that they work by relying on assumptions, rather than "simply working," especially between engine revisions, whereas a more robust demo format would be able to avoid this to some degree. To be fair though, I guess it's not really all that different if the engine is set to a fixed state versus if the demo itself set it to a fixed state other than what is doing the setting.

Edited October 20, 2023 by Dark Pulse

[banjiepixel]

1 hour ago, Dark Pulse said:

This is why it's not really possible to "temporarily disable every feature." The underlying engine is fundamentally different, and demos are literally just a keypress log. If everything is not EXACTLY the same - and they wouldn't be (for example, the aforementioned change to floating point coordinates, or the fact that GZDoom no longer uses an RNG table of any sort) - the demo will simply not work right. Graf decided that's simply not a priority he wishes to pursue or deal with since that would force him to not be able to do other features he would like to do, but other engines can and do indeed do that.

 

That's why it should function more like a vanilla source port built into GZDoom, be more of a separate module that can take over when vanilla demo compatibility is needed, like the startup with vanilla IWADs or manually starting vanilla demo playback using a command line parameter. Since the scope of such vanilla module would rather limited, simple vanilla demo playback and possibly a new vanilla only gameplay mode, it shouldn't really interact or interfere with gameplay or development of the advanced features of GZDoom. Heck, the idea possibly could be eventually expanded to include other modules or "gameplay cores", like for example, a module for Boom or MBF.

 

It would be pretty much like compatibility modes on steroids, or RetroArch of Doom source ports. It would really make GZDoom the ultimate all-in-one solution for playing Doom. And for the most part, it should generally only require creation of the vanilla module, turning the main GZDoom gameplay mode into a module itself and creating a menu system that would allow seamless switching between the modules.

 

In the long run, it would be very much worth it because the modules outside the main GZDoom one would require almost zero maintenance. If it helps at all, modules outside of GZDoom itself could be also strictly software rendered, which also wouldn't really be a problem because how much faster they would be compared to the GZDoom module. Also no advanced modding support, maybe only some basic Decorate as a way to do DeHackEd stuff in "classic" modules and a UMAPINFO support.

 

Even if Graf doesn't want to go this direction, I am putting this idea out there incase someone likes it and wants to make an attempt on it. And just the vanilla demo compatibility on a modern ZDoom family engine would be great for more authentic experience when playing IWADs or vanilla content in general.

[Edward850]

46 minutes ago, Dark Pulse said:

Hence, while on the technical side there's nothing unusual about it, in other games, demos can store values like that

They don't, actually. That's exactly what I'm talking about, Doom is not unique or special in that matter, the state isn't stored in an input only transmission. You might be getting confused with something like Quake where that does store the frame state, but it only stores the frame state, no input information at all. Modern games still work the way Doom works, period.

 

There's nothing special that Doom is missing, the prng table isn't special, it's all just normal. You don't need to overthink this, there are no "hacks" involved here.

Edited October 20, 2023 by Edward850

[dasho]

1 hour ago, banjiepixel said:

 And for the most part, it should generally only require creation of the vanilla module, turning the main GZDoom gameplay mode into a module itself and creating a menu system that would allow seamless switching between the modules.

 

Why not just download a second port and use a launcher as your menu system? Seems a lot easier, and although not "seamless" unless you're switching ports multiple times per minute I don't see the issue.

Edited October 20, 2023 by dasho

[Professor Hastig]

45 minutes ago, Edward850 said:

There's nothing special that Doom is missing, the prng table isn't special, it's all just normal.

 

I think we can disagree on this, of all the games I know, Doom is the only one using such a hacked together (not really) 'random' table that's anything but 'normal'. And yet, since PRNGs are deterministic if their seed is set accordingly, it doesn't matter if you use Doom's 'random' table, a run-of-the-mill rand() function or something more complex like a Mersenne Twister - as long as the number of calls and their sequence is identical, the returned values are identical.

 

 

[Edward850]

14 minutes ago, Professor Hastig said:

I think we can disagree on this, of all the games I know, Doom is the only one using such a hacked together (not really) 'random' table that's anything but 'normal'. And yet, since PRNGs are deterministic if their seed is set accordingly, it doesn't matter if you use Doom's 'random' table, a run-of-the-mill rand() function or something more complex like a Mersenne Twister - as long as the number of calls and their sequence is identical, the returned values are identical.

Frankly you're reasoning is just plain strange. Doom has a pregenerated PRNG table, so what? And you even explain this yourself which is strange. It does the same thing any other PRNG system would do at a time before PRNG libraries were common place. When you needed a simple crossplatform solution, well that solves the problem relatively quickly. Pull a rotating number, take the remainder into your intended max size, done.

 

Like, you know I develop games as a job right? This is all so very normal. I've seen it all. Doom is not special.

Edited October 20, 2023 by Edward850

[Professor Hastig]

1 hour ago, banjiepixel said:

 

That's why it should function more like a vanilla source port built into GZDoom, be more of a separate module that can take over when vanilla demo compatibility is needed, like the startup with vanilla IWADs or manually starting vanilla demo playback using a command line parameter. Since the scope of such vanilla module would rather limited, simple vanilla demo playback and possibly a new vanilla only gameplay mode, it shouldn't really interact or interfere with gameplay or development of the advanced features of GZDoom. Heck, the idea possibly could be eventually expanded to include other modules or "gameplay cores", like for example, a module for Boom or MBF.

 

1 hour ago, banjiepixel said:

 

That's why it should function more like a vanilla source port built into GZDoom, be more of a separate module that can take over when vanilla demo compatibility is needed, like the startup with vanilla IWADs or manually starting vanilla demo playback using a command line parameter. Since the scope of such vanilla module would rather limited, simple vanilla demo playback and possibly a new vanilla only gameplay mode, it shouldn't really interact or interfere with gameplay or development of the advanced features of GZDoom. Heck, the idea possibly could be eventually expanded to include other modules or "gameplay cores", like for example, a module for Boom or MBF.

 

Even as a non-developer taking their first careful steps into C programming I can tell you that it's not this easy.

What benefit would there be if GZDoom got a 'vanilla module'? And who should maintain it, how should it work? Integrating the source into the project is easy, but that's just when the problems start. Doom's input model is quite a bit different from GZDoom's, you have to add some abstraction between the backend and the game code, the renderer works off the play code's floating point data so you have to rewrite the entire layer that converts game geometry into renderable data. Adding to that, have you been keeping track of vkDoom and the plans behind it? It tries to go somewhat into the same direction as Helion by rendering larger chunks of map data in one go. Now you suddenly have to deal with two very different representations of map data, one fixed point and the other one floating point, so congratulations - yet another engine part that needs to be duplicated. Wanna do further changes to how the renderer processes the map. Yay, again double work! And so it goes on. It's all doable but it is hardly economical.

Yes, it would be great having a more classic oriented port with GZDoom's renderer but that would have to be its own project with its own maintainer.

[Kinsie]

1.) I think it's good to have more than One Source Port To Rule Them All. Doom is a broad, broad church, and there should be multiple ports to cover multiple bases, whether that be insane moddability, hyper-accuracy to the original DOS binary, and the wide spectrum between those two extremes. No single port can make everyone happy, so why strive towards an impossible goal?

 

2.) I think it'd be cool if GZDoom had a new demo format closer to Quake's where it's more or less a network packet capture saving the location and state of every object every tic, for greater cross-version compatibility (I have Quake mods that don't work on modern source ports, but their included demos still work fine!), but that's far from a trivial feat to be sure.

 

3.) Animation interpolation is cool but it doesn't really work with Quake 1's original models because the animations weren't created with it in mind so they have a bad habit of bugging out (see: the muzzle flash on the Nailgun tweening back and forth between the barrels). Hell, it doesn't quite work in Quake 2 either (see: the Parasite becoming a polygon soup briefly during their death animation) but that's how it shipped so...

[banjiepixel]

1 minute ago, dasho said:

 

Why not just download a second port and use a launcher as your menu system? Seems a lot easier, and although not "seamless" unless you're switching ports multiple times per minute I don't see the issue.

 

The thing is that it would potentially benefit all source port development. If there was existing framework for such modules, it could become trivial for any source port to add compatibilities or remove them. Something like building a custom version of DSDA-Doom with only vanilla and limit removing support would require simply other compatibility modules not be included in the building process. Also one potential option would be that a PWAD could even offer it's own custom "compatibility model" that would make the process having the correct compatibility settings automatic, with a optional user override of course.

20 minutes ago, Professor Hastig said:

 

Yay, again double work! And so it goes on. It's all doable but it is hardly economical..

 

Or there could simply be vanilla specific minimalist renderer is simple turned on when the source port is in vanilla mode, also same could done to the input handling. At this point we talking about being able to switch to a vanilla mode during the startup. And the thing is it's possible that the GZDoom team wouldn't need to all the work. It would be great opportunity for various source port developers to work together as in the end, all that work needed to create framework like that benefit the whole community. The vanilla module could be easily be developed by someone more familiar with vanilla source port development while GZDoom team would only need to work on creating a system module support itself.

 

And once there is there the module and support for it, the module could easily go years without being update and still work with latest GZDoom because it is literally just a separate module replaces functions of GZDoom without actually interacting with them. This does make things whole alot simpler. Only extra work to the GZDoom team at this this point would be that if some mistake they make breaks the module support. The modules could potentially be even near complete engine replacement if needed and this could extend modding possibilities with creators being able to ignore any need to be compatible with existing Doom engine content, something that GZDoom developers themselves can't do.

[Professor Hastig]

3 minutes ago, banjiepixel said:

Or there could simply be vanilla specific minimalist renderer is simple turned on when the source port is in vanilla mode, also same could done to the input handling.

 

 

In clear English what you are saying essentially means to integrate a completely separate secondary port into GZDoom.

At this point it becomes an exercise in pointlessness. If you want a vanilla port with other GZDoom features, why not make another port with GZDoom features?

But any way you twist it, such a thing is better served as its own project because then you are no longer forced to cover all eventualities in your backend code and can make adjustments if needed.