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)

[banjiepixel]

2 minutes ago, Professor Hastig said:

 

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.

 

 

By all means, I am not saying it must be the GZDoom team that takes the lead with this. They just probably have most resources do alot of work that would be required. Also my main point is just that the module framework would have tons of benefit and would make it extremely easy for GZDoom to add vanilla demo compatibility. The modules could be the future of source port development and could even work both ways, with things like ZDoom support being able to be added to DSDA-Doom by simply writing a ZDoom module without needing to worry about other code changes that would be required without the module system.

 

I personally also like that it could be used to create stronger separation between the compatibility modes.

[Dark Pulse]

2 hours ago, banjiepixel said:

 

By all means, I am not saying it must be the GZDoom team that takes the lead with this. They just probably have most resources do alot of work that would be required. Also my main point is just that the module framework would have tons of benefit and would make it extremely easy for GZDoom to add vanilla demo compatibility. The modules could be the future of source port development and could even work both ways, with things like ZDoom support being able to be added to DSDA-Doom by simply writing a ZDoom module without needing to worry about other code changes that would be required without the module system.

 

I personally also like that it could be used to create stronger separation between the compatibility modes.

You can have all the resources in the world, but if the interest in doing it and maintaining it isn't there, that simply does not matter. None of the current devs seem interested in this, but if you know how to code or are willing to learn how to code, if it's important to you, by all means, get in there and start cracking away at it.

 

Ideas like that are easy to say but hard to keep maintained and reliable, and considering the significant changes GZDoom has every engine revision, that would always be the catch. id didn't even try to keep demo compatibility between engine revisions, and compared to GZDoom, that code was far simpler.

Edited October 20, 2023 by Dark Pulse

[Professor Hastig]

39 minutes ago, Dark Pulse said:

You can have all the resources in the world, but if the interest in doing it and maintaining it isn't there, that simply does not matter. None of the current devs seem interested in this

 

 

Have you heard that recent chatter about GZDoom that it intends to split up between an OpenGL and a Vulkan port? Why? Because it increasingly incurs an unmanageable amount of double maintenance that is threatening to stall future development. By leaving OpenGL behind all the work can be focussed on the modern iteration.

It's precisely the same here - that code is not free - it will cause work as long as it is there, even if you isolate it further. At some point something needs to change that will affect this hypothetical 'vanilla module' and then become the cause of added work. But you just saddled it upon a group of developers that has no interest in this. They mainly do not have any interest because the existing ports already service this segment of the market with far greater dedication. It'd only take away scarce resources from work that these other programmers are not interested in. The end result will be some lower productivity overall, i.e. lose-lose.

 

Edited October 20, 2023 by Professor Hastig

[D4NUK1]

We need to see the other side of the coin.

 

What if we make instead the devs of demo compatible games be compatible with GZDoom wads. That's would be more easy 

 

 

/s

 

For the more straight forward, if we as a group of devs outside of GZDoom make this vainilla demo compatible with a module/fork of GZDoom, what would be the user case, everyone would start making demos or watching it with 3D Hardware rendered or what would be the best outcome that others ports can't do?.

[Professor Hastig]

9 minutes ago, D4NUK1 said:

For the more straight forward, if we as a group of devs outside of GZDoom make this vainilla demo compatible with a module/fork of GZDoom, what would be the user case, everyone would start making demos or watching it with 3D Hardware rendered or what would be the best outcome that others ports can't do?.

 

Joking aside, the outcome would be that you could watch the demos with dynamic lights and SSAO, but that's essentially it.

If you do not need that, for pure playback PrBoom+ will give you almost everything else (DSDA won't with its removal of the true color renderer.)

 

[dpJudas]

8 hours 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.

Of course it is a hack. It forced the original Id Software developers to lose their intro sequence for the game every time they released a patch for the game. The players also lost all their recorded demos when they did that. That's not good software design, even if a lot of games did it at the time.

 

Multiplayer is a completely different deal, since here you can require all clients to be on the same version. Incidentally, that's also why GZDoom still supports it.

[Redneckerz]

11 hours ago, banjiepixel said:

 

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.

I don't like these kinds of generalizations so please can you aswell be more careful with your words if you are going to handle the broom to poke at people.

4 hours ago, banjiepixel said:

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.

This quite literally sounds like how Doomsday has been developed - from seperate executables, to plugins with a wrapper exe, to (nowadays) modules within the Doomsday framework. Why don't you use that? It seems that's exactly what you want. Ofcourse, these modules are purely game-related - One for Doom, one for Hexen, etc. 

 

What you want is essentially similar, but rather: A vanilla module and a moddable module aka how GZDoom is today, seperated within a more general framework, just like Doomsday.

 

But at the end of the day, the interest has to be there. From everything in GZDoom's history, its clear that this concept isn't what is worked towards at. There is VKDoom as recent development, which seeks to do something similar to the Quake port Ironwail - Optimize for performance and including lightmaps. Then there is Helion which simply does away with the Doom render loop - essentially a custom renderer that is finetuned to behave exactly like Vanilla/Boom/etc..

4 hours ago, banjiepixel said:

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.

What i like about this entire concept is how you are essentially presenting it as an ideas guy, theorizing how the GZDoom developers need to develop their port and how much easier life would be if they just followed your steps. I think that's pretty rich given how at the same time you tell one such developer to be careful with his words and generalizing how some other GZDoom people also tend to project pretty hard.

 

You want to be heard? Be a co-developer instead of an opinionist semi-attacking the very people you want to listen to you.

 

[Edward850]

55 minutes ago, dpJudas said:

Of course it is a hack. It forced the original Id Software developers to lose their intro sequence for the game every time they released a patch for the game. The players also lost all their recorded demos when they did that. That's not good software design, even if a lot of games did it at the time. 

A lot of games still do it, it's an extremely standard way of doing demos. And just because you don't like something, that doesn't make it a hack, it removes all meaning of the word otherwise.

Edited October 20, 2023 by Edward850

[dpJudas]

A million flies can't be wrong. Saying a lot of people is doing something isn't really a strong argument for quality/correctness. But I'll humor you: GZDoom doesn't actually do anything wrong. Its demo compatibility is exactly the same as Carmack and Romero provided: this patch only. What you're seeing in this thread are the users being unhappy that such a design fucks their demos over. None of the games of the 1990's that I know of that did demos this way maintained perpetual backwards compatibility in the manner that modern Doom source ports do.

 

I think this fits the definition of hack perfectly fine. A shortcut that is a pain to maintain in the long run that didn't really address the problem in a solid manner.

[Edward850]

You can think what you like I suppose, but that don't make it right. All the code follows reasonable and sound logic, and thus doesn't fit any reasonable description of "hack". There's no moon logic found in that code.

 

Also I don't particularly care what gzdoom does or doesn't do. You can claim its right or not, but I never brought it up. The only thing I ever talked about was the feature itself.

Edited October 20, 2023 by Edward850

[dpJudas]

The hack is the assumption that playsim code never change behavior and even if it does you'll be able to easily tell that you broke it. For multiplayer that's (usually) not a problem since you can just require all players use the same patch version. You can't do that for demos as they are persisted on disk.

 

If you don't find that to be a hack I guess we'll just have to disagree on that as you say.

[Edward850]

It's not a hack if that blatantly wasn't even important to the feature. You seem to be insisting on a standard that just simply wasn't necessary at the time. It was only later on that people decided it was important.

After all, it's demonstrated that you can make demos in sourceports maintain compatibility between revisions if you bother to implement it without frankly that much effort at all.

[dpJudas]

I agree with you on that, but to me that's also the nature of hacks: they get you the feature fast (demo playback), but is built on assumptions that aren't universally true.

 

In any case, my first post was to illustrate it isn't as black and white. There are some serious cons to the input recording strategy, whether we call it a hack or not.

[Edward850]

7 minutes ago, dpJudas said:

I agree with you on that, but to me that's also the nature of hacks: they get you the feature fast (demo playback), but is built on assumptions that aren't universally true.

This seems to be a misunderstanding of commercial software development, a feature implemented quickly that does only what you need it to do is exactly the expectation. If you start calling that a hack then the word automatically loses all meaning, actual hacks are things like finding a code base that relies on void being 4 bytes wide or single size array allocations expanded into larger suzes via a custom allocator. The demo feature did exactly what it needed them to do, play an arcade attract sequence at the start of the game.

 

The fact we used it to preserve 30 years of speedrunning and tournaments was just pure evolution.

Edited October 20, 2023 by Edward850

[Jerem]

I think the "hack" confusion is simply a miscommunication based on experience.

Unless you both can agree on a source for definitions, I don't see anything constructive coming out of continuing. 🙁

[dpJudas]

But it didn't do exactly what they needed. Even in the 1990's a user that recorded demos with Doom 2 1.666 lost all his demos when he upgraded to 1.9. The "solution" back then was to make a second folder with the old version of the game and load that up if you wanted to see the demo. Even with modern source ports he still can't view those demos outside dosbox as far as I know. The only saving grace of the 90's was the fact that getting a new patch required so much of an effort that most of us didn't even bother.

 

Hacks always break in the edge cases, or when code gets refactored, which this is just another example of. By your definition if the customer doesn't complain and you complete the task quickly, then something isn't a hack. That doesn't seem like a very good definition of the term either.

[banjiepixel]

17 minutes ago, Redneckerz said:

I don't like these kinds of generalizations so please can you aswell be more careful with your words if you are going to handle the broom to poke at people.

 

Just a simple observation based on how there are people here that seem very uncomfortable with the idea that using GZDoom to play non-GZDoom content is less appropriate than playing it with something closer to the specificiations that the content was made for, even when it is literally not supposed to be a negative thing to engage less appropriate play and I even freely admit myself doing it. And these specific people do tend to get very defensive of GZDoom very quickly with no reason, so "some other GZDoom people" does seem pretty accurate to me instead of being generalization. In my view, at most it could be too vague as the connection between GZDoom and "these some people" isn't directly stated.

 

42 minutes ago, Redneckerz said:

This quite literally sounds like how Doomsday has been developed - from seperate executables, to plugins with a wrapper exe, to (nowadays) modules within the Doomsday framework. Why don't you use that? It seems that's exactly what you want. Ofcourse, these modules are purely game-related - One for Doom, one for Hexen, etc.

 

I am aware, my idea mainly take just that approach to the next level. Should be noted that this isn't about what I personally would like to use to play Doom, not to say I wouldn't use source port that had a module system that works like the system I am describing here.

 

52 minutes ago, Redneckerz said:

But at the end of the day, the interest has to be there. From everything in GZDoom's history, its clear that this concept isn't what is worked towards at.

 

Just like I said, Graf doesn't need to have interest to make the module system become reality, idea is shared for anyone potentially be the one to make it the reality. It seems to be pretty GZDoom centered thinking that I would be putting any pressure or expection to GZDoom do this. I am simply trying to "sell" my idea to anyone that could get interested, GZDoom developers included.

 

1 hour ago, Redneckerz said:

What i like about this entire concept is how you are essentially presenting it as an ideas guy, theorizing how the GZDoom developers need to develop their port and how much easier life would be if they just followed your steps. I think that's pretty rich given how at the same time you tell one such developer to be careful with his words and generalizing how some other GZDoom people also tend to project pretty hard.

 

It might be some kind of autistic or neuroatypical trait in me but I really don't get how normal people work. I simply theorize how my ideas could fit to the GZDoom development pipeline and goals if they get interested and this is somehow me telling them what they should do. And how just some light talking back against the main GZDoom developer and some other people that seem to be have a pretty arrogant GZDoom centric views makes it weird that I would present my idea to also them despite how I feel Graf's attitude.

 

It's like normal people are so wrapped in their ego that they must make everything personal, even when there is literally a zero reason to do that and it only overcomplicates things while making the communication much harder. And just to clarify, that is not meant to be claim, accusation or generalization. It is literally just my personal interpretation because none of that behaviour makes any real sense to me.

[Dark Pulse]

49 minutes ago, banjiepixel said:

Just like I said, Graf doesn't need to have interest to make the module system become reality, idea is shared for anyone potentially be the one to make it the reality. It seems to be pretty GZDoom centered thinking that I would be putting any pressure or expection to GZDoom do this. I am simply trying to "sell" my idea to anyone that could get interested, GZDoom developers included.

Fine and dandy, but if they haven't done it in the last 15-odd years of GZDoom's existence, I doubt they are going to pick it up, and considering there are alternative ports more focused on demo compatibility, odds are slim that it will happen. Usually features to the engine come along when someone is willing to do the work and put in the code - this is how we got stuff like portals, Doom 64-style lighting, even ZScript.

 

It's basically a solution that doesn't really have an audience, as the audience you are looking for basically "I like GZDoom, but I want demos too, but I don't want to use a source port that is more friendly to them or give up GZDoom features." 

 

Nothing wrong with posting the idea, but that's a pretty narrow segment. Most people who want features don't really care about demo compatibility, and most people for whom demo compatibility is important aren't going to be using GZDoom in the first place.

[dsda-dev]

Even in a port designed completely around demo compatibility like dsda-doom, demo compatibility is HARD. When heretic was being implemented, there was a desync with a single demo out of a thousand from the archive. If that demo didn't exist, the issue would not have been caught. Before releases we do regression tests against tens of thousands of demos and sometimes catch errors affecting only a few of them. On the hexen front, chocolate hexen is not completely demo compatible and this has also been inherited by dsda-doom. PRBoom+ and by extension dsda-doom are also not compatible with MBF - a ton of stuff was broken over the years and Woof had to make changes to adapt to the status quo rather than maintain compatibility with the original MBF.

 

To give an idea of the type of thing that can break demo compatibility that could be difficult to anticipate or catch, here are a couple real examples, that would also have happened during zdoom's development:

 

Hexen uses single bytes for its special action arguments. This is pretty limiting, so integers are used in udmf. It turns out that one of those byte arguments in hexen was used as a rolling counter that loops from 255 to 0 by incrementing it and letting it overflow. When it became an integer, it stopped looping and the associated code started behaving differently. In another place in the code, the array of byte arguments was cast together as one integer. Naturally, that casting process also lost information when the bytes became integers instead.

 

So even in a port designed for this purpose, and with comparatively less (and simpler) change over time, maintaining demo compatibility is a constant challenge and there are still gaps.

[Graf Zahl]

31 minutes ago, Dark Pulse said:

Fine and dandy, but if they haven't done it in the last 15-odd years of GZDoom's existence, I doubt they are going to pick it up, and considering there are alternative ports more focused on demo compatibility, odds are slim that it will happen. Usually features to the engine come along when someone is willing to do the work and put in the code - this is how we got stuff like portals, Doom 64-style lighting, even ZScript.

 

 

It was already hinted at in other posts but when it comes to programming there is no such thing as maintenance-free code. Once we take on a 'vanilla compatible module' it is there, it has to be maintained, it has to be adapted to changes in the underlying engine etc, and it has to be tested! All this costs time. If someone else is interested in such a port, they are welcome to maintain it - but certainly not as an integrated part of GZDoom but a standalone engine.

 

It is very much like the upcoming render backend split we are planning. Having two render backends means that all code needs to work with both, and often the differences are small but incredibly hard to manage in a shared code base. On top of that for Vulkan-based enhanced features some data structures need to be changed and if both backends were there the GL backend would need frequent adaptation to work around these things. It is far more economical to have two separate projects that can make their own individual changes and over time deviate ever further.

 

35 minutes ago, dsda-dev said:

Hexen uses single bytes for its special action arguments. This is pretty limiting, so integers are used in udmf. It turns out that one of those byte arguments in hexen was used as a rolling counter that loops from 255 to 0 by incrementing it and letting it overflow. When it became an integer, it stopped looping and the associated code started behaving differently. In another place in the code, the array of byte arguments was cast together as one integer. Naturally, that casting process also lost information when the bytes became integers instead.

 

That's things we found out quite frequently with Hexen. It has a few weird things going on that are really non-intuitive. One thing in particular was some angular math for the Heresiarch that depended on integer overflows in such a peculiar way that the only way to fix it in the floating point version was to convert an angle to BAM, do some calculations with it and then convert it back. Doing the math directly with floats just did not work.

 

[Andromeda]

1 hour ago, dpJudas said:

Even in the 1990's a user that recorded demos with Doom 2 1.666 lost all his demos when he upgraded to 1.9. The "solution" back then was to make a second folder with the old version of the game and load that up if you wanted to see the demo. Even with modern source ports he still can't view those demos outside dosbox as far as I know.

PrBoom and its offshoots support 1.666 demos.

 

3 hours ago, Professor Hastig said:

Joking aside, the outcome would be that you could watch the demos with dynamic lights and SSAO, but that's essentially it.

If you do not need that, for pure playback PrBoom+ will give you almost everything else (DSDA won't with its removal of the true color renderer.)

On the other hand PrBoom+ doesn't support MBF21 wads.

[Bank]

On 10/14/2023 at 1:00 PM, Flytrap said:

Sooo, why doesnt GZDoom support replays? Or accurate compatibilities for that matter

 

I love multipage threads where everyone defends their preferences as though we haven't been having the same conversations about this for 20 years, but I actually know the answer to this original question: because the people who make things get to decide how they work.

 

It may not seem obvious to us players, but this marvelous world of choice and preference and sourceports is made possible because very very sick people make the bewildering decision to take on the thankless job of creating it for us with their own time and expertise. I don't think it is reductive or anti-communitarian at all to say "if you don't like features in a project, make your own project." And people do this all the time, groups with strong preferences or goals coordinate around a project that serves the interests of their community like DSDA for compatibility-obsessed speedrunners or GZDoom for third-dimension enjoyers.

 

The fact that these projects exist at all is a small miracle with almost no parallel in other gaming communities of this vintage. The overwhelming majority of Doom community members do not possess the ability, the desire, or the frightening obsession required to create a source port, or any technical content at all. That is why in the 30 year history of this community, there are at most 10 memorable and influential source ports that any regular Doomer can name. I hope one day we can free ourselves from the same (frankly boring) cycle of conversations about the "RIGHT" way ports should work and get back to important forum topics like "what would yuo do if doom happened in real life."

[banjiepixel]

3 minutes ago, Dark Pulse said:

Fine and dandy, but if they haven't done it in the last 15-odd years of GZDoom's existence, I doubt they are going to pick it up, and considering there are alternative ports more focused on demo compatibility, odds are slim that it will happen. Usually features to the engine come along when someone is willing to do the work and put in the code - this is how we got stuff like portals, Doom 64-style lighting, even ZScript.

 

It does seem to me that my idea would approach things in a new innovative way that would be only fitting to a "bleeding edge" source port like GZDoom. especially as big portion of it's base is made of people looking for "all-in-one" solution for playing Doom. But it is alot like with implementing actual proper netcode, the developers are not just not interested because it is not what they personally want or need from a Doom source port. As a more idealistic type of person, I often wirh that they would see things beyond just their own personal preference and seek to create something with a more universal scale that would benefit the whole community more.

 

And any new feature does start from an idea and considering if it would be possible, useful and needed. There is nothing wrong with discussion about an idea like the one I have shared here. It is supposed be just strongly hypothetical to explore new ideas and approaches that could be missed by the more grounded practical thinking that would tell us that such a big paradigm shift would be totally unrealistic atleast for the GZDoom project. The point isn't the direction of GZDoom development but finding a solution to things that make it so hard to have any kind of demo compatibility in GZDoom, my idea could potentially be a solution.

 

16 minutes ago, Graf Zahl said:

It was already hinted at in other posts but when it comes to programming there is no such thing as maintenance-free code. Once we take on a 'vanilla compatible module' it is there, it has to be maintained, it has to be adapted to changes in the underlying engine etc, and it has to be tested! All this costs time. If someone else is interested in such a port, they are welcome to maintain it - but certainly not as an integrated part of GZDoom but a standalone engine.

 

Why the modules would need too be adapted to the changes in the underlying engine if for the large portions of them would be standalone with rest of using shared features of the underlying engine by the module system itself working as a compatibility layer between the underlying engine and the modules themselves. This would mean that modules could be nearly universal and it is only the module support that needs to be adapted to a specific source port. Nobody is suggesting that GZDoom should do this, just that it could be done and it would be a solution to the demo compatibilty issues.

[dasho]

You say that it is "innovative" and would "benefit all source port development", so as a thought exercise, how would it benefit EDGE-Classic? I predict that even if such a "RetroArch-but-just-for-Doom-engines" came into being, and we put in the work required to make our program work as part of such a modularized system, it would simply be a menu entry that gets quickly passed over on the way to GZDoom.

[Graf Zahl]

10 minutes ago, dasho said:

You say that it is "innovative" and would "benefit all source port development", so as a thought exercise, how would it benefit EDGE-Classic? I predict that even if such a "RetroArch-but-just-for-Doom-engines" came into being, and we put in the work required to make our program work as part of such a modularized system, it would simply be a menu entry that gets quickly passed over on the way to GZDoom.

 

Don't overthink it. The entire idea is not practicable in any way so there's really no need to argue about its appropriateness to other ports. The code bases are so vastly different that the needed work would be far too much.

 

IMO the only thing in GZDoom that could be shareable is ZMusic and that's already a standalone library with no dependencies on the engine

[Redneckerz]

4 hours ago, banjiepixel said:

It's like normal people are so wrapped in their ego that they must make everything personal, even when there is literally a zero reason to do that and it only overcomplicates things while making the communication much harder. And just to clarify, that is not meant to be claim, accusation or generalization. It is literally just my personal interpretation because none of that behaviour makes any real sense to me.

If you are going to call some GZDoom people, don't hide behind a curtain or a textual Jedi trick: Call their names.

 

This has little to do with people but more the fact you put in little lines that are designed to piss people off. Which is what i mean't when i wrote what i wrote.

2 hours ago, banjiepixel said:

Why the modules would need too be adapted to the changes in the underlying engine if for the large portions of them would be standalone with rest of using shared features of the underlying engine by the module system itself working as a compatibility layer between the underlying engine and the modules themselves. This would mean that modules could be nearly universal and it is only the module support that needs to be adapted to a specific source port. Nobody is suggesting that GZDoom should do this, just that it could be done and it would be a solution to the demo compatibilty issues.

Okay, so you explained your idea. People have been telling you the following:

• GZDoom won't do this (You accept this, you are merely stating a idea after all)
• It sounds like Doomsday (You are aware of this, and describe it as taking that approach to the next level. However, you also say that this wouldn't be your way to play Doom or even a module system that is put in a source port to begin with
• The entire idea/concept relies on something that yes, could be done, but as Doomsday shows - is a lot of work to maintain, and it isn't that popular either. Since there is already a smaller version of this concept available (Doomsday), there is practically no niche to which this hypothetical work could cater to.

What in the ever-loving heck do you keep on arguing then, in a thread that is about why GZDoom doesn't support replays or accurate compatibilities when it comes to demo's? The question by itself is, frankly, rather naive - GZDoom, much less so ZDoom, was never about demo accuracy to begin with. At best, one could look at ZDoom 1.x demos as those are somewhat fixed (And not ideally by such)

 

So basically i am at @Graf Zahlhere: There is no practical reason to do this. Sure, if you want to do this, go ahead! Make your own port if you don't want to be a co-developer. People make wonderful things when left on their own.

Edited October 20, 2023 by Redneckerz
Drawing a fully unintended comparison. I have sent my pencil to sharpening camp.

[Gez]

1 hour ago, Andromeda said:

PrBoom and its offshoots support 1.666 demos.

PrBoom and its offshoots were not around back when Doom v1.9 was brand new and people were updating from 1.666.

[banjiepixel]

7 minutes ago, dasho said:

You say that it is "innovative" and would "benefit all source port development", so as a thought exercise, how would it benefit EDGE-Classic? I predict that even if such a "RetroArch-but-just-for-Doom-engines" came into being, and we put in the work required to make our program work as part of such a modularized system, it would simply be a menu entry that gets quickly passed over on the way to GZDoom.

 

Large portions of more casual users would only use the Default/GZDoom module, but because of people that do actually explore what the software can do, EDGE-Classic could gain more exposure and accessibility. People would be more likely try and use EDGE-Classic if it is part of the software they are already using. Using any lesser known standalone source port is always a potential security risk to the user. I have personally discovered many great emulators simply because they are a part of the RetroArch ecosystem.

 

12 minutes ago, Graf Zahl said:

Don't overthink it. The entire idea is not practicable in any way so there's really no need to argue about its appropriateness to other ports. The code bases are so vastly different that the needed work would be far too much.

 

Different code bases can be adapted to become semi standalone modules that work in same underlying engine, this is pretty much how RetroArch works. It should be actually even easier simply because we are nnly talking about variations of the same base Doom source code. It would probably require completely new underlying engine designed to be modular from the ground up, but the thing is that all of the existing GZDoom code could be adapted into being a module. Why emulator community can do it but not the Doom community?

 

22 minutes ago, Redneckerz said:

If you are going to call some GZDoom people, don't hide behind a curtain or a textual Jedi trick: Call their names.

 

It was an attempt to be polite while giving still some push back against bad attitudes. Graf is a big name in the community so a direct reference is fine. But since I am more unfamiliar with the status of people do seem to have similar bad attitude, I feel like it's best not target them directly. In my mind "SOME GZDoom people" does atleast make it clear that I am not talking about all GZDoom users and for me it seems good enough as it would be a real generalization to me. Simply hinting about that there are some unnamed people that might need an attitude check shouldn't piss anyone off outside of those seem to have the attitude issues that I hinted at, atleast if they are able read my hints. Unrelated people with a clean conscience should be smart enough to understand I couldn't possibly be talking about them, right?

[Graf Zahl]

1 minute ago, banjiepixel said:

Different code bases can be adapted to become semi standalone modules that work in same underlying engine, this is pretty much how RetroArch works. It should be actually even easier simply because we are nnly talking about variations of the same base Doom source code. It would probably require completely new underlying engine designed to be modular from the ground up, but the thing is that all of the existing GZDoom code could be adapted into being a module. Why emulator community can do it but not the Doom community?

 

You clearly have no idea what this entails. No, it isn't nearly as clearcut as you make it out. Remember: Raze is a somewhat watered down version of such a concept and it is not trivial keeping all this stuff in sync between the 4 different game modules.

[Individualised]

56 minutes ago, Redneckerz said:

autistic or normal people

Can we not do this?