PrBoom+ 2.6.66 (Jun 20, 2023)

Great! This was much needed. Where can I find documentation/examples of the syntax UMAPINFO uses? I only found a quote on the other thread.
Also, messing with nerve.wad got me this error: "R_textureNumForName: RSKY1 not found"

This was in the umapinfo lump

Will this port also parse the classic MAPINFO lump or is this all about UMAPINFO?

There is no classic MAPINFO parser. Such a thing would make sense if I wanted to support simple ZDoom features but not right now.

Regarding all the demo compatibility discussion, what wouldn't make much sense is to enable UMAPINFO based on complevels. That'd negate one of the major assets here, i.e. play mods with a non-standard progression with classic settings. So the only solution would be to set a bit somewhere in the header to make the demo invalid to non-supporting ports.

In any case, right now the biggest problem that needs to be found is the broken float->int conversions in the GL renderer.

24 minutes ago, Graf Zahl said:

In any case, right now the biggest problem that needs to be found is the broken float->int conversions in the GL renderer.

Is this about rounding? I somehow fail to see how else converting a number from a floating point representation to an int could make such a difference. Could you probably point to some document which is availablre online and which I could use to educate myself?

Deleted

17 minutes ago, fabian said:

 

Is this about rounding? I somehow fail to see how else converting a number from a floating point representation to an int could make such a difference. Could you probably point to some document which is availablre online and which I could use to educate myself?

No document, but the catch here is that if you cast a float to an int and the float's value is outside the valid range for the target type (e.g. negative for unsigned or >= 0x80000000 for a signed int) the result of that conversion is undefined. And in this case 'undefined' really means undefined. Different hardware performs differently.

Possible outcomes are:

- the value discards the upper bits and wraps around.

- the value is clamped to the target's range (i.e. anything smaller gets set to the smallest representable value, anything larger to the biggest representable one)

- an error code is returned (if the input value is out of bounds it will always return the same value.)

I have observed these 3 scenarios with different instruction sets or CPUs.

It seems to me that the renderer assumes to get wraparound behavior, but to my knowledge you will only get that with x87 and a float to int conversion function that doesn't use SSE2 if available. Just looking at the glitches it was very obvious that something goes wrong when certain angle values get converted between floating point and angle_t.

Here's the relevant thread from the ZDoom forum where the problem was initially discovered:

https://forum.zdoom.org/viewtopic.php?f=7&t=50755

Alright, the implementations in http://stereopsis.com/sree/fpu2006.html seem pretty straightforward to me. Is the 'real64' data type the same as 'double'?

Can I get umapinfo example? Does this allow end map in any slot? I'd like to test it on my boom project and see how it works. 

You can find for Sigil E5 in the UMAPINFO discussion thread.

2 hours ago, Misty said:

Can I get umapinfo example? Does this allow end map in any slot? I'd like to test it on my boom project and see how it works. 

In case someone is too lazy to go hunting for it. Here is the example for Sigil:

// UMAPINFO for SIGIL

map E5M1
{
	LevelName = "Baphomet's Demesne"
	LevelPic = "WILV40"
	Next = "E5M2"
	Music = "D_E5M1"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
	Episode = "M_EPI5", "SIGIL", "S"
}

map E5M2
{
	LevelName = "Sheol"
	LevelPic = "WILV41"
	Next = "E5M3"
	Music = "D_E5M2"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M3
{
	LevelName = "Cages of the Damned"
	LevelPic = "WILV42"
	Next = "E5M4"
	Music = "D_E5M3"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M4
{
	LevelName = "Paths of Wretchedness"
	LevelPic = "WILV43"
	Next = "E5M5"
	Music = "D_E5M4"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M5
{
	LevelName = "Abaddon's Void"
	LevelPic = "WILV44"
	Next = "E5M6"
	Music = "D_E5M5"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M6
{
	LevelName = "Unspeakable Persecution"
	LevelPic = "WILV45"
	Next = "E5M7"
	NextSecret = "E5M9"
	Music = "D_E5M6"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M7
{
	LevelName = "Nightmare Underworld"
	LevelPic = "WILV46"
	Next = "E5M8"
	Music = "D_E5M7"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M8
{
	LevelName = "Halls of Perdition"
	LevelPic = "WILV47"
	EndPic = "CREDIT"
	InterText = "Baphomet was only doing Satan's bidding",
				"by bringing you back to Hell. Somehow they",
				"didn't understand that you're the reason",
				"they failed in the first place.",
				"",
				"After mopping up the place with your",
				"arsenal, you're ready to face the more",
				"advanced demons that were sent to Earth.",
				"",
				"Lock and load. Rip and tear."
	Music = "D_E5M8"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M9
{
	LevelName = "Realm of Iblis"
	LevelPic = "WILV48"
	Next = "E5M7"
	Music = "D_E5M9"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

I hope that this fork does not turn into a kind of GZDoom. I am not against cosmetic features that do not alter the gameplay and demo compatibility.

That'd require another developer to invest that much time.

The most likely things on my list would be support for Hexen and UDMF formats, but most likely without ACS at first because that would open a huge can of worms I'd rather keep closed for the time being. But having Hexen and especially UDMF format would make it a lot easier to implement such cosmetic features that make mapping easier without changing the core properties of the game. Doom's format is just a bit too limited because there is no extensibility anymore.

1 minute ago, riderr3 said:

I hope that this fork does not turn into a kind of GZDoom. I am not against cosmetic features that do not alter the gameplay and demo compatibility.

Don't worry. That won't happen as people are hell-bent on keeping vanilla traditions. In fact my fears are the opposite of yours.

I can almost bet that even if PrBoom+, Eternity Engine and Crispy manage to implement UMAPINFO and resolve the demo compatibility issues that dew mentioned (by changing header bit so that non-supporting ports not try to play the demo), there would still be people who would keep sticking with old traditions.

I don't want to see this effort of UMAPINFO implementation go to waste.

Just now, ReaperAA said:

I can almost bet that even if PrBoom+, Eternity Engine and Crispy manage to implement UMAPINFO and resolve the demo compatibility issues that dew mentioned (by changing header bit so that non-supporting ports not try to play the demo), there would still be people who would keep sticking with old traditions. 

I don't want to see this effort of UMAPINFO implementation go to waste. 

These people will always exist, and so will be projects that target simpler specs. The problem I am currently seeing is with mods like Eviternity that are involuntarily confined by the inflexible progression they must adhere to to target a demo compatible engine. If that could be solved it'd eliminate a lot of problems.

Awesome job Graf, very happy to see this starting to see the light of day!

Forgive me if I'm misunderstanding any of this (I certainly had some misunderstandings in the original thread) but I can see Graf's point about not making this its own complevel. If ultimately this becomes supported by ports like Crispy, one could end up making a limit-removing wad that uses umapinfo. Would that be -CL2 or something else?

On the other hand, I also understand you don't want situations where someone tries playing back a umapinfo demo on a non-upmapinfo version of PRBoom+ (or Crispy or whatever) and it simply desyncing (rather than crashing out) because the older sourceport doesn't understand it's doing something wrong.

Random idea, is there a reason we couldn't have a bunch of new complevels that are basically "old complevels + umapinfo"? Realistically we'd only need to do the big ones (2, 9, 11, 17?) and maybe set them as something way high like 40 - 44?

40 minutes ago, Bauul said:

Forgive me if I'm misunderstanding any of this (I certainly had some misunderstandings in the original thread) but I can see Graf's point about not making this its own complevel. If ultimately this becomes supported by ports like Crispy, one could end up making a limit-removing wad that uses umapinfo. Would that be -CL2 or something else?

Personally, I would not like UMAPINFO to be complevel dependant. There are already too many complevels. Do we REALLY need to have more complevel numbers. Like Graf said, it would be better to change a header bit so that non-supporting port wouldn't try to play it.

Afterall this is similar to how wads like Ancinet Aliens and Eviternity are like. They are complevel 9(Boom) and 11(MBF) wads but they do not run on original boom and MBF executables.

Since the header would be changed anyway, maybe it would make sense to add some data to the demo so it can know exactly what map the demo transitioned to?

That way it would be possible to keep compatibility in terms of map progression no matter how the umapinfo spec changed in the future.

I wouldn't overdo it. In the end demos are made for released mods and they tend not to change. It should be fully sufficient to mark the demo as requiring UMAPINFO.

Since this thread seems to be acting as informal wishlist for prb+ bug-fixing and feature requests, here are some small changes that'd be great to see:

1) seamless musinfo on save/reload. (which fabian ended up fixing in crispy)

2) restoring friction on save/reload (which is as simple as calling P_SpawnFriction during the load game routines). This technically breaks previous demos recorded on complevel 9+ that contain saves and friction sectors (do any even exist?). but idk. As is it is undeniably broken.

3) if a wad contains a new playpal that is similar to but not identical to the one used to compute the cached tranmap, then the cached one might be used and software gfx transparent sprites may have visual errors. A hacky way to fix this is to rebuild the tranmap every time (trivial computational expense tbh), though there's probably a more robust way to check to see if the cached one matches.

4) support for zdbsp compressed nodes

Thank you so much for taking care of this nice old port. I believe you might fix a few issues it has had.

The most apparent is a bug in GLBoom+ where it won't adapt the picture to the screen on startup: https://imgur.com/PrREDxx

It only works after setting the renderer to 32-bit and then reverting to OpenGL. However, this makes it crash with the following message most of the time (yet not always): https://imgur.com/ztWgkHM

EDIT: Actually, the problem is of a larger scale, with PRBoom+ showing the same issues. It all also happens when just changing the resolution in-game.

EDIT 2: Also, what the hell is that? https://imgur.com/m3S9lxQ

1 hour ago, Ribbiks said:

Since this thread seems to be acting as informal wishlist for prb+ bug-fixing and feature requests, here are some small changes that'd be great to see:

 

1) seamless musinfo on save/reload. (which fabian ended up fixing in crispy)

2) restoring friction on save/reload (which is as simple as calling P_SpawnFriction during the load game routines). This technically breaks previous demos recorded on complevel 9+ that contain saves and friction sectors (do any even exist?). but idk. As is it is undeniably broken.

Stuff for later. I'm not familiar enough with the code yet to make such changes. I'm a bit puzzled that friction is not part of the savegame.

Was savegame format fixing also blocked by the needs of demo compatibility?

1 hour ago, Ribbiks said:

3) if a wad contains a new playpal that is similar to but not identical to the one used to compute the cached tranmap, then the cached one might be used and software gfx transparent sprites may have visual errors. A hacky way to fix this is to rebuild the tranmap every time (trivial computational expense tbh), though there's probably a more robust way to check to see if the cached one matches.

IMO caching the tranmap is nonsense. Even back when Boom was new this wasn't costly enough. It's one of those stupid relics of bad 90's optimizations.

1 hour ago, Ribbiks said:

4) support for zdbsp compressed nodes

Why? They are already deprecated even by ZDoom and no longer recommended for new maps.

1 hour ago, Get Phobo said:

EDIT 2: Also, what the hell is that? https://imgur.com/m3S9lxQ

That's the float to int conversion bug we had been discussing on page 1 of this thread. Fortunately I already fixed it.

8 minutes ago, Graf Zahl said:

I'm a bit puzzled that friction is not part of the savegame.

Was savegame format fixing also blocked by the needs of demo compatibility?

Friction is successfully packed and unpacked as a sector property during the save/reload processes, but for some reason it is not reinitialized so it doesn't take effect on reload. I'm 90% sure this was an oversight back when the sector-property-based friction replaced the less efficient thinker-based method (courtesy Killough, circa late 90s). Someone more savvy than me wrt historical demo compatibility might know if this was a conscious choice or not.

18 minutes ago, Graf Zahl said:

Why? They are already deprecated even by ZDoom and no longer recommended for new maps.

A bit completionist, and I figured it might've served a niche of being the node format with the smallest footprint.

3 hours ago, Ribbiks said:

3) if a wad contains a new playpal that is similar to but not identical to the one used to compute the cached tranmap, then the cached one might be used and software gfx transparent sprites may have visual errors.

This can be fixed by comparing the entire palette instead of just the first 256 bytes: 

https://github.com/fabiangreffrath/crispy-doom/commit/95922e8c540abb019f6dd42b7ae24ce4280b6b3e

Quote

4) support for zdbsp compressed nodes

I could contribute this. And loading of maps in Hexen format without ACS. 

28 minutes ago, fabian said:

I could contribute this. And loading of maps in Hexen format without ACS. 

Wouldn't it be more prolific to skip outdated hexen format and go straight to udmf if possible?

Yes and no. Most of the work is not reading the map but implementing the required features - and those are the same for both formats. Hexen format has one decided advantage: There's a lot more testing material of old ZDoom maps in it than in UDMF, so supporting Hexen format may just make sense for that.

I did the same in ZDoom once for Eternity Extradata: It has no use for mapping at all - but with it I could use the Vaporware map as a test case for the portal feature at a time when there were no other portal-containing maps available.

Possibly a stupid question: Would the support for udmf/acs negatively affect performance? One of the biggest draws of prb+/glb+ is the ability to handle big boom maps with lesser hardware than zdoom requires (due in part to lack of generalized/extended monster behaviors, and overall a smaller feature set, as far as I understand)

The biggest performance hit in ZDoom comes from the change in which things are linked to the blockmap (i.e. they are linked to every block they touch, not just the center.) This is what affects NUTS the most.

Aside from that, the more costly parts are actor features, not map features. Whether there's 10 or 100 or 1000 methods to start moving a floor, the end result regarding performance is the same.

So, no, more mapping options won't have a larger impact on performance.

On 6/11/2019 at 3:46 PM, Graf Zahl said:

Maintaining two ports may not work out so if someone could provide a bit of help it would be appreciated.

 

The main question is what could be done with this and where to draw the line. What would be great if that discussion about an advanced Boom standard could be resurrected and a few features that are sorely missing from Boom could be added.

 

Of course, with this Eternity also needs to be in the boat.

I know I have not yet provided any results of my efforts on the Boom extensions - a fact which I deeply regret. Despite my efforts, I am still consumed by "real life" priority projects. I cannot make promises, but my heart is in it 100%. I did write most of what I saw the first spec to contain, but it still needs major polishing.

As far as development goes, if I did manage to free up my time, I'd be interested in parallel development of PrBoom and KBDoom, as far as the Boom-extensions go. There's no reason you have to maintain both GZDoom and PrBoom+, but KBDoom and PrBoom share a lot of philosophy, meaning that a lot of literal copy+paste could go a long way.

And, yes, in those specs, a lot of consideration was given to Eternity goals, as well as the goals of the other ports. I very much want all the ports involved, because that is what will make the spec work.

But, again, I hate to make those promises, and be responsible for retarding any progress. I'm not accustomed to not being able to produce results in a timely manner, and it really upsets me. I can say this: I *will* get to it - I'm devoted to making it happen. I just can't say when.

23 hours ago, AD_79 said:

Yeah, we can't forget that PR+'s primary goal is to playback demos smoothly and properly. If you are to work on this, demo compatibility needs to stay intact 100%. Maybe UMAPINFO could have its own set of complevels or something so it doesn't mess with already existing things? So, cl2, 3, 4, 9, and 11 UMAPINFO equivalents. I don't think any other complevels are really used.

 

That being said: Cool, it would be nice to place secret maps where I feel like in Boom!

23 hours ago, dew said:

So let me get this straight. I can record a complevel 2 demo on a UMAPINFO project in prboom-plus that will be replayable on pr+, but not on any other non-compliant port, because you just broke the backwards compatability. And there's no need to address it by either altering the header, or creating extra complevels.

 

I cannot condone this. There are ways to fix this (new header for god's sake), but the current state seems like a trojan horse that would destroy prboom-plus' status as the gold standard for demo compatability.

UMAPINFO DOES NOT require Complevels, and doing so is what would permanently destroy compatibility.

If you DeHack your vanilla Doom2.exe, and record a demo, that demo is not going to play properly on unmodified vanilla Doom2.exe either.

Complevels are not a "configure all the settings the way I like" tool, although they are often used for that very purpose. Complevels tell the engine to emulate a particular engine - that is their purpose. The distinction is usually not obvious, but it comes into play in this discussion.

Yes, the addition of UMAPINFO support does require careful care and consideration to ensure preserved demo compatibility. But it is not PrBoom's responsibility to produce demos that run on non-compliant ports. It is the responsibility of non-compliant ports to become compliant. We are discussing enhancements that are to be added to *all* possible ports, to be able to move past Boom/MBF compatibility.

I do agree that *something* needs to exist in the demo file to indicate that it was recorded with modified map information.

Let me take a step back: Yes, there *is* the *potential* to implement things in an ugly way that causes demo compat headaches. I acknowledge this. Maybe, for the time being, demo recording should be disabled if a UMAPINFO lump is loaded.

But, let me also say this: UMAPINFO is the first step towards a new standard beyond Boom/MBF. If we are to move forward with a new compatibility standard that all enhanced ports can adopt, the "complevel" concept needs to be ironed out, after we have defined the enhancements.

Realistically, complevel 2 should not load a UMAPINFO at all if recording is to be done. But, no one wants to add 18 new complevels to support UMAPINFO.

Sorry about the bold text at the beginning of my response. I want to discourage making fast, rash decisions that we have to live with forever, and I want to discourage a misunderstanding of the "complevel" concept. This needs to be considered carefully to balance ease-of-use with confusion-prevention, but, above all else, yes, demo playback must always be preserved.

Personally, I have not given it enough thought to be able to suggest a clean resolution to this issue. I know that I don't yet know how to best resolve it, and I'm hoping that everyone else knows that they don't yet know, too. (if you know what I mean). Many things must all be considered.

kb1, leave this thread alone, please.