Yet another retro source port?

[SanyaWaffles]

Turned out I all ready had it downloaded. Thanks for reminding me it existed. I like the look of these textures already.

[drfrag]

I still own a couple of 486DX-33 but i never use them, Doom ran well but for later Doom 2 levels you had to use low detail.
I downloaded megawads and those 11 and 7 level wads not single maps, with exceptions of course.
Recently i've played another pretty good megawad, Sinergy (unless i'm wrong and was another one). But of course with LZDoom and Brutal Doom.

[Graf Zahl]

I But of course with ... Brutal Doom.

Heretic!

[drfrag]

Yeah i know, hope RUDE helps me to quit playing BD.

[drfrag]

I've been doing some local MP testing on the same machine and the result is that on PRBoom+ there's severe mouse lag but only for SDL1, the SDL2 version (UM) has minor lag for green and it's perfectly playable. Shirt colors for other players are wrong tough, all are green.
Edit: seems it only happens with uncapped frame rate.
Chocolate is not as great as i expected, seems there was an original vanilla bug and there's some serious lag for indigo. There's an enhanced sync code i've ported (-newsync parameter) and that's better but there's still some lag for indigo. In the old days i played with a friend using a null modem cable and we didn't experience that problem AFAIR but i had to set detail to low on my 486 or else he got slowdown on his pentium. May be i was experiencing that lag after all i'm not sure, the game didn't ran great on my DX4 with an isa card. Then i got a VLB card but right after that i bought my friend's pentium.

[ETTiNGRiNDER]

I'm probably not really the same type of vanillist that's being called out in this thread but I'll throw in my 2 cents, I never really gave much of a damn about demos or speedrunning, and have kind of ping-ponged back and forth between here and Doomworld, but what put me off of ZDoom and into targeting maps for vanilla was (in addition to a few other annoyances that have since been rectified for the most part) in big part due to this dark age that happened in ZDoom some years ago when a bunch of old mods were broken and devs at the time seemed to pretty much just flip the bird at it, citing "reliance on old hacks that we no longer support because it interferes with the new features" or something along those lines (Wolfen would be a good example of one that was fairly high-profile at least among Hexen fans, I also remember having issues when I wanted to try Goblin Doom but missing out on that one is... rather less of a loss). Makes me think of Hexen Mage Tower where they make their weird Doomsday mods but then say they recommend you use this particular old version of Doomsday to play them. That's kind of a fucked place to be. I think that part of the appeal of PrBoom (and the resistance to adding stuff to it) comes from that direction, if you work with a "dead" target then you can be relatively sure it's not going to break because someone added some new feature that messes with it. And at least if you target the DOS version you have the option of a DOS emulator to fall back on if all else fails, which is a lot less likely to disappear or become unusable than a particular version of a particular port of a particular game. Having the same level of emulation for older Windows stuff hasn't really materialized to the same degree.

If there would've been a Boom/PrBoom equivalent for Heretic and Hexen I probably would've been all over that. I remember wHeretic was a thing back in the day and at least had the limit removal aspect, but it kind of dropped off the map ages ago. For the longest time I've held the torch for Eternity to finish support already but they've been promising that it's "almost done" for like 10 years now and at this point I think they'll probably have it in at around the same time Mordeth TC releases i.e. never. Insert wisecrack about the port being aptly named here.

It seems like these days a lot of things I took issue with in (G)ZDoom have since been improved on, those old mods were made to work again, and I can still run the mainline port despite my computer being pretty old, so I guess my interest in possibly making stuff for it is somewhat returning, though I still feel kind of wary about how reliably mod/hardware support is going to stick around.

[Rachael]

@ ETTiNGRiNDER:

I am not Graf but I can tell you that supporting old 1993 hacks with more modern code is annoying to say the least. Even the planar flood-fill where an upper/lower line is missing a texture is an example of that, even though GZDoom has had ways to deal with that for the greater majority of its existence.

What really doesn't help is that new hacks keep getting discovered (ie "Linguortals", that one hack where anything crossing below the -32768 z-reference gets teleported to the top of a sector due to overflow, I forgot the name of that one, etc), and yes, people rely on these, even though the original Doom levels never actually used the majority of them, which means they clearly were not intended. If your map depends on unintended behavior that even Carmack could never have anticipated with the original source code, then yes, it will break when the code this behavior depends on is improved or changed.

And that does indeed leave you with two options: Either use the newer version of the engine where the behavior you actually want is intended and there are ways that you can actually use it, or be stuck with vanilla where the features you want are extremely limited and rely on such hacks in order to function properly. What a lot of people don't understand is the novelty of exploiting bugs in vanilla wears off very quickly. That is, unfortunately, just the way it is.

[ETTiNGRiNDER]

Those mods I'm referring to are ZDoom mods (for the older versions), though.

[Graf Zahl]

Since you mention Wolfen, it fell victim to a bug exploit, some misnamed inventory items in the old ACS inventory code. The mod got released just right around the time when this bug got fixed.
LilWhiteMouse was aware of that problem and promised to release a fixed version but it never happened. What do you expect us developers to do in such a case? This problem needs to be fixed in the mod because the only alternative would be to add a hack to the engine. The mod also played very loose with actor replacements and several thing in it never worked right because it wasn't afraid to use rather gross hacks to achieve what it intended.

What really doesn't help is that new hacks keep getting discovered (ie "Linguortals", that one hack where anything crossing below the -32768 z-reference gets teleported to the top of a sector due to overflow, I forgot the name of that one, etc), and yes, people rely on these, even though the original Doom levels never actually used the majority of them, which means they clearly were not intended. If your map depends on unintended behavior that even Carmack could never have anticipated with the original source code, then yes, it will break when the code this behavior depends on is improved or changed.

The good thing here is that these exploits do not work in any advanced port so the sole audience for them is the hopeless hard core of vanilla enthusiasts. I already made clear that I won't support either of them because they are pure novelty exploits with little to no usability.


But let's not forget one thing about early ZDoom: Up until 1.23 it was a very buggy engine and it took a good part of the 2.0.x range to get it to a stable state which was reached around 2.0.60. This was all before I got involved in ZDoom's development - the first DECORATE appeared in 2.0.61 if I am not mistaken. Of course there were several mods of this early time that got broken because they depended on bugs. In some cases a compatibility setting helped but when broken ACS got into the picture, no engine side workaround can do anything about it. Wolfen was released right around that time and it was one of those mods that pushed that fragile engine a bit too far. So please do not use examples from this old time as examples for how development has been conducted later, the ZDoom of that vintage really has little in common with what's there today.

But even now, no developer can foresee all the exploits some mappers use without ever thinking about the ramifications. A good example would be the dynamic light attachment exploit that got broken when a long overdue refactoring of the light management was done. In that case I had two choices: Revert everything and keep mods working or keep the change and break a handful of mods. Sometimes keeping the hack in will forever lock the engine into a bad design with no chance of ever getting out of that quagmire again. The lights were one such example where it was either to fix the design or to forfeit some desperately needed reorganization.

[3saster]

While your concerns about old mods breaking were relatively valid, I'll give the GZDoom devs this; they have been in the last few years making a much more conscious effort to keep backwards compatibility. On top of that, they have been adding more features to ensure gross hacks aren't required, to avoid this problem in the first place. So kudos to you guys!

[SanyaWaffles]

Honestly it's frustrating when people depend on buggy undefined behavior and then expect everyone else just to be okay with keeping it that way. I honestly have no qualms updating either DD1 or DD2 if something is broken because I misused a feature. I get backwards compatibility is needed, but sometimes it's frustrating when it's gross hacks or a coding error holding that together.

Admittedly even GZDoom falls victim to this - One example is the PrintBold function in the ZDoom family of ports where the original behavior was meant to print everything to all players, but due to a coding oversight it uses Print instead therefore only printing to the activator. Instead of using the intended behavior by default, it relies on me having to manually state I want to use the correct behavior.

To me I think most people intended using PrintBold in the correct way because it's always been indicative that's what PrintBold was intended to do. Using it in any other way was not correct.

Since I barely use ACS for HUD-related stuff anymore it's not a problem... but I do feel for older projects most people would have intended PrintBold to have been used correctly.

I feel a better way would have been to do a Level Preprocessor - either the old compatibility.txt or the new ZScript versions... that sets the setting to use the old buggy Print functionality as opposed to you having to opt into using the feature properly. However that's not exactly doable now, the MAPINFO'/Gameinfo block option has been around for years and removing it would cause further issues yet.

A bit frustrating, no offense to the devs of GZDoom intended.

[Graf Zahl]

A far more severe thing is the texture coordinate mess for scaled textures. And only because, when the issue first came up, instead of fixing it it was decided to consider it a feature, not a bug, and add the fix as an option - never mind that it has devolved into an utter mess to maintain as time went by. If I could just remove that crap it'd remove a major annoyance from the engine, but I have no idea if this will break some mods.

These are the design mistakes that will haunt us until eternity. But maybe it's all something that's not even relevant. I simply do not know.

[SanyaWaffles]

The thing is you could have 99.9% of the projects out there not use the buggy behavior and prefer the fix by default but all it takes is that .1% that relied on it and someone out there will cry foul if it's fixed.

[3saster]

The thing is that if it really is .1% and someone does cry foul, GZDoom's compatibility system is sophisticated enough in that it could just turn the buggy behaviour back up. The problem is in cases where many mods DID rely on the broken behaviour (I'm sure Graf can give an example), and thus you can't fix the default behaviour anymore.

[Rachael]

Except that GZDoom's compatibility system can't handle ACS or ZScript errors, yet.