PrBoom+ 2.6.66 (Jun 20, 2023)

I'm planning to transition the project to CMake to consolidate the multiple project configurations some of which target ancient compilers which I do not own and cannot maintain. My main problem here is that this has some rather obscure dependencies, meaning I could use some help to set up the dependencies so that configuring the project on Linux will find all of them.

Thanks for taking care of this port, @Graf Zahl !

First, please make sure to merge in the latest changes from SVN, I have fixed a couple of minor bugs there.

Second, I am the Debian maintainer for the prboom-plus package, so I could help out with building on Linux. However, I have a strong aversion against CMake, so I could probably test the builds, but will not bother myself with learning another build system's syntax.

8 minutes ago, fabian said:

However, I have a strong aversion against CMake, so I could probably test the builds, but will not bother myself with learning another build system's syntax.

I have a strong aversion against projects that contain setups for 4 incompatible build systems. ZDoom once also had multiple ones in the past and they never were in sync, so I'd rather have one project setup that can target everything.

The only thing I really need is what packages I need to add. Some of the dependencies are obvious, but there's a few ones where I don't know what package names they have in CMake and I cannot test it myself. Most of the rest I can take from GZDoom's CMake project anyway.

Does CMake check for pkg-config files or do you need header/library names?

That's the problem - I do not know what precisely gets checked here, on Windows it is always necessary to manually fill those in after configuring. This will need a bit of input from someone who is more familiar with CMake on Linux.

@AlexMax set up CMake for Chocolate Doom. Maybe he is able to provide the necessary input here.

What's UMAPINFO?

1 minute ago, Sector 147 said:

What's UMAPINFO?

I just posted an update to fix a major bug in the episode menu.

Do you have any plans to develop this port even further or is the mission already accomplished with the umapinfo implementation? 

Someone maitaining this port would be fantastic to be honest, because well, it kinda looks like Andrey is starting to run out of steam...

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.

Just downloaded it to try it out. Well I am getting HOMs almost everywhere in GlBoom+. PrBoom+ doesn't have this issue.

Edit: Also, autoaim is not working in GlBoom+. But working fine in PrBoom+

Maybe the colored blood from this version by Fabian could also be incorporated.

Lately I've thought about suggesting a lump called "bloodinfo" or something that certain ports could use to determine what monsters bleed what color. So for example, you could have a line in it with a monster's editor and/or dehacked number, then an equals sign, then the range in the playpal you want the default blood graphic to be translated to. I dunno. Just a potentially thread-derailing idea that could be a lot more effort than it's worth.

Blood colorization is not the most complex thing - GZDoom had it for over 10 years.

27 minutes ago, ReaperAA said:

Edit: Also, autoaim is not working in GlBoom+. But working fine in PrBoom+

Are you sure both use the same settings? Both EXEs use separate config files.

48 minutes ago, ReaperAA said:

Just downloaded it to try it out. Well I am getting HOMs almost everywhere in GlBoom+. PrBoom+ doesn't have this issue.

 

Now that is interesting. VS 2019 uses SSE2 as a default for floating point math and that is indeed broken. Setting the compiler to output x87 math looks correct, this suggests some MAJOR math bug with angular math somewhere in the code that is platform dependent...

I know that both instruction sets have different integer conversion semantics so something in there must have taken the x87 behavior for granted.

35 minutes ago, Graf Zahl said:

Are you sure both use the same settings? Both EXEs use separate config files.

Well u r right. It was a config issue. That got fixed

Good to know. The math bug in the GL renderer is troubling, though. It makes me wonder how this code could ever be compiled on 64 bit Linux which requires SSE2 math.

But in the end this is the result of sticking with ancient compilers and never properly testing the code with more modern settings.

And it's going to be a PITA to find out what went wrong here.

About time this happened. What problems does it pose for demo compatibility\playback?

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!

7 minutes ago, Marcaek said:

About time this happened. What problems does it pose for demo compatibility\playback?

None. This is strictly in the renderer code. The problem comes from floating point -> integer conversions being totally undefined when outside the range of the target type. This was something I had to find out the hard way in GZDoom a few years ago. x87 is different from SSE2, and both are different from ARM, and probably from AVX as well. The solution in GZDoom was to use a custom conversion function for anything critical - the problem with that is that it's template-based C++ code that cannot be ported to C easily.

My guess here is that the code tries to convert binary angles to floating point and back - and that simply does not work with a simple cast to an integer type, the only way this can ever work compiler-independently is to use the aforementioned conversion function. On older compilers this wasn't an issue because the system provided version on those older compilers did it just correctly by happenstance. On more recent compilers this isn't the case for either instruction set.

4 minutes 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. 

I don't think this is really needed - unless you intend to record demos on UMAPINFO-based projects without any UMAPINFO-based settings. Aside from that, if the map definitions differ, it's not much different from the level itself not being identical, i.e. the demo will most likely desync if this triggers a difference in behavior.

2 minutes ago, Graf Zahl said:

I don't think this is really needed - unless you intend to record demos on UMAPINFO-based projects without any UMAPINFO-based settings. Aside from that, if the map definitions differ, it's not much different from the level itself not being identical, i.e. the demo will most likely desync if this triggers a difference in behavior.

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.

12 minutes 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.

I'm confused. I might be reading this wrong, but you're saying UMAPINFO project demos wouldn't be able to play on non UMAPINFO ports, right? 

Well isn't that kinda obvious? Not sure what the problem is there, so I'm probably misinterpreting.

The contention is that prb+ demos ideally conform to the standard that [complevel in header] = [plays back with that corresponding port]. (there are some cases where this isn't true, like if prb+ tolerates map-specific features that would crash the original exes being emulated, etc).

At a bare minimum some new header information is required, maybe embed certain bits of umapinfo data in the footer as well? Should a UMAPINFO-supporting port bomb out if the mapinfo in the demo data doesn't match the wad that's loaded?

14 minutes ago, TheMightyHeracross said:

I'm confused. I might be reading this wrong, but you're saying UMAPINFO project demos wouldn't be able to play on non UMAPINFO ports, right? 

Well isn't that kinda obvious? Not sure what the problem is there, so I'm probably misinterpreting. 

Yes. The problem is that the non-supporting ports will have no idea about this. The demos produced by pr+ would look like demos perfectly compliant with the specified complevel, but they'd break the strict ports in horrible ways. Just imagine that an otherwise vanilla project used UMAPINFO to specify that e1m1 leads to e1m5 and you try to replay the demo on choco. Since this new tech is implemented into pr+, we can avoid such scenarios by changing the first byte of the demo header to a new value if the UMAPINFO lump is present, so that "ignorant" ports will refuse to play it in the first place.

9 minutes ago, Ribbiks said:

The contention is that prb+ demos ideally conform to the standard that [complevel in header] = [plays back with that corresponding port]. (there are some cases where this isn't true, like if prb+ tolerates map-specific features that would crash the original exes being emulated, etc). 

A minor correction: complevels aren't specified in the header. Ultimate Doom 1.9 (cl3), final release of Doom 2 (cl2) and Final Doom (cl4) all share the same header and pr+ recognizes the complevel by the iwad loaded in the footer. Or more obscurely, by demo name pattern (hi, Grazza). The header itself differs drastically for older versions like 1.2 (a very primitive one, useless for anything) and then for Boom.

I'm saying this UMAPINFO change should follow Boom's lead and inflict a change of the header - just a new identifier in the first byte would be sufficient, anything extra that is required for emulation can technically go into the footer, because by default this would make the demo unplayable for any non-compliant port.

Seems like quite a minor problem for something that would "destroy prboom-plus' status" as the demo compatibility standard though IMO. I wouldn't see why someone would try to play a demo for a UMAPINFO WAD on a port that doesn't support it in the first place.

I'm only arguing this because I wouldn't want people to see statements like that and start to oppose the feature's addition into the port (and others). 

Adding non-compliant, compatability-destroying features is not a minor problem, it's an issue that needs to be resolved or this entire proposition fails. We need to prevent as many inconsistencies as possible right from the start. What if someone records on UDoom with an extra wad that adds UMAPINFO? Adding features is a nice thing, but it must not be done haphazardly and prboom's backward compat must be guarded jealously.