Graf Zahl

As long as these conditions are only being used in 'if' or 'while' checks - which are statements, not expressions, the worst that can really happen is that the stack doesn't get fully popped. The stale value that remains never gets used anywhere, and most scripts do not run long enough for this to become a problem. I think the only ways this could really cause problems is to do such a check in a loop where the stack gradually fills up or to assign the value of this boolean expression to a variable, but that's something that rarely happens in simple scripting code. My guess here would be that none of the scripts in vanilla Hexen maps had sufficient complexity to let this manifest as error, and even if it did there's still no guarantee it was perceived as a misbehaving script. As for active modern ports, Doomsday has not fixed this, and neither has DSDA-Doom. Judging from this I think it has never been compensated by anyone using Hexen's original ACS code. But Doomsday has never been a popular port for mapping and DSDA-Doom is rather new, so historically there has never been a port that was both sufficiently popular for mapping *and* used the original interpreter. I think the reasons this was never discovered before are a) it is only relevant for Hexen which has never had Doom's popularity b) in most use cases this won't do anything perceivably wrong and the script will terminate before this ever becomes critical c) it was never relevant for ZDoom's ACS interpreter which uses stack indexing instead op popping to access the values for these operators. Presumably the same applies to Eternity as well as its ACS VM is a complete reimplementation, too.

I stay away from the digital cesspools (mainly Twitter and Facebook) so despite all the computing stuff I stay grounded in the analogue world while enjoying the convenience of digital as well.

I prefer maps with lots of smaller enemies over those with less bigger ones. And I generally avoid maps which treat the Revenant as a cannon fodder type of enemy.

What I miss most is the kind of mods which were made for early ZDoom. Mods that did not go overboard with scripting but tried more to use ACS to replicate gameplay like Quake/Quake2. For me these were a big part of "rediscovering" Doom after moving on to more recent titles after 1995.

That's the same for all ports - the main rule for demo compatibility is to not alter gameplay mechanics. Period. Other ports solve this by adding checks to the fixed code to execute the original if a demo is being played, with special check for each known demo format. The demo is just a recording of network actions, essentially recorded keystrokes. It knows nothing about map features, i.e. the demo has no idea of - nor does it have to care about - slopes, 3D floors or portals. All it knows is that the player is to be accelerated by a force of xyz in direction abc, or is holding down the fire button, using an inventory item, opening a door, or pressing a switch, etc. If you want demo compatibility you have to adjust your entire editing philosophy to it, i.e. any time you touch the game code or the DECORATE scripts you got to add a fallback for every single change, retaining the old logic, regardless of how minimal it is. ZDoom's demo format is no more or less stable than Doom's, the difference is that we never bothered to add all the checks to the game code to retain the old code path.

Well, ok. After looking at Dhewm3 I found the commit telling me everything about what's important: "Fix compatibility with Mac OSX 10.4 and 10.5 ", committed two months ago. In all honesty, when I see that I'd also take a hike and do my own thing.

Demo compatibility is not about the format but about not altering the gameplay mechanics. The format is mostly the same as original Doom - it stores the network traffic in a file, but since ZDoom sends a bit more data the packets are a bit more complex.

In that case you should ask Dhewm3's maintainer what they want. Is Mac support so bad because they want to keep it operational on this old hardware or just because nobody has maintained it. With many projects the main problem is lack of interest by developers. See, you are basically the only man in town who seems to care with the ability to change things - so if you can help these projects to be up to date it'd help the community a lot more than creating yet another fork which most interested users are unlikely to ever notice. I mean, look at the download numbers for this: https://tooomm.github.io/github-release-stats/?username=atsb&repository=gbDoom3

As a very first thing how does it crash? Do you get a crash log? If yes, save that and post a link to the saved file. Second, what's your precise system specs? i5 can be a lot, the name has been in use for 10 years now for vastly different types of CPUs.

There's already a copyright message in the startup log, back in the day that was sufficient, have they changed their requirements for FMod Studio?

What do your source and your INI say about "mod_dumb"? That's the CVAR that controls which player is used, in 2.8.1 there were little provisions for OpenAL so it may have the wrong value.

That library may be old and unmaintained but module music has been used quite frequently in ZDoom mods. What's the problem with it? It has been working fine for all those many years ZDoom had been using it.

Haven't you removed DUMB? Well, there's your answer. Void uses an XM module but without anything to play it of course stays silent.

These are not good settings because they introduce a lot of aliasing. The only really useful ones are Trilinear for filtering on and "none (trilinear)" for filtering off. The latter gives you square pixels but still retains most of the benefits for reducing aliasing. Switching anisotropic and multisampling off will also only introduce ugly artifacts, although with filtering fully disabled it probably does not matter much. It may be worth thinking about removing the other filtering options - the full set made sense 15 years ago when there was a performance difference but these days what most users really want is filter on/off but otherwise use the best quality option

Even "inside of GZDoom" it hinges on only two people. Should they quit the game will be over. This is something I'll tag along as long as it won't cause additional work, but the user share with the last survey was less than 2.5% - virtually unchanged since 2018.

Very much the same as ZDoom - it still contains the old software renderer and the OPL code among a few other things with a "not for profit" license. So right now it's not viable. It also doesn't have the OpenAL sound backend yet. So everything's still in the same state as 2015/2016 before we started a concerted effort to rid ZDoom of these licensing obstacles. Says you. Edward is right, the new renderer with its lightmaps was the main selling point of the remaster. It may not have been everyone's taste but you have to be somewhat objective about your target market when making such decisions. If you want to *sell* a game these days, 8 bit software rendering isn't going to cut it - you suddenly reach customers outside the community here with vastly different expectations. And you have to consider them to avoid some backlash and potential review bombing that would sink your game. So what? Discussing technical issues with Apple platforms is now considered "bashing"? Although I do not develop games for them, at my job iOS is my main target but Mac is also quite important. And the maintenance hassle enforced by Apple's constant changes of guidelines and requirements is something that costs a lot of manpower and time. We can afford it with our business oriented software - but for entertainment software things are a bit different. If you have 20% of your maintenance work on Windows, another 20% on Linux and the rest on Apple, this can quickly eat the rather slim profits that may be had there for the measly few percent of market share the platform provides for PC gaming. OpenGL getting the finger is also not going to help. As long as Vulkan can be used through MoltenVK there's still a chance of keeping support alive - but don't expect anyone to waste the time of writing a native Metal backend for their cross-platform games. That time is better invested in cooler features on Windows which then will be effortlessly available on Linux, too.

It is very apparent that you do not understand ANY of the concerns Kinsie and I raised. What you are doing here is advertising a clearly abandoned engine as a viable choice for mod-making. How do you this expect to work? Anyone starting with this is left to their own devices when something goes wrong. The "support" from zdoom.org will be "Upgrade to the latest GZDoom" and that's it. So far, so bad. Now imagine that imaginary mod maker makes use of GLOOME's new features that aren't in GZDoom and runs into a problem with this engine - and you can rest assured that they will. Who to turn to to get it solved? There is nobody! So they are screwed. In summary, GLOOME has some historic value for being the first GPL compatible fork of ZDoom - but that's where it should remain. If you want to maintain it and address issues reported by potential users that'd be fine and a valid offer to promote its use. But I am fairly certain that this is not what you want to do. As it stands, you are promoting an abandoned engine. Its creator has no interest in maintaining it and the creators of its parent project have neither. It also does not matter that it "runs fine" on Windows 10 now. Many games of the past also "ran fine" on the hardware they were developed for, but once that hardware started changing they stopped "running fine". I am left with several old games I can only play by booting up my ancient 2004 computer with Windows XP and a Geforce 6800. The same risk applies here, especially when you consider that OpenGL is on the slow way out. See, and here's where things get scary. You are just peddling a project you do not control (and actually nobody controls!) to people who don't know better. In the business world such actions would be classified somewhere in the realm of fraud.

Maybe you haven't run the software I need at work. Stuff constantly breaks when the OS gets updated. 10.13 to 10.14 was the worst due to the 32 bit thing, but every time an update is due something breaks and needs an update. Of course these updates take time to arrive and I'm just waiting it out for as long as possible so the software that broke has a patch available. I can't afford, for example, when the various VPN clients I need run into Apple's next newly erected security barrier and block me from accessing customer systems. That's always the stuff making the most problems. Good to see that we do not disagree about the state of things. But that statement "in the future it will be pretty much meaningless." should really serve as a red flag for potential users. Yes, the port deserves a place in history as the first attempt to create a freely usable fork of ZDoom, but let's leave it as that and not harm potential game makers with an engine that, for all intents and purposes, is abandoned, outdated and comes with no warranty and support whatsoever.

I have to second virtually everything Kinsie pointed out here. This engine is more than half a decade old (the last relevant commit was at the end of 2015) and has seen absolutely no maintenance over that time. We do not even know what kinds of technical issues it may show on modern systems. It is based on an ancient OpenGL version, uses features that have fallen out of favor of GPU programming these days and uses a beta-grade sound engine - because OpenAL was added just before GLOOME was forked, the sound backend here is virtually unproven and barely tested. Most of that refinement and fixing happened *after* ZDoom ceased operating in December 2016. Until then, FMod had still been the actively maintained primary sound backend. This also doesn't even have a Vulkan backend so it also comes with all the known performance penalties on AMD and Intel GPUs OpenGL implies. And from what I heard, OpenGL is seriously compromised on the M1 as well with a hefty performance penalty compared to Vulkan through MoltenVK. So, if anyone picks that up, who is going to do technical support for it? Because over at zdoom.org all you're gonna hear is 'we cannot support a 6 year old and abandoned-by-its-original-maker offshoot'. So, are you two going to provide that support? No? In that case you better stay away from peddling a project that isn't even yours for independent game-making. And please don't say "It's old - it's safe". There is no such thing as "safe" in software development when it comes to the multitude of hardware it's going to run on. Somewhere out there someone will have problems and they'll first contact the maker of the product they bought or downloaded, and from there will get referred to the engine providers - which in this case is not the people at zdoom.org, but Redneckerz and Gibbon. Last but not least - have you *tested* this on all platforms you advertise? Here's a serious issue that was discovered on GZDoom affecting the M1 due to some badly assumption in a third party dependency: https://forum.zdoom.org/viewtopic.php?f=7&t=71303&hilit=apple+m1 That dependency is present in exactly the same form in GLOOME so it is probably affected as well by the linked issue. So this is the very least you'd have to sort out. What he's getting at is that in each new major version Apple removed something or introduced a new incompatibility. macOS 10.14 broke most 32 bit support and macOS 10.15 saw complete removal of it. Libraries get deprecated all the time until they formally get evicted 5 or 6 years later. They need OpenGL for supporting professional CAD software but not for games, and like I pointed out above, this already shows on the M1. It's only getting worse from here on. Expect OpenGL on Mac to be a dead thing for games in 5 years at the very latest. I am fairly certain that once they have migrated all mission critical business software that still depends on OpenGL to Metal it will be retired quickly afterward. I had to deal with macOS updates breaking stuff at work for the last 4 years and it's bad enough that most Mac users try to delay the OS update for as long as they can afford. Which with Apple is normally less than a year before something happens that makes an update necessary.

Something's broken here. Well, we are on Linux, aren't we?`:P Yes, sure. It's just, when I check my Program Files folder on Windows, the only larger chunk of redundant code is Git which contains tens of executables which are 3MB large each. Obviously they all link one huge static library. But in the end all potential redundancy in there may add up to 2GB - the entire folder's size is 120 GB. But it's funny that you argue for the lowest common denominator here to refuse adding some sane application mechanics. What do you want? Get people onto Linux or just preserve the system you personally like? I think by now it is clear that the current way does not work for the general public. It doesn't even work for many software developers, and as I pointed out, the number of technical issues with GZDoom is disproportionately higher for Linux users. And with that, in the end shaving 1 GB off your hard drive storage means absolutely nothing if some software stops working and its developer decides that it isn't their fault that there's no stable set of libraries available. We have good reasons to statically link several critical third party dependencies in GZDoom to avoid that bottomless pit of dependency hell.

Reality check: Windows does precisely that and its HD space doesn't implode. You are also forgetting something here: With most big applications the vast majority of storage space is application assets or app specific code, not those libraries you talk about. Why are you so stuck in the past where storage came at a premium? These days even 1TB SSDs are dirt cheap. I'd never trade system stability to save myself a few GB of hard drive space. I'm sorry but the entire notion is just the epitome of being amateurish.

A frame rate limiter limits the renderer, not the play code. So unless its implementation is broken it will not affect demo sync at all. Normally it is just a short wait after having rendered a frame.

When all else fails: Try to make your point with exaggeration and lies!

What I've been saying all along. Of course that must also imply that all mandatory application data must be part of the package as well, and not be scattered around the directory tree, far away from the executable. That's also one of those things where Linux creates too much mess.

Just thinking about it - who, aside from Apple would dare selling a $2500 computer with just 16 GB of RAM and a measly 512 GB SSD...? For that price I'd expect double that amount on both accounts. IMO that's a story of the past. I've heard some real horror stories about the later Mac generations after Apple decided to make them unrepairable. Yes, as long as these things work, they are good - but how long are they going to work and what will happen if they stop working?