Graf Zahl

Your POV was to blatantly ignore all sane settings for a standard (as already implemented by the two supporting ports!) and instead forcing your view of things without any compromise. I tried to give you a compromise that would have worked fine for every eventuality but instead you dumped a mess on me and the modders to sort out I am not willing to sort out. Seriously, what reaction did you expect here? It makes no sense defining a standard if one person in power chooses to ignore it, despite opposition by everybody else weighing in their opinion.

Hexen never shows the map label or hub label. The default is to just show "Badlands" (The actual text in the internal MAPINFO is "BADLANDS", actually.) This is also the default in GZDoom, but there's a user side option to force the map label to be shown. So it's either "Badlands" or "MAP45: Badlands", depending on how you have set it. This is precisely the edge case I was talking about where the engine cannot take apart the string because the map label bears no machine recognizable pattern to find. If this bothers you in GZDoom, switch the map label display off, but in the end that's a poor solution for something that should be dealt with in a sane fashion. Having both of these things lumped together in one string is just a relic of a long gone past, that should be avoided in future features, not encouraged. Just because something is "as it always has been" doesn't mean it's not broken. And it's precisely this case I was trying to avoid by defining a sane and well defined framework, but got ultimately sabotaged by Printz.

No, you can't. If you do not want to adhere to the spec (even though not written yet because I was hoping on some consensus), better drop the feature in its entirety. It's no fun trying to tweak something to an intentionally broken implementation, even if it is something as seemingly inconsequential as the map name display on the automap. Congratulations then, because to me this sounds like all the talk and attempt to compromise was for nothing. So, with that I think we can just forget about the "label" field because its purpose was to provide a defined standard everybody could adhere to without compromising their vision. Since that didn't work out, consider the feature dropped, I see no point supporting something that isn't uniformly handled in all ports and ultimately not really needed. All things considered, map name display on the automap works fine in both my PrBoom fork and in GZDoom, so the ball is in your field now. If you don't want to pick it up, please deal with the mess yourself. Well done! :(

@Printz: The solution for that would be an engine option where you can explicitly select if you want to show the label or not. I have added such an option to ZDoom a long time ago because I did not like the defaults of the time (map label on for single maps, map label off for hub maps) and chose to add more end-user-friendliness, even though all *I* wanted was to force the map label on. What I absolutely do not like are "solutions" that defer the entire mess to the mod makers with no sane default that makes most people - players and modders - happy. But that's precisely what you seem to prefer here.

32 bit with 16 GB of RAM? What kind of system is that? Not that it matters for the problem - that's more likely caused by the graphics card - it's marginally better than the Geforce 8600 I had 10 years ago - and that definitely had problems with portal setups, which the skybox is.

Can be done, but there still needs to be a default. And I am quite sure that, if we asked the community, the consensus will be to use the lump name. BTW, in all those 20 years, nobody ever complained that ZDoom replaced the 'level xx' part with 'MAPxx' on the automap in Doom 2. I think that's saying a lot about what people want here: Some information what map plays right now, the exact presentation does not really matter, as long as it is obvious. I am convinced that leaving it off is bound to draw complaints like "Please show the number/name of the current map, please!"

No, a missing label specification should do what the spec demands you to do in this case. If the spec states that it wants to see the map lump name instead that's not open to interpretation, especially if there's a clearly defined case for not showing the label at all.

Let's rather define this *properly*, so that the mappers can decide. Most of the time they want this displayed. Shadow Hog's suggestion is on point here and fully in line with other features that can be reset to nothing.

Sadly with current hardware, not at all. The limiting factor here is the blending stage which is not accessible to shaders and only offers very limited configurability. I guess we can only hope that eventually this will become programmable as well - it'd really open up a completely new category of rendering effects if the blending could be controlled per pixel. This is basically the last remaining part of the render pipeline that isn't programmable... What do you consider "legacy crap"? Old OpenGL version support or handling some arcane engine features? Trust me, you'd be surprised by how little you gain here. I got more juice out of just multithreading the setup, once I manage to multithread the render list generation as well the entire issue will no longer consume any relevant time and can fully run in parallel to the BSP traversal. You can't skip the BSP traverser because that's the only means to collect the needed portal information, and this needs to be kept as low as possible because too many portals can really drag down performance because they can cause render pipeline stalls with their stencil manipulation. Actually, one of the biggest time wasters in the renderer is cache misses in the clipper, again something you cannot skip because this defines what parts of the automap are visible. Think about it: We got several GL ports out there that tried to go the route you describe, and they are generally the slowest of the bunch - the main reason that the added data produces far worse CPU caching behavior. Also, perfection has always been the greatest enemy of something good. I don't know how often it happened with ZDoom that something good was pushed to the wayside because something better was supposed to be in the pipeline, and often that better thing never materialized for all sorts of reasons, either because it turned out unfeasible or nobody had the time to make it work. Do you have the time to write a new renderer from scratch that works completely differently than everything that came before? Not even GZDoom did that: The renderer grew out of PrBoom's - it just got extended and streamlined over the years and actually modernized. It still took me 3 years to get it ready for prime-time, that happened between 2002 and 2005. For copying the software canvas to the hardware, this is perfectly fine - but once you do true hardware rendering, those rotten potatoes will really make your life miserable when it comes to a performant render setup on better hardware. This was what actually caused the split of GZDoom into modern and vintage last year - an optimzation that brought significant performance improvements on any modern and semi-modern hardware made the frame rate tank on those "rotten potatoes". Trying to maintain both code paths in the same executable would have been a mess. That part can be done in the shader easily. However, not quite feasible on GL 3 hardware, it's just not fast enough for such complex per-pixel operations. When I was still using a Geforce 8600, that system was seriously struggling with software lighting emulation.

The renderer *is* faster (on my system, compiled with the same VC compiler, Frozen Time's bridge scene is 60 fps on GZDoom (with multithreaded processing) vs. 75 fps with GlBoom. I haven't done detailed profiling, but the most likely cause is that the GLBoom renderer doesn't have a few things that cost a bit of time on GZDoom, like offscreen rendering. When this was introduced it caused a 5 fps frame rate dip on my system and it required the multithreaded render list generation plus Vulkan do get back that bit of performance. Playsim think time is not nearly high enough on that map. I'll have to add some genuine profiling code to GlBoom to find out what part precisely is causing the difference. I don't really think that the speed advantage can be kept with Eternity. Raw speed isn't anything, you'll also need a roughly compatible feature set. Let's not forget that Eternity requires both slopes and portals which GLBoom does not have. The portal code in particular is a very complex thing because of the complex obstruction checks that can occur with portals. It also doesn't have any dynamic light code. AFAIK the biggest thing GZDoom lacks over Eternity in rendering features are edge portals (they are a bit tricky with hardware clipping as they can cause nasty recursion cases if not handled properly.)

This sounds like a bug with last year's AMD drivers which miscompiled one shader. If it's that problem a graphics driver update should help.

What's your graphics hardware?

Correct, but "back to the basics" implies "no hacks". To make do with 40 sectors would necessitate hacks. Why no hacks? My suggestion for a "back to basics" mod would mean to make maps that could have been built with the original Doom editor. This editor had no concept of sectors, so anything involving degenerate sectors or split sectors would be out of the question. So: - map should have roughly the size of an IWAD map - no visplane overflows, no drawseg overflows, no vissprite overflows, i.e. renders glitch-free with a non-limit-removing engine. - no render glitch abuse. Vanilla did not do this - Plutonia doesn't count in this respect because it wasn't made with the original tools. The original tools used by id are fundamentally unable to do render hacks involving self-referencing sectors. - monster count approximately in the same range of original levels. - considering the Revenant an upper-tier enemy, not lower-tier like many more modern mapsets do. Back in the day it was considered a dangerous threat and used as such. - must be playable and saveable with Doom.exe. If we could agree on these limitations THEN we'd be talking genuine "back to the basics"!

City of the Damned: Apcalypse: https://www.doomworld.com/idgames/levels/doom2/Ports/s-u/tcotd21me One of the few projects that really manages to convey a scary atmpsphere.

Do you really need full support for it? Aside from some occasional demo maps it hasn't ever been used for anything more than setting a translucency factor (i.e. setting PrBoom to the given factor, let it generate a TRANMAP and rename it.) and for that some simple analyzer is good enough to create an alpha factor for the software renderer. Trying to do this with shaders isn't really going to work out, because shaders cannot read from the buffer they write to - and that's what you'd need when blending a color with the background - not to mention that a shader will operate on True Color values, not palette indices. If it was that easy I'd have added support for full TRANMAP a long time ago, but unfortunately the blending stage is still not programmable on modern hardware. For general mapping purposes you are better off anyway to do it like ZDoom and create translucency maps on the fly from a given factor and not use pregenerated resources as the only means to achieve it. It's a big problem, you could do it like StrifeVE but that'd cause a bootload of other follow-up problems, especially when handling portals the depth buffer is a vital component and an approach that avoids its use most likely won't work that well. This also shouldn't be forgotten. A software renderer will inevitably be limited to smaller screen sizes. I think for many users coming from more recent games, that paletted and banded look is something they are not accustomed to and really don't like. The main question is: Do people really want this or is it just a limitation they begrudgingly accept as an inherent limitation? A true color based software renderer, if done correctly, will look just like hardware rendering without texture filter and proper tilting. Just have a look at the smooth lighting gradients in GZDoom's. Unless you look up and down it'll nearly be the same as the hardware renderer when using software-emulated lighting mode. Regarding Macs, the only way forward is to use Vulkan, never mind that it's not a great API to work with with all those synchronization objects that are needed. OpenGL on Mac is shit already and nobody is going to do a Metal port. Also, writing a complete hardware renderer from scratch isn't going to be easy. Setting up a basic renderer isn't too hard, but what costs time is to implement all the special things Doom has to offer, like render hacks, properly positioning sprites and having to recreate the scene every frame - and optimizing the whole thing. You'd be better off to take an existing renderer and make the needed adjustments to it instead of reinventing such a gigantic wheel.

What about my compromise offer? That should satisfy everybody without forcing modders to jump through redundant hoops.

That's my standpoint here as well. Just because it was originally done differently does not mean that the original way was actually a good and useful way to handle this thing and needs to be preserved at all costs, including inconveniencing potential users. In fact, many things were done very inefficiently with Doom (think about all that graphics-based text that's so hard to localize) and it'd be a lot easier if this stuff could just be tossed out (which sadly it can't.) There's also another issue to consider here: In ZDoom, display of the map label on the automap has been a user option for many years, i.e. you can set it to show the label or to hide it, or to only hide it when in a hub. Forcing everything into this string removes that option. As for the "different name on automap vs. intermission screen" thing, is this really important? It happened twice in Doom originally, but it is doubtful it was intentional, it looks like the classic case of development bug where the thing was changed but thanks to an inefficient asset duplication, only one of the two instances was changed.

No, in this case it's mere attitude. You got a feature presented and your reaction was flat out refusal to implement it as presented in the spec and as implemented by the reference engine. That's simply not how specs are supposed to work. If everybody was to treat them this way there'd be no interoperability ever. As a compromise, how about this: Have a separate property in the map record, called "Label". If that is not empty, use it in the automap as the part before the ":". If not specified, use the map lump name instead Also, your opinion that the map lump name is an internal matter is simply wrong. I don't know how many console commands in Eternity refer to it, but in ZDoom-based ports, 3 come to mind immediately: "map", "changemap", "mapchecksum". So it is useful information for the player. Sure, but with 'fadetable' I'm a bit ambivalent. This is a classic software-rendering lock-in feature. I think it'd be more useful to add a fade color and generate the fog maps on the fly, like ZDoom has been doing for 20 years. That way you don't have to manually create fade maps for every fog color, i.e. for the mapper it's a lot easier to use - especially when being combined with colored lighting (as you'd have to create a separate colormap for each light/fade combination.) There hasn't been a single ZDoom-based map ever using a custom fade table - even though the option exists in MAPINFO because Hexen needs it, but there have been countless maps using different fade colors.

So, I guess with such an attitude we can bury the thing right away, huh?

No. I'm sorry but here your ideas do not mix with mine, because in ZDoom it has always been a hassle to remove that map label in front so that we have a sane text to work with. With too many Dehacked modifications that were limited by available character space it cannot do it correctly. I'll comment on the rest later.

I guess we'll have to wait until some mod appears that may benefit from using it.

Because it'd block playing mods with older complevels. Imagine BTSX came with an UMAPINFO and someone wants to record demos on it using strict vanilla gameplay settings. Currently this is doable, but with your approach it wouldn't be.

Here's the latest release of my PrBoom fork with UMAPINFO support: https://github.com/coelckers/prboom-plus/releases/tag/v2.5.1.7um The changelog can be found in the above link So far there's only a Windows 32 bit version because I am unable to create release packages for macOS and Linux, so any help here is welcome. This has been built with Visual Studio 2019 so there's no Windows XP support. Please report issues at the Github issue tracker.

Maybe because I do not keep records? Do you really expect me to check out all the hundreds of mods I played over the years which in part I barely remember? Ultimately, being pistol start compatible is not a metric I care much about to be able to pull a list out of my hat. Yeah, whatever. I see someone felt addressed by what I said in the previous post and had to act defensively. :P

There's countless of mapsets that were designed for continuous gameplay and do not handle well with pistol starts. Of course those who proudly look down on people not playing everything on UV with pistol starts only, would never EVER admit to it. >)