Graf Zahl

What do you mean with Things? Inventory items? Like I said, I think everything up to ZDoom's inventory refactor (which was exposed to modding in 2.1.0) is fine, after that it will get tricky because the inventory stuff is so closely tied to ZDoom's implementation of an inventory system. I wouldn't start thinking about this until the rest - which is still a lot of work - has been ported. Regarding weapons, in hindsight I have to agree. It was tempting back then but turned out to be a major mistake because there's no proper separation between weapon actor states and weapon player sprite states. Sadly it is far too late to fix this by now. While I think it can still be kept in the actor definition, the states need to be separate to make it robust. If you want to do truly "unlimited", yeah - without using sparse tables or other means of non-linear lookup it may become tricky if it starts wasting too much memory for the linear tables.

You are probably right. But start in a vacuum? I'm not sure about that, if the point is supposed to be running older ZDoom mods. What probably makes the most sense would be to get a subset of DECORATE working to run that monster resource WAD from 2005. If you got that there'd be enough features for convenient definition of new monsters - this was before the implementation of custom states and overall still quite basic. The needed code pointers would also all be of the kind that's painless to backport. If that could be made to work within the framework of what MBF21 and DSDHacked provide it'd already be a huge win for everybody.

To guesstimate a translucency value you need to check black and white, like ZDoom implemented for TRANMAP. This of course only works as intended if the palette is not being inverted so for invulnerability it'd be unable to determine the proper blend mode.

Hardware rendering does not use these palettes (doing so would necessitate creating new textures for every single one if these layers of intensity which is utterly prohibitive), it draws a translucent solid colored rectangle over the entire screen, and no port so far has any logic to extract this blending color from the provided PLAYPAL.

If you do it right it won't affect demos. The slope math functions just return the flat sector height for unsloped sectors so the only places to be careful is the movement and collision code which would need a bit more care to handle both options. DSDA already has this for these games. The code could also be activated for Doom if needed. Since this is mostly on the UI side and not the play code it won't affect demos too badly. But obviously for a demo-centered port it needs to be done with a little more care to avoid breaking things. As with most other things, it's not impossible to do but it's a lot of work.

Publishers may have gotten better at squeezing more out of it, but even by 1995's standards, 2 MB of main RAM and 1 MB of video RAM (minus the two screen buffers) was already laughable. It couldn't even run Doom without stripping the game down first and then had to use some colored light to make up for the loss of level detail. Yes, it was certainly better than the other consoles you mentioned but during its 6 years of shelf life PCs' capabilities managed to get lightyears ahead.

If you want something grammar based you may just take ZScript minus the actual code part which is essentially DECORATE with a stricter syntax. Of course an ad-hoc parser will be significantly less work to implement than a grammar-based one. None of that is in a form that can't be ported to other ports. Even the entire expression evaluator contains nothing show stopping.

You are inevitably limited by not being able to put fractional heights in the map data which severely limits the places your code may jump to. Of course, if you manage to get some meaningful code into such a place, yes it is theoretically possible. This is a typical array-on-stack overflow, after all that will eventually overwrite the return address (with its 23rd element if I am not mistaken)

If you get slopes working, a lot, actually. The places where the real problem starts is custom inventory items. Everything before that can be ported to a more vanilla-like port if someone took the needed effort to make it work. That'd mean, up to 2.0.98 should be possible.

Reading that function again, it's not the number of sectors that matters but the number of linedefs. And that's a lot more than 17.

Yes, it can deal with 20 sectors higher than the one that's being moved.

Yes, this is a vanilla limitation. The function to find the next highest (lowest?) neighboring sector was very, very stupidly done, instead of just iterating over the neighbors, it stored the height info in a local array to check that later. That array had 20 entries, you could add two more due to other variables on the stack before it crashed. That function is actually a genuine facepalm thing, one has to wonder how anybody could come up with something this idiotic.

Playstation 1 is the worst from a technical standpoint. With the amount of RAM that thing had it was virtually impossible to do a game without making any compromises in quality. Been there, done that several times, the fight against the limited resources always took its toll on the result. I actually developed on that thing, and I admit that this surely affects my memories of it.

That "numbers in quote" thing is owed to Hexen's sc_man parser which was used for that first DECORATE version. ZDoom's version of that only got a proper tokenizer years later when it was too late and some idiots had actually released stuff that used numbers in quotes... (no kidding here... :?)

Please don't come with that C argument again. The language sucks when serving as a 'reference' . it often means that one can take the code and toss it into the dumpster right away. Reusability of C code is no better than C++ unless you restrict yourself to the language core which lacks virtually everything needed to do a good parser. So the result will be to bring in some third party code to make the job easier and we've just lost the 'portability' argument. Besides, the UMAPINFO parser already is C++, because I had no working C parser capable of doing the job and saw no point writing one, as C++ variants were readily available, and it hasn't harmed anyone.

I already do dynamic allocation for everything. Remember, I do not have static arrays for these things. I just do not like the way this was done because it's needlessly too low level and exposes implementation details that could have easily been hidden away.

Agreed here. but that's natural film grain vs. intentional image degradation of a pristine digital source. That film really looks great with a clean image. I know it wasn't intended to be shown that way, but still... That version of Predator was an utter disaster, though. It's also image degradation, just in the reverse direction. But the end result is comparable. One other film where I have seen something similar is Dark City. That one (at least the version I bought many years ago, no idea if there's a better remaster by now) has also been DNR'd to death. What's interesting here is that there is one scene fading in where the filter took a few seconds to kick in, so we got a beautifully natural image reproducing the film grain during the fade, but after that it's that flat lifeless image again. Ugh... Yeah, that's always the problem with such effects. One needs to understand where they come from to properly emulate them - but then, is that really necessary? More often than not it's a sign of people getting too caught up in details instead of seeing the bigger picture.

No, you are just leaving us with the mess this creates - and of course give Ketmar more reason not to implement the spec at all... Granted, the sound and sprite issue is minor compared to the states, but it's still a totally needless and useless complication of things compared to dynamic allocation of sounds and sprites at the places where they get referenced. No idea. I haven't heard anything from them at all, but then, there has not been much activity on their repo in recent months.

Go to the menu, switch it off... :P

Two other things I'll never understand. Or that grain filter in Blade of Agony. On the same note, I never could accept that layer on dirt that was plastered over the "Planet Terror" movie as artistic. I found it just distracting. Fortunately the BluRay also has a scratch-free version. I think it has become clear by now that I cannot see much merit in deliberately trying hard to replicate visual degradation caused by limitations of old tech. But apparently there's enough people who find this "charming" or so. It's something I'll never understand, I prefer the kind of retro that acknowledges how games were made in the past but then tries to present them as best as it can be done in 2021 without betraying their roots, not try too hard to make it look like it was right out of the (early) 90's with all the warts and bumps included.

Sadly in return it makes the entire thing extremely more complicated for some ports because there is no good way to handle this indirection without the linear table, not to mention being less editing friendly and error prone. BTW, I'd be interested to hear how Team Eternity thinks about all this, they have been quite absent from this discussion so far.

@Wadmodder Shalton Reading all the stuff you have posted I have to seriously ask, what's your problem here? You continue to talk about lots of things that are either long obsolete and irrelevant when thinking about a new OS or they bear no relation to Windows 11. To sum it up: 32 bit is dead. Period. Market share outside of supporting obsolete but mission critical enterprise software is virtually non-existent by now. Steam says less than 0.5%, GZDoom's last survey from 2019 said 1.55%, but that was two years ago, so the numbers are a lot lower now. So it's merely a tiny, tiny group of holdouts with their more than a decade old systems that will only shrink further still depends on this - and none of these people would consider updating their OS if they don't see the need to update their computer after such a long time. There's really no no need to even discuss this further. And the VM stuff is a totally separate issue. Windows 11 won't change this neither for the better nor for the worse. Yes, it sucks, but then again, VMs suck at running games anyway - so what? The real issue here is that Windows 11 renders lots of relatively modern CPUs obsolete, but that seems to be the one issue you apparently do not have on the radar

The state table's format is mostly the same in all ports up to DSDA, so it should be no problem to implement the same resizing mechanism. But if you want to keep it static, what should a reasonable upper limit be? At some point the table will become too large anyway, so "unlimited" isn't really a thing. For example, some modder may set their index to something ridiculously high like 65535. This is something I can deal with in GZDoom because I use a hashmap to index my states during parsing, but with a static table you now will have to allocate all 65536 states including all the unused gaps. The same applies to the other resources. For actors and sounds I actually cheated - I just define an entity like ~SomeGenericName~#index which I then look up by that name instead of having a huge array of unused stuff. But again, with a table based format you have to fill in all the gaps in the list. With that in mind it should work if you use reasonable limits to avoid the reallocation but rest assured that sooner or later some map will break your limit - either by being careless or being too ambitious. I'd still expect most modders to just count up from the first free one and not put their things somewhere far away from the beginning. But you never know. In any case, since this is all new and has not been put to use yet, maybe we can make it a little bit nicer and reduce the potential problems? The thing about this spec that bugs me most are the sound and sprite arrays because they introduce an easily avoidable indirection. Maybe we can just do away with them entirely. If the parser could be changed to optionally parse these as strings in addition to numbers we could just write "sprite = POS2" or "Attack Sound = poshot" and remove the [SPRITES] and [SOUNDS] blocks entirely and just dynamically add content to the arrays when a new name is found. This not only would avoid arrays with gaps, it would also make the whole thing a lot easier to handle for those ports which no longer have these tables.

If you port DECORATE please be aware that this needs to work on the actor/state data without Dehacked modifications. In ZDoom Dehacked is done afterward as DECORATE is also used for the stock actors. This may become a bit tricky with the unlimited stuff inserting itself at places you may not know when parsing DECORATE first

You know how it goes when making such decisions: A) "GUI is not part of the kernel, it has no place there" (Yes, correct, but an OS is more than a kernel.) B) "Hey, why did you use abc? xyz is much better and I refuse to support abc!" C) "We don not need any bloatware in the OS" and so on, and so on. And if it happened anyway, some schmucks will release "Linux Lite" with the GUI stuff removed and we're back to square one.