Graf Zahl

That's not what I meant. I also tinker with old software, some of which cannot be compiled as 64 bit. What I mean is modern software that still sees double releases for both architectures. It's not just Doom ports, but also countless utilities or libraries. I can somewhat understand it for the libraries or even for applications whose code is too problematic to port to 64 bit, but doing it for an application that also gets released as 64 bit seems a bit like wasted work.

Done. I think if anyone is interested in forking this, DSDA would be a better starting point anyway.

The last time I used 32 bit was when my old system broke down in 2012. Even back then it was virtually unthinkable to buy a 32 bit OS with a new computer. Yes, essentially. But often, to make this old software work, you not only need an old OS but also equally old hardware. The more important question, of course, isn't whether people still use 32 bit OSs but why so many developers cannot leave this fossil platform behind - essentially doing double testing duty to make sure that something for less than 1% of the potential user share still works.

This is probably the most frequent topic around here. Had you done a search you'd have found 100 or so threads asking the same question.

Hands of Necromancy as well: https://store.steampowered.com/app/1898610/Hands_of_Necromancy/

UDMF and Hexen line actions are essentially the same, except for the value range. Hexen only has byte parameters which forced a lot of compromises on the map format while UDMF extends all to full integers. Regarding 'inconvenient', I'd say it's a poorly chosen term. What has happened in the past is that some vanilla mappers voiced the opinion that remembering one value was easier than all the parameters Hexen additionally needs. Oh, you are wrong. There's always demand for new stuff. Where 'new' obviously means something that did not exist before. That's really the problem with another map format. As things stand it's not something any current port may benefit from. Those which already support UDMF already have something equivalent, and the rest which hasn't adopted it yet is just as unlikely to adopt another different format because their intended scope is too different. I can't really see where this might fit in with ports like Crispy or Woof, for example.

I'm even less in favor of binary formats for actor definitions than for maps. We should be beyond the state where data needs to be compiled before use. It would make sense if the performance gain would be significant, but as things stand, the same applies here as for maps: The actual parsing is not the main driver in execution time here. Processing the data into internal structures is. Well, parsing of the actual map data may be twice as long, depending on the quality of the parser.. But like I said, loading a map is not merely parsing. You won't be able to accelerate the rest. That's where dynamic arrays normally come in. You know, they are quite standard these days. Yes, they are, and on top there's DECOHACK to make it nicer to edit. Which all has the nice property of being really universal. What you propose will require a gargantuan effort by virtually every player involved. Then please define a baseline of where you want it to run. It doesn't strengthen your point if you just ignore or dismiss opinions that don't fit your view of things. Just a little hint: If you don't get the port authors on board and listen to their feedback you will end up empty-handed.

Binary (for 'faster parsing') will make the whole thing DOA. You totally overestimate the time that is needed to parse text files. The downside would be that binary formats are hard to extend if the need arises. UDMF was designed from the ground up to add whatever you like. Parsing text really isn't the bottleneck. When I stress tested ZDoom's UDMF parser on a conversion of the first ZDCMP the pure text parsing was less than half the map setup time. Things like texture lookup and actor spawning were a lot more costly than scanning a few MB of text Overall, I don't think this will work out. It's too much change for the sake of change and putting questionable performance concerns before ease of use. The only thing in here that sounds interesting would be a sanitized line axtion system. Concerning the blockmap, no it makes no sense to have it in the map, it'd be a lot better if we had a reference implementation of a blockmap generator that could be included into all interested ports. Generating a blockmap is so fast that loading it from a file makes little sense.

That's not how bean counters think. If keeping the games up they generate some cost, even if it's just tech support. And these types never like that, they are virtually incapable of factoring in secondary effects. This makes no sense at all in the movie business. A streaming service lives from a wide offering - narrow it down and you WILL lose customers and their revenue. So, since this harms their product, there must have been some costs involved that are higher than the projected losses from the diminished offering. Well, that it definitely is, no matter what precisely the motivation is, but I doubt it will work. The negative PR from these actions will also cause some long term damage that needs to be factored in.

Even though it's not the most accurate, I prefer the "Doom" mode, its light diminishing looks more natural than the software renderer's. Still, no contest with Build - its light diminishing is so poor that I deliberately added a different option later to have something better, By comparison, GZDoom's light modes come from a time when there were no shaders and an approximation was all we could do.

ZDoom requires FluidSynth 1.x. I think most distros have long discontinued that old version and only provide 2.x This incompatibility is why I integrated FluidSynth into ZMusic in source form to avoid the inevitable problems with its next version jump.

No big surprise here, neither on the gaming nor the movie side. This all plays out the way it had to be. Everybody wanted to have their cake and eat it, too, and now the costs are exploding. Even though I have little sympathies for Steam, things were better before both game and movie studios got carried away by dreams of endless supplies of money(TM) from launching their own services, just having one or two independent ones, keeping the costs in check. Now we got the same amount of content but 5-10 times the cost - and the inevitable result is removing titles from the library that take up space but don't bring in much revenue.

While part of this has already been answered let'e elaborate a bit from a developer's perspective: Like the post I made over at the ZDoom forum already hints at, with modern hardware there can be a significant difference in performance, even with a Vulkan renderer just emulating OpenGL's state machine. This is precisely where GZDoom is right now, the entire code is geared towards OpenGL's setup and does not really take any advantage whatsoever of Vulkan's stengths. Surely we could continue on this path for a long time but what would be the benefit? The only ones profiting from it would be users of really old and outdated hardware that'd be better served by a leaner port with less features as these systems often cannot run the demanding maps anyway. It's also an ever diminishing return on investment as this user group will steadily shrink. On top of that our surveys have shown quite clearly that the users of high end graphics hardware are far, far quicker to upgrade than the users of low end hardware. All this has caused the strange situation that we currently have 90% of users on Vulkan capable hardware, 1% of upper range pre-Vulkan hardware and 9% on really weak pre-Vulkan integrated GPUs. Those latter 9% are best served by the GLES backend, and should we go forward with making the engine more Vulkan friendly, splitting this off into a low maintenance LZDoom successor would be the best course of action because trying to keep everything under one umbrella would be a disservice to the users of what constitutes a modern setup and forfeit future proofing the engine for upcoming hardware changes. The regular fully featured OpenGL backend's days are numbered, though, I do not see this survive for another year due to the extremely low user base that can benefit from it.

You are forgetting something very important here: Most mods made for GZDoom are not independent games but gameplay mods that are supposed to be run with Doom. Why would you cut off these people from what they need to do their work? There's also the - little - problem that this would pretty much kill developer contributions for good. If GZDoom loses the few people that actually do contribute code there won't be much left - and these people all come from the gameplay mod scene. They want Doom AND they want features, if one gets stripped they'd be gone.

Here's the deal about it: We have reached the point where it is impossible to run Vulkan and OpenGL off the same renderer. If we do there is no way optimizing Vulksn, if we declared OpenGL the primary API that's considered the gold standard we'd lose the main contributor to the Vulkan backend. The only way to go forward is to completely separate them and then put OpenGL in low maintenance mode and feature freeze it. Otherwise either the low end or the high end gets compromised because the techniques needed to serve both are too different. It was for the same reason that 4 years ago OpenGL 2 support was ended. It also was far too different from what more modern hardware needs and when being faced with having Vulkan support or continued GL 2 support, Vulkan won. We currently have the GLES renderer for the low end and it surely works better than LZDoom, but that's merely a stopgap measure to ride out the rest of OpenGL's life. Sigh, that stuff again. It's a simple case of being a lot more complex than all the other ports. I could get it back to the performance of simpler ports if I took out all the features again, but then nothing would be gained, wouldn't it? That's simply caused by fixing some broken math, not by changing the physics.

What do you even mean by that?

NVidia's OpenGL drivers have seen some degradation recently. I noticed this myself just today whan I replaced my Geforce GTX 1060 with an RTX 3060. I'm pretty sure it's not the hardware but the driver causing the issues, though. OpenGL is on the way out, and it is no surprise that driver support will get worse as time goes by. You may think so, but I have seen so many badly calibrated monitors that this is just wishful thinking. The lighting mode is on a setting that ensures best performance. Software lighting can really affect the low end hardware with weak shader performance. We are only now slowly reaching the point where this hardware drops below the point where we don't have to care anymore. Also, since this can be set through MAPINFO it surely can't be an issue, if you really need a specific lighting mode for your map.

That is actually utter nonsense. If it used Quake physics it wouldn't be able to play Doom anymore. It's still Doom physics code with all the poor design that gives it its unique quirks. I think what you experience here is actually the input code being different, not the physics. Virtually all other ports use SDL, while GZDoom uses Windows directly and I have heard from several people that this shows in input responsiveness. Idiots being idiots, yes some people would do that. I couldn't care less. Whatever you may like the next person may not, yet you assume that your preferences are what the majority wants. Things do not work like that and it is impossible to satisfy everyone. You also cannot guarantee with ANY port that people will see what you intended. Not with Doom.exe, not with Boom and not with GZDoom. Every monitor is different and whatever display you tweaked your visuals for will be different from the next display and what looks good on one will look like crap on the next one. Some are brighter than others any you either need to amp up the gamma or change the lighting mode to make things look right, and the color temperature is also different between monitors. I have seen maps that were designed for monitors so bright that the only way to play them was to change the light mode to 'bright' on my properly calibrated display. (BTW, the Build lighting mode is there because the code exists. Remember: This is available as a map option if a mapper is so inclined to use it.) We'll probably do that for next version. The downside here is that some Vulkan drivers of early generation integrated GPUs are not that good on Vulkan, even if they support it. 2x faster is a bit unusual, what GPU was this? It doesn't - but let's not forget that the most recent non-Vulkan compatible hardware is 12 years old by now. It is so far beyond the baseline of how a current system - even low end - looks, that it's not a good idea anymore to use it as the default, especially since even on NVidia's current hardware OpenGL is starting to show the first cracks in its support.

Now THAT might pose a real problem because it would actually break existing and still working legacy software. Who knows how many older games are using MMX code somewhere?

ROTT yes. Wolfenstein not so much. The engine is just too limited and after a handful of levels boredom quickly sets in. There's just not enough variety in the level design.

What's up with the reading impairment? Did you even READ the original post?

It's about time to excise all that old baggage. But wanna bet that some people will still complain? >D

It was posted here some time ago - I haven't found the thread yet, the search terms are too broad. :(

At least it's not as bad as trying to play Duke Nukem with Blood's assets in the same folder... :D:D:D

Good luck finding a developer willing to do that. It sounds easier on paper than it really is and skilled people are a rare commodity.