Graf Zahl

Regarding Dear IMGui, it would be possible. There is a software renderer for it. The actual problem here is the same as the startup screen for non-Windows platforms: Nobody is willing to do some work here. The current situation has been existing for nearly 15 years so if it was that important to solve this on non-Windows, where's the contributors? I already refactored the startup code that all that is needed is a simple window the game can blit a bitmap to and resize it. Not a single thing more, and yet we still haven't gotten anything working. So for the startup all I can offer is to redo the entire thing in Dear IMGui and hope that someone will adapt it to the other platforms. But my guess is that the end result will be the same as it is now, i.e. no full implementation on non-Windows.

Yes, if you keep your .ini, all settings will be preserved.

The problem are not that they are a big obstacle, but that this requires a lot of messy cruft in the code to support. Just have a look at GZDoom's dehacked.cpp, the last 500 lines of it are virtually all fudging to force some totally alien concepts into the engine so that Dehacked works as intended. And here's where the problem lies. The more features Dehacked gets the more cruft accumulates. Of course the big damage has always been there from the start. The mere presence of Dehacked made it impossible to define a properly constructed class-based actor hierarchy.

No, it's not that easy. For our advanced ports Dehacked is some really messy legacy baggage that blocks us from genuinely cleaning up the engine. Had it not been for the continued need to support Dehacked, DECORATE would look a lot different than it does because much more information would have been moved into subclasses in the actor hierarchy. As an example, for a simple decoration all those properties an actor has to support being used as a monster are not needed, it could be made with half, or even just a quarter of the original size. However, since any decoration can be turned into a monster using Dehacked, we have to support this, meaning we cannot strip down the actor base class to be better suited for simple stuff and use an extension for actual monsters. This not only inflates data size, it also forces the main thinking function to be all-encompassing and we cannot provide a simpler one for simpler objects. As another example, in GZDoom there is a strict actor hierarchy, normally each actor should only be able to execute its own states and its ancestors'. Dehacked requires that it can run *every* state. Which means we cannot do state scanners that scan the hierarchy - we need to use ones that scan all actors in the game. This not only complicates the setup but also makes it a lot harder to do proper consistency checks. With unlimited states it gets even more problematic because there is no good way to assign them to any actor at all, so gross hacks are the only way to go forward because now all places where states get used need additional handling. I also had some issues with the sound extension because Dehacked allows referencing a sound before it is defined. So I ended up with a situation where defining the sound had to happen before I knew what it is. In all these cases the core problem is the same - Dehacked works on arrays that no longer exist and that often oversimplify matters, so each time new references get added to the spec it forces us to add yet another workaround for it that needs to circumvent the abstractions that were built into the engine. I fully understand why Ketmar does not want to deal with this, but so far it has not been an insurmountable obstacle for GZDoom, but I simply cannot guarantee that this will remain so. It depends on what kinds of stuff will get added in the future.

Yeah, this definitely looks like PS1 - but sorry, no, these aesthetics don't click with me. Like I said, even the Build games look better than that - including the more obscure ones.

All true, you won't get me to disagree here. It's just that the PS1's aesthetics are an utter red flag for me, back in the day I had developed a few games for it myself and worked on one PS1->PC port and as a result developed a strong dislike for Sony and the PS1's technical capabilities in particular. I also found Tomb Raider on the PS1 one of the ugliest games I've ever seen and this is what stuck for me with that platform. So, trying to replicate that aesthetic instead of going where PC games were at the same time (hey, even the Build engine looked better!) just doesn't click with me. Give me all the 90's style games you can make and I'd be a very happy gamer - but please use something a bit more mature as the baseline - the Q1 engine is from the same year as the PS1 and has aged a lot better. If I'd ever have to see that texture warping again in a newly purchased game I'd request an immediate refund.

It may have been "very slight" to you - but surely not for me! Implementing the spec meant lots of jumping through hoops and having to solve problems I'd have preferred to not care about. So, assuming that other authors of more advanced ports may face the same issue, these things may have an impact in the end and hamper adoption if modders feel they are limiting their work by using these features. This is also what may discourage other port authors, i.e. having to adapt a spec aimed at comparatively primitive implementations to more refined and better abstracted implementations which may be a poor fit to the spec's needs. If you got "all that" (good luck trying to make it work within a single year... :P) there would be no discussion. I think when having the choice of defining new actors in a high level language like DECORATE vs. Dehacked it's a very small minority that'd choose Dehacked. Most would only do it if they have no choice. So all addition that'd need would be to expose some features that could be retroactively grafted on the stock actors.

You know, such attitudes are incredibly discouraging to us port authors. It boils down to "why improve things if people made do with the old?" and is the epitome of the anti-innovation that has kept the classic source ports in their niche for 20 years because no developer of these ports ever tried to branch out. DSDA is the first port that actually makes an attempt to remove these barriers while at the same time trying to avoid building its own niche, and it should get all encouragement that can be gotten to continue with that. And please do not use Eternity as an example for making it sound pointless. Eternity mods only run on the Eternity Engine which means that this mere fact alone may serve as discouragement, whereas these new *documented* standards are meant to implemented by more than one port, so they won't cause any sort of port lock-in, provided that sufficient ports care. If they find adoption, even those ports which initially take a wait-and-see approach may later follow suit.

Yeah, that's precisely what I'd be aiming at. The expression evaluator may not be totally out of scope, though, as it is fairly contained, it merely needs better encapsulation of the state's arguments. But surely not for a first version.

I surely wouldn't want to invent something completely new here, that's for sure. The parser as-is may be too far gone, I'd probably use the one from ZDoom 2.8.1 instead because it predates ZScript. Only problem is that this is still all C++ code and must interface with plain C stuff which may be a bit tricky (but surely not unsolvable.)

DECOHack has one very big problem: What gets put into the finished mods is only the low level representation, but not the actual source it was made from. It forces all interested ports to deal with the low level trappings of Dehacked and all following extensions to that and will most certainly make life for port developers a lot harder because instead of modifying a well defined high level parser they have to add extensions to the atrocity that Dehacked is (i.e a format that has no sane rules, is a hassle to parse and already far too complex for its own good.) Aside from that, we should see any sort of compiled format as undesirable (even when it's text to text), it wasn't a good idea for ACS, nor for Boom's ANIMATED and SWITCHES lumps and not for anything else. And Dehacked is surely not something I'd consider Human readable, it's actually the worst of both worlds: a poorly defined format that on top of being close to unreadable is also very hard to parse. If you want to create an extended cross-port standard you have to make sure that it doesn't become an obstacle all in itself. MBF21 already got close to the breaking point and while I added MBF21 to GZDoom, it was not fun to do - and DSDHacked was already overstepping the bounds of what ports may be willing to put up with. I think Ketmar has already publicly stated that he wasn't interested. So that'd be one port down. More of this and you might be very surprised that no other port follows suit once more, which means your "standard" is no such thing. Better do a stable foundation first instead of more (de)hackery.

No, but if you always cater your specs to the lowest common denominator the end result will not be that great. Besides, a common parser is the least of the problems, as long as it can dispatch its data to port specific backends it only needs to be written once with a bit of glue to connect it to the backend. We already got the low level parser for UMAPINFO, adding a parsing frontend to that isn't that hard. I don't think it'd be such a big issue anyway. Most ports still keep info.c around mostly unchanged, and with that having its limits removed they already have all that is needed. More advanced ports can just hook this into their backend facilities as they need these anyway for their port specific implementations.

I've been saying that for years. It's an instant turn-off for making Linux a viable desktop system that can compete with Windows or Mac.

The main problem is that the general (paying) public will strongly disagree with you - if you develop a game too deeply mired in these things it may create a sort of backlash you may find surprising. Here's a story from a long, time ago, roughly 1998-2000. Back then the company I worked for was contracted to port a PS1 game to the PC. There was just one problem with this game: It was written in a way that made it impossible to port to a sane 3D API so the only chance we had was to grab the output of the PS1 transformation code and render it as-is. For obvious reasons, as the PS1 is blissfully oblivious of the concept of perspective correction (all the hardware itself can do is render a flat 2D triangle without any depth info whatsoever) our port of the game had the same problem. And now take one guess what ultimately sunk this game... It got bashed in reviews (with virtually everybody pointing out the texture warping as its big problem), got poor customer feedback and ultimately disappeared faster from the market than anyone would have expected. And the reason for this was solely that the textures were warping around like crazy. It did not look artistic but simply like crap. All of us developers agreed but we didn't have the budget to rewrite the renderer. You may get a lot of mileage out of old tech, but beware of replicating technical limitations that are totally alien to your customers. Lack of perspective correction will be worst, because PS1 was the only hardware shitty enough to be outright incapable of doing perspectively correct rendering. I also do not know any people who did not hate this particular quirk of the PS1. (Oh those awful memories of the first Tomb Raider game... :?) You really need a strong retro-mindset to find any appeal here.

DECORATE has no impact on performance at all. All it does is provide a high level access to define actors, but internally they'd be in the same format as the native ones. This misconception may come from the vastly extended feature set in ZDoom-based ports that inflates the data size to support all this. Obviously, any such format for other ports will have to be scaled down to the actual features being supported by the standard, so that it only can define the data actually being present. It'd be a lot more like the very first iteration of modern DECORATE from ZDoom 2.0.61.

It was you who brought up the list. Over the last few years I actually have checked several launchers, but none made the cut to serve as a working base for various reasons.

No, neither. I just feel that the entire process as-is is very inconvenient to use for potential contributors and will surely discourage potential users from giving the needed feedback. Concerning bugs, what I like to do is let them collect for a certain amount of time and then spend one day just squashing 20 or 30 at once. But for that they need to be tracked somewhere, it cannot be done if there is no centralized place that keeps track of them. I often also do not have the time to look at the issues for several days at a time. In Discord or a single forum thread they'd quickly disappear into the ether. I guess we never know because there's no list of issues that may qualify as an indicator. ;) Hm, to me that does not make much sense. You already publish the releases on Github but they are source only. Rest assured that this is where many potential users will stop because they think that they have to self-compile. Wo does read readmes anyway? Average Joes often do not even if they are right in their face. There's also one other thing: How can one download old releases? With Github they'd be neatly stored under the corresponding release tag where they are easy to find for anybody used to how Github works. For GZDoom we formerly self-hosted our builds as well, but it is so much easier being able to point the users to that single location where they can find everything they may need. :)

Player number is 9099. Can you also make a screenshot one function up in P_SpawnMapThing? This is where the error l likely originates.

I'm not sure that this is really exhaustive. Your port has gained a lot of traction outside the speedrunning community already and I am pretty sure that none of these people will ever visit there. Well, let me disagree on your behalf then. :P At the pace you are currently developing it will be inevitable that mistakes are being made, especially in the lesser used parts of the engine, and if you do not provide a convenient means to your users to report these issues I am fairly certain that a lot of info will get lost - especially the discussions that happen after the report - if people feel they cannot easily contribute. How about trying at least? If you feel it doesn't work for you you can still change your mind, but without trying we'll never see how things may go. You can also set up some rules (e.g. "no feature requests until further notice") and close such reports on sight. Estimated time would be 5 minutes a day, maybe - if it gets that high - GZDoom got less than 20 feature suggestions over the last month! I am also fairly convinved that some people here would gladly help you out here if they could, to keep you focussed on the actual work. Something else: Why aren't you hosting your binary downloads on Github? The link's only here in the forum which may make potential users believe they have to self-compile if they don't know this place. As an added bonus, with Github you can get download count statistics if you know the right website to use (I can post a link later today, right now I'm at work where I don't have it available.)

I haven't experienced this with any of my projects. Sure, you occasionally get some stupid reports, but this is minor background noise compared to genuine reports not being made because it's too inconvenient.

None! Those which do mainly use Qt. I have come to believe that the only viable GUI library for a task ike this is Dear IMGui, but since this window needs to run before OpenGL or Vulkan start up it has to be backed by a software renderer that works on all 3 platforms - and that's where things get tricky again...

Of those 106 projects, probably half is search noise, many are ancient and the vast majority of the rest being based on languages that require installation of external packages on some systems. Others are platform specific or useless in other ways. Where all of them seem to fail is IWAD detection, so this would have to be added before making it usable - and this limits the choices to those written in C++ or as a last resort C, because all code I have for this is written in C++.

It surely is doable. When porting the sound system to Raze I removed lots of hard dependencies on how ZDoom works internally and that would help here, too. The main issue here is that Doom's sound system has no limiting features beyond channel eviction if the available set is used up and happily plays all sounds it's being requested to play - and this turned out to be unviable when it was tried in ZDoom many, many years ago as well and created such a strong backlash that the "un-doomy" sound limiting had to be brought back. You cannot go much beyond 10-15 channels without some control options. IMO Visual Studio 2019 is "the" canonical build environment for Windows. Have you tried to run your build in the debugger to see where it crashes? If you can give that information it'd be a lot easier to find the cause. Since you experience the crash and have set up the build environment you are in the best position to provide more help. In any case, I don't expect this to be a compiler specific problem but far more likely a setup issue that was never expected by some code in here. @kraflab Have you ever considered enabling the issue tracker on the repo? With this thread being the only public place where the port is being discussed it's not really the best place to report issues. Something a bit more organized may help a lot.

The main problem with Dehacked is the burden it places on other ports trying to implement the spec. MBF21 was a lot of work replicating trivial stuff and Dsdhacked needed some gross hackery to work as intended with GZDoom. I have written the code but it isn't tested yet - and some of it is really shitty. The good thing now is that with Dsdhacked the relevant arrays are all expandable so some DECORATE -like thing really only needs the parser now, the rest can be done by piggybacking on the unlimited-stuff interface for the more basic ports and the native extension mechanisms for the more advanced ones.

I need something that can be cleanly integrated into GZDoom. That means a) full cross-platform capability and b) they must be written in a language I feel comfortable with because I'd need to add some modifications fo integrate them directly into GZDoom's package. And Go isn't that. That Mini launcher is just a little bit too minimalistic for what I need.