banjiepixel

But it would be nice that my Doom source code based DOSBox frontend would also work as native Doom source port with all the neat Crispy Doom features that I like to have. Crispy Doom and DOSBox combined to be single program that can do both, play native version of Doom with crispy features and play the original dos version with only vanilla features in emulated form along with other emulated DOS games. The interface should be the easy part, especially if I first focus on being just a simple frontend that launches a separate totally external DOSBox executable, Logically I would only need to find a way to make the source port be able to give a external program like DOSBox simple commands to execute. And I do learn and stay motivated better by teaching myself to read existing code and experimenting with it. Even if I just wanted frontend without a sourceport, I would base it to Doom code, just stripping it from anything that isn't menu and interface related. And Doom source code already uses the Doom assets and has all the needed core menu functionality, so why try to recreate something that already exists? What actually seems to be complicated is to make source port and dosbox work together like they would be a single executable. Even if it would be between some other program and DOSBox.

I don't want some basic frontend for DOSBox with mouse based controls, boring Windows-style looks and not being made to launching specifically Doom and maybe some other related games. I want make DOSBox launcher that would actually make me use DOSBox. And that would be a Doom source port, most likely crispy doom based, with an ability to seamlessly launch DOSBox game sessions within it. And have my own custom expanded Doom menus. I am not sure how much clearer I could be with what I would like to make for my own use.

It is true that my wording does not seem exactly accurate. But "Dos program that would run before Doom" or "make another Doom source port for Dos with those features implemented" seem match to my goals even less. I like the idea of Wolfenstein 3D, Doom and even Quake being playable from same interface based on Doom and combinng Doom source port with DOSBox seems slightly easier than trying to somehow mix Wolfenstein and Quake sources together with Doom code.

DOSBox features would come with new menus that allow starting Doom on DOSBox directly with no DOS prompts. My plan is actually that many traditional command line parameters would be simple menu options when using DOSBox, things that often need to be entered manually to Doom launchers. For example, instead of needing to use -warp parameter, you would have level selection menu for playing Doom using DOSBox.

A part of the source port would be a modified menu system to make playing DOS version of Doom easy with things like level selection menu and idea would be to eventually have also other Id games supported by the new menus designed to make their use with DOSBox easy and hopefully seamless as possible. DOSBox related Doom features generally would just be the logical starting point. No, separate feature, actual Crispy Doom gameplay related things wouldn't be touched, just native version and emulated DOSBox version being playable from same unified user interface. It is the new menus I want to design for playing both and not needing switch program change version that main things for me, with emulated side making more sense once I start to include new menus specific to other games too. I am talking about potentially being able to make my own Crispy fork with a seamless DOSBox support. Including my own custon menu design based on Doom menus to create a pleasant user experience, atleast for myself. Actually the most important thing would be that I want to create a specialized DOSBox frontend using Doom source port as the base. But I am hoping to make it as seamless as possible so the source port and dosbox would need to be made function very closely together. And not much point in trying remove the native Doom gameplay functionality as it is already there by using a source port directly as the base for the frontend.

Who has said anything about only being able to run Doom being the goal?

Just mainly the user experience, being able to use extra features of a source port but also easily play the original DOS version of the game using the same program and interface. And both things being so close together could give some extra benefits. Mostly thinking about this for my personal experimentation, potentially something that could help me to learn some coding. Making two separate programs closer to being one atleast sounds somewhat good place to start because i would have to dive into the code of both existing programs and learn how they function. And as a purist, something like Crispy Doom that would work also as user interface to play the DOS version could have value to me. And I really don't mind wasting my time and sanity to create something that has value to me. But not knowing the scale for actual work needed, it is hard to know how much it would be actually worth to me personally. I mean it would a nice little extra have with a source port and there is nothing wrong with there being another DOSBox frontend. There is some inspiration taken from that thing, but this is a separate idea with much smaller and hopefully more realistic scale. Just something that I personally would like to try making to have nice DOSBox user interface for myself. And maybe learn some programming along the way.

Alot of remastering comes from the fact that console generations usually have hard cutoffs to access to certain games. Remasters are very often just a port to newer generation console to keep the game accessible with actual upgrades to graphics being mostly just something extra to make it more worthy package to sell. Remasters on pc are generally always essentially pc ports of console remasters or old pc games upgraded to be functional on modern hardware. So answer is, if they're already making console remaster, why not make a pc version too and sell it there as a new product too, like they do on consoles? For every Skyrim remaster, there was a new set of next generation consoles to port the game to. I mean, it is technically the version of the game with latest updates and you gain access to the same product that is on the current gen consoles, so why not?

I do feel like the issue is that it's the current ecosystem that does make it not be that easy so I have started to move it away from that ecosystem and to the direction of something more independent that could be then brought into the excosystem once there is clean packaging and usable API for it. How often the GZDoom's music format libraries, especially those responsible of things like vgm chiptune music formats are updated and how often they actually need to be updated? I would assume that very rarely if these use some kind of API solution. So currently my concept takes alot inspiration from this and would seem to be able to dodge alot of issues that devs have noted there being. I am hoping to hear about solutions to the issues in my concept and pointers to the direction that would make my theoretical solution more practical. Some people done this and I am thankful for that, but you for example seem to take it as personal insult that I am trying despite maybe lacking some critical information about coding and software development. I might make some careless and uninformed claims about some things being easier than they probably actually are, but that is generally how I discuss and learn, I present my case for my current understanding about the topic and expect the other side to present a better case for the things that I am wrong about. Me presenting my case does seem to be often taken as attempt to argue or debate when in reality I am just trying to gain more data that I could use analytically to reach the right conclusion. Except it goes far beyond just ideas. While i am floating the idea around, my brains are so hard at work crunching all kinds of numbers related my idea that people seem to have trouble keeping up with how much it has already evolved with actusl programmer concerns having been pretty useful, despite plenty of negativity. The thing about Ideas Guys is that they're out of touch because they lack in the practical analytical skills. That isn't a issue for me and it is literally just specific bits of data missing that is leading me into potential wrong conclusions. And my questions do usually target pretty well the places where I suspect there being important missing data so I can easily interpolate the rest to reach the correct conclusion, you know if dev people would bother to actually answer most of my questions. I could be called more of a theory or analysis guy, on the surface it could look alot like a ideas guy, but actually can bring something deeper and practical to the table. You know, if the discussion wasn't mostly just shallow bickering. It does amaze me how much my regular, generally too polite behaviour can trigger some people that I do assume to have mostly more typical neurological state. It is kinda hard to be elitist when I am constantly politely asking clarifying questions from the coders and programmers and get no answers because apparently it is arrogant to ask and I am expected to just take their word at face value without being allowed to reach the same conclusion on my own with just couple of extra pieces of information. And as a part of my natural analytical process, I must consider always a possiblity that there are gaps in the any coders knowledge, no matter how experienced and professional they are as a developer. At no point I am putting myself above them, only thing I do is attempt to rule out their own personal blind spots from the equation, after all we are just humans. And it is not like people outside of neurotypicality or specific community in general ever come up many brilliant ideas that are possible only thinking outside the box. To be brutally honest, my alleged "elitism" does look alot like tons projection happening, people getting triggered because of my untypical behaviour and approach to things. It is almost funny how untypical lack of ego seems to look like there being too much of ego to a more typically egocentric person.

Does sound like very similar idea, just slightly different approach that I had in mind. And I did realize that some like demo video player would probably require that demo files would include data defining the needed IWAD and potential needed PWADs to be loaded along with them, so mainly a enhanced demo file format ccould be a decent solution. One big goal would be to playback Doom demos outside of traditional source port enviroment and user interface so traditional demos needing to converted into new enhanced demo file format would be less of a issue, same could be said about GZDoom as it is so far removed from anything more directly demo compatible. Nobody is forcing you to engage with me, you are completely free to ignore me completely. But it should be clear that I am going beyond of just being someone with an idea and expecting port devs just make it a reality for me. I am going to need eventually somneone to do atleast most of coding for it as my brains are wired for design and user interfaces, it is better that designers do not do the coding and coders do not do the design, but that is not problem for today as I am currently in just the brainstorming, research and planning phase. There literally no need for any programming yet and it is pretty much impossible to submit a pull request as my initiative isn't atleast currently specific to any existing source port. And it isn't probably a good idea to burden port developers directly and instead it's better to seek more general community help and advice, like I am doing right now in this thread where discussion is about a issue that my ideas could likely solve. And I am trying to discuss about the programming theory that would present roadblocks to my hypothetical solution, that is called doing research and seeking advice to find a shape for my ideas that would be practical to execute and would benefit the community. I really don't like this "code first then ask questions" attitude. I know that devs generally might not have time to advice non-programmer like me about the practical coding roadblocks related to my ideas but how about atleast some positivity in the feedback if you're taking the time to reply. I do feel like this sign of a discussion culture that isn't very healthy.

Currently I am trying to brainstorm my ideas with community which is taking the first steps making it a reality and it would be much easier if people would willing to actually discuss about it instead of trying instantly shoot it down. I need make the idea float around so I could eventually get actual programmer interested doing the coding for it. I am already doing alot to process the idea itself forward and refining it into something practical to write code for. There is zero implication of anyone being lazy, it's just me hoping atleast some cooperation from the community to help anything currently not vanilla Doom demo compatible to gain easy access to having demo compatibility. I am simply asking for willingness to help me and take my idea seriously, even if it is just to humor me and my nonsense ideas. Like I said, adding support for manipulating MIDI sequences would be easy at that point, it would be very arbitrary limitation to have only playback support. And of course if Doom source could be simply audio or video player plugin, it would open alot of doors for "It runs Doom" stuff. Also one potential logical extreme could be that the same core plugin api or library could be used in expanded form to make even the mighty GZDoom run in browser and other very unlikely and hard to port places. It would be mainly about Doom community helping to make doom demo playback more accessible in general. Honestly I am surprised that people aren't interested about the idea considering how much the community still uses demo recording and playback in the modern day and demo compatibility is highly valued feature. But then again, it does also seem like there haven't been any attempts to make demo playback more user friendly experience, atleast as far I know.

And that is exactly why GZDoom support should be side effect of there being API that would allow a simple vanilla Doom demo player plugin added to almost any piece of software. GZDoom does already support emulated music format playback so why not emulated demo format playback? The emulated music playback uses already existing libraries and emulated demo playbabk would technically only require the library that can do that to be created. Obviously emulating demo compatibility is much more complicated than emulating music format, they are in essence the same process and adding support to them to any software as long as the library already exists is basically identical. And the great thing about emulated vanilla demo playback library would be that it is literally only few steps away from emulated vanilla gameplay and demo recording. In the end we would have this whole new layer of Doom source port development being based on this library that is extremely portable. Ideally the library could make things like playing Doom on video player sofware not only possible but also easy to implement. But for practical reasons, let's focus on just the demo playback for now.

That does sound rather close to what I have in mind. Even if it would be just something very simple that could be used to playback demos in traditionally non-demo compatible source ports. Maybe some kind of a vanilla demo emulator instead of a something that directly attempts to port demo compatible mode into more advanced source port. The whole nesting doll situation of doom port within a doom port would be bit silly of course. Starting point should be rather simple, isolated vanilla demo player that could rather easily be integraded into any source port or pretty much any type of software without too much work. That could be then expanded into actual gameplay modes with specific compatibility simulation and renderer features wrapped into isolated module. And things like game logic and rendering could be given ability of existing as separate modules but it's probably easier to require custom module that could combine desired game logic and rendering features. Modules would either replace underlying engine functionality, or probably more practically just run completely on top of the host engine, emulated or as engine within a engine. But again, my base idea is that a vanilla demo player could be potentially made into something like a video player codec and this then could be easily integraded into GZDoom.

You seem be talking about all the game modules using generally the same expanded feature set which would require things being kept more in the sync. But my idea would mean that the modules would be both more separate from eachother and mode standalone, often lacking even big portions of the expanded feature set or replicating them in standalone manner eliminating dependencies of the features built into the underlying engine. I am seriously just curious about the potential roadblocks. I know I am taking your time but any serious discussion about my idea would be welcome. Doesn't need to be related to GZDoom, just you sharing your general knowledge as a programmer. Great thing about open source is that you are not required make a EDGE-Classic module but someone else that happens to be interested could adapt it into being a module. And if modules would generally universal, almost any source port could very easily have EC support, even those not based on ZDoom, or Boom. I used term neuroatypical because of I don't have a official diagnosis but alot of signs do point to that I am wired in pretty untypical way. For me atleast neuroatypical does seem to communicate well that some things are definitely different without making a claim of being actually valid for classification of a neurodivergent person. Fair point. But there issues with RetroArch's approach that could justify a Doom specific version of the same concept. The native framerate of RetroArch PrBoom is 60fps, basically breaking demo compatibility and generally being very inaccurate, Not to mention PrBoom being simply an ancient source port these days. As far I know, part of this comes from emulators being the main focus and all cores do technically run at native 60fps. And another difference would be how much more intergrated the modules would be underlying engine instead of the engine being just a frontend for starting several different source ports. And in general I would like to move away from idea of all-in-one source port for now and focus more on modularity being cleaner and more flexible way to handle compatibility support in general.

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. 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? 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?

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

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

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.

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

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.

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

I love the original Quake monster animations, 320x240 rendering resolution and sofware mode visuals. And even if i didn't, it would be highly irrelevant because I am not claiming I play more appropriate way than anyone else. I love playing vanilla maps with Complex Doom using Zandronum and can freely admit that this is pretty low in the appropriateness scale, these maps definitely weren't meant to be played this. And that is the whole point of a spectrum, everything counts and is valid, it is simply about amount of how much of the original work of art is respected and preserved. Optimal parameters for this exist only very rarely, like a movie theater experience without some idiot not knowing how to behave in public, but theater viewings are still the intended format. Music is more flexible because it often lacks the visual element. Concerts are completely separate from listening song from album or radio because whole element of being part of the audience existing only in concerts, the same element that also makes seeing movie in theater to be the intended experience. And the fact that video games do require deeper interaction with the work of art, it is much less flexible medium compared to music and movies. 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.

The crispy visuals could be easily compared to filmgrain, some people hate it but many people really love it and without it, things do usually look pretty sterile and artificial. I might be a weirdo but I never understood people hating aliasing, especially when the game was meant to be displayed in 640x480 or lower resolutions. Being able to see the jaggy edges gives a videogamey look to the visuals and filtered image generally just too fake and artificial to me. Let me guess, you don't play many other retro games from that era, especially console games? What updates Super Mario World needs to be playable in the modern day to you? For me personally, why try to fix something that isn't broken. I like to play Doom same way as I like to play all my other retro games. It is a spectrum, not a binary. Just like with every artform, Doom content is made with specific intended experience in mind, the most appropriate way to experience the creative work, like movies are made to watched in a theater setting. It is less appropriate to watch movie meant for theater viewing on your phone but it may fit better for your personal preference than the appropriate, intended experience. But it is important realize that this can also effect your interpretation of a piece of art alot. And it does show some lack of respect towards the artist and their work.

Atleast my own experience is regular Joes often do not generally care either way and often go more with what happens to be most accessible to them. There are definitely ways that extra features of GZDoom has more mainstream appeal but there are plenty of actual regular Joes that don't know how to setup something like that. So in the end, it becomes more natural for them to use the official ports with more vanilla based feature sets. Regular Joes are likely just not care are often just simply willing to listen those people that are bigger part of the Doom community and likely know better what things make a better source port. And there are alot of overlap between all kinds of people in Doom community. Plenty of purists do casual play on GZDoom and plenty of GZDoom use official ports or simpler source ports. I feel like it is far more common to find mainly ZDoom port users that do not use any port with a demo compatibility that it is to mainly classic style port users that also wouldn't use ports lacking demo compatibility. Alot of people in general use GZDoom as all-in-one way to play Doom instead of it's advanced features and switching ports when it would be more appropriate for the content currently being played, so many people will not even bother with compatibility settings unless something very clearly becomes broken by wrong settings. No regular Joes are hurt by demo compatibility and if they want somethinh beyond that, thet already have GZDoom and other ZDoom based ports. And there is no group in the Doom community demanding for every source port to be demo compatible, Doom Retro gets away just nicely with not being demo compatible. New projects fail more because of failing to built up hype or there just being too little of practical need for them. Sure, that is probably why I had not ran into ZDoom stuff much back in the day. I did also transition to using Linux and not having to access to playing Doom for few years after the days of using Doom Legacy. I only got back to Doom once I started to use Ubuntu and discovered PrBoom. I might be mistaken but didn't Brutal Doom only really explode to the mainstream much later? I feel like things started to get really big only after version 18ish with version 20 being probably being the biggest success. And for me it seems that GZDoom reached it's modern popularity around the same time, with development of ZDoom ending not too soon after that.

It could be just my personal journey with Doom. I went from using Doom Legacy in early 00's to using PrBoom(-plus) in late 00's so smoothly that I probably missed the level of popularity that ZDoom had during that time, I personally atleast barely even knew about ZDoom being a thing and definitely didn't organically find any reason to try it. So it might seem to have been more of niche source port to me than it was actually. But I did say GZDoom and the truth is that it's popularity is at whole another level, with Brutal Doom being the thing that pushed GZDoom to it's almost untouchable status in terms of popularity. Also, outside of popularity, GZDoom having almost no limitations for modding does make it very different beast than ZDoom in 2005. There is simply less room for innovation because GZDoom already does almost everything imaginable that reasonably can't be demo compatible while still being based on Doom.