PrBoom+ 2.6.66 (Jun 20, 2023)

[T.Will]

For GLBoom+, I think it's fine for it not to have the flashy hardware rendering features of others like GZDoom. The only thing I'm concerned about is some of the rendering issues that makes it inaccurate to software. E4M6 comes to mind. But from what I was told on Github, it requires rewriting parts of the renderer, and no one wants to do it as of now.

 

Why bother fixing the hardware rendering when we have PrBoom software rendering? Because some maps run better in OpenGl, so addressing this is valuable in my eyes.

[Death Egg]

I was looking at the names in the ActorNames array and noticed "Stalagtite" misspelled as "Slalagtite"; is this intentional?

[JadingTsunami]

18 hours ago, Death Egg said:

is this intentional?

 

In the sense that, this is how it is coded, yes. So only that spelling would work.

 

But of course it does look like a typo.

 

EDIT: It's fixed.

Edited February 12, 2021 by JadingTsunami

[ReaperAA]

Regarding the OpenGL upgrade, I'll play the devil's advocate and side with Seed here.

 

The current version of OpenGL that PrBoom+ supports is extremely outdated and it probably won't be long before we may start seeing compatibility issues due to it. Like in case of DirectX versions, where pre-DX9 games have performance issues on Windows 8 onwards.

 

And those who are concerned about performance should know that newer OpenGL =/= worse performance, especially if the hardware is not completely ancient. At times, performance can even increase. I'll give example of a Quake 2 source port here (Yamagi Quake 2). In addition of slightly better visuals and better dynamic lights, I actually get better framerate on OpenGL 3.2 as opposed to the legacy Quake 2 (OpenGL 1.4?) renderer.

 

The improved shaders/visuals is just icing on the cake compared to the advantage of better compatibility with modern systems.

Edited February 12, 2021 by ReaperAA

[seed]

3 minutes ago, ReaperAA said:

I actually get better framerate on OpenGL 3.2 as opposed to the legacy Quake 2 (OpenGL 1.4?) renderer.

 

Of course you do, the more modern version will always play better than the legacy one, which puts you at the mercy of drivers anyway.

 

But all this is a dream you know, PrBoom is staying the way it is for good. The only way to see this kind of stuff is someone else to fork it again, but considering it took this long for it to see contributions again, chances are, a new fork will have a single contributor for the longest time - the developer himself.

 

With the current state of things, I'd only like to see 2 things, but both kinda unrealistic:

 

- fixed projectile translucency in GL. If I recall, Graf said part of the reason why they don't work is due to the render using a naive depth buffer and taking some shortcuts.

- current mouse code to be tossed in the deepest dumpster and replaced with that of a different port, like fabian did with Woof, or get rewritten. Current handling is crap and it feels quite sluggish compared to... virtually all existing and still maintained ports out there, it's as if some slight smoothing/acceleration is always enabled. But I'm not holding my breath since speedrunners in particular will complain that the input got changed after they got so used to the subpar handling.

[Dimon12321]

If we want the render upgraded, someone should dig into the render files and stuff and upgrade it. As a compromise, we can use Vulkan wrapper to prevent compatibility issues, if such an enthusiast won't be found.

People keep their DOS machines to play authentic Doom. So, it's a matter of time, when this "legacyness" reaches Doom for speedrunning. If we dig into this topic, GZDoom is the best perspective choice for non-speedrunning activities, despite its all inaccurate stuff.

Edited February 12, 2021 by Dimon12321

[ketmar]

9 hours ago, Death Egg said:

I was looking at the names in the ActorNames array and noticed "Stalagtite" misspelled as "Slalagtite"; is this intentional?

definitely not intentional. that actor in ZDoom is called "Stalagtite". as the specs clearly says that names should be the same as in ZDoom, this is definitely a bug.

 

4 hours ago, ReaperAA said:

Regarding the OpenGL upgrade, I'll play the devil's advocate and side with Seed here.

the thing is that "upgrading to new OpenGL" means "rewrite the whole renderer from scratch". it's not a simple case of "we will replace that API calls with those API calls and call it a day." "modern" OpenGL is not even close to normal OpenGL, and it requires completely different rendering pipeline (not only code-wise, but logic-wise too). there are not enough people to replace the sound system, so i don't think that expecting a whole new renderer is a realistic goal.

 

besides, the moment new renderer will be introduced, its author will be shited upon for "breaking things". people complain even for harmless blood color change, imagine what shitstorm will raise on renderer change. in my "rating of things i like to deal with after working hard and for free" it is -1000 of 10.

 

and yeah, about having two completely different OpenGL rendering pathes (like, "you don't have to throw away the old one!")... well, twice as much maintenance work for... ah, for the great reward i described above.

[Da Werecat]

It might be harmless as in it won't decapitate your dog, but I like to think that these PrBoom derivatives and Doom Retro occupy different niches, with slightly different standards for what to include and how thorough to be while implementing it.

More than one way to complain though.

[fabian]

1 hour ago, Da Werecat said:

 how thorough to be while implementing it.

 

Feel free to suggest a better, more thorough way to implement it. Right here, right now. 

[Da Werecat]

I said enough about it from my perspective.

[fabian]

21 minutes ago, Da Werecat said:

I said enough about it from my perspective.

 

You suggested future mods to ship custom color translation tables or blood objects. I am asking for a "more thorough" solution that works NOW for IWADs and 99% of all mods. But I agree that you have already said enough...

[seed]

The ship has sailed, Werecat, seriously...

 

Leave it man...

[Gez]

11 hours ago, Death Egg said:

I was looking at the names in the ActorNames array and noticed "Stalagtite" misspelled as "Slalagtite"; is this intentional?

"Stalagtite" was already a typo (it should have been "Stalagmite" logically)...

[Daerik]

8 hours ago, seed said:

- current mouse code to be tossed in the deepest dumpster and replaced with that of a different port, like fabian did with Woof, or get rewritten. Current handling is crap and it feels quite sluggish compared to... virtually all existing and still maintained ports out there, it's as if some slight smoothing/acceleration is always enabled. But I'm not holding my breath since speedrunners in particular will complain that the input got changed after they got so used to the subpar handling.

 

The mouse is fine though? There's definitely not smoothing/acceleration being constantly applied. There's a very slight delay if you're playing uncapped, but it's definitely not enough to make it feel like unplayable garbage.

[Da Werecat]

1 hour ago, fabian said:

I am asking for a "more thorough" solution that works NOW for IWADs and 99% of all mods.

 

I already said that I don't know what to do with old wads. It's a cheap shot, but if you wanted to make a point then sure, you could do worse.

 

Since this ship keeps sailing without actually sailing, I will add that the issue, as minor as it is, goes beyond the color of blood. Last time I found a new cosmetic feature it was as far back as 2.5.1.5, and it was an option to center the weapon while it's firing. I don't remember if I reported it or not, but it broke the second I introduced it to an unusual set of state properties. Namely, I used the sprite offset values, and the way I was using them caused no problems unless this new feature was enabled.

Anyone can come up with reasons why no one should give a fuck. Yes, you can figure it out and disable it. Yes, you'd have to work very hard to find old mods that would be affected by either of these features and their quirks. Not to mention that in both cases happiness is a minor DEHACKED crutch away.

 

But now I suddenly have to study the changelog to make sure that my otherwise compatible mod doesn't look stupid on someone's setup. It's relevant to me, which is why I'm talking about it, and not because I want to attack someone. Both of these features are great. I use one, and I'm planning to use the other.

[ChopBlock223]

If we're all suggesting things, is there any plans to fix Generalized Walkover Crusher linedefs? I've mentioned it before, and it wouldn't be the highest priority, because I believe nothing that's currently published is actually using them (as they don't actually function), but it wouldn't be that much work to get it done some day, right?

[seed]

1 hour ago, Daerik said:

The mouse is fine though? There's definitely not smoothing/acceleration being constantly applied. There's a very slight delay if you're playing uncapped, but it's definitely not enough to make it feel like unplayable garbage.

 

It's not very slight to me at all though, I can definitely see it when going from one port to the next, and while it's not unusable garbage, it most certainly is subpar when every single port in existence that is still maintained offers a superior experience.

[Lippeth]

The perceived mouse smoothing had always prevented me from using PrBoom+. I'm very susceptible to getting motion sickness so the slightest inconsistency between input and display will make it unplayable. Turning on Adaptive sync actually almost fixes the entire issue, but denying that an issue exists at all is inaccurate.

[JadingTsunami]

1 hour ago, ChopBlock223 said:

If we're all suggesting things, is there any plans to fix Generalized Walkover Crusher linedefs? I've mentioned it before, and it wouldn't be the highest priority, because I believe nothing that's currently published is actually using them (as they don't actually function), but it wouldn't be that much work to get it done some day, right?

 

There is currently an open discussion on the general topic. The thread here has details.

[Daerik]

4 hours ago, seed said:

 

It's not very slight to me at all though, I can definitely see it when going from one port to the next, and while it's not unusable garbage, it most certainly is subpar when every single port in existence that is still maintained offers a superior experience.

 

Mouse acceleration is your sensitivity differing depending on how fast you move your mouse.

Mouse smoothing is delaying your inputs as the software tries to guess where you're moving the mouse to.

 

Neither of these are whats happening, I am seeing a 1:1 mouse distance moved to camera turning ingame, regardless of speed.

 

Using a webcam, pointing it at both my hand and monitor, I measured a <50 ms delay between mouse movement and any change showing up on the screen in both PRBoom+ with an uncapped framerate and GZDoom. I'd really like to see what issues your experiencing, because this is definitely not a case of stubborn man rejects change because he's used to it.

 

Fwiw I found the mouse code in 2.5.1.4 to be complete garbage, but 2.5.1.5 onwards has been basically perfect for me.

[Da Werecat]

Could it be platform-dependent? Older versions on Windows seemed to depend on cursor settings, which meant that any acceleration applied by the OS was picked up by the game. With very bad results.

 

It's been a while since that was the case though.

[GoneAway]

21 minutes ago, Da Werecat said:

Could it be platform-dependent? Older versions on Windows seemed to depend on cursor settings, which meant that any acceleration applied by the OS was picked up by the game. With very bad results.

 

It's been a while since that was the case though.

It sounds like seed might have "enhanced pointer precision" enabled, which does cause acceleration. Some ports ignore this setting whereas prboom+ obeys it. Some people actually prefer it on (aka shockblast).

[ChopBlock223]

5 minutes ago, kraflab said:

Some ports ignore this setting whereas prboom+ obeys it. Some people actually prefer it on (aka shockblast).

That's completely insane to me, and it really makes me admire his talent even more.

[Da Werecat]

That's the thing though, there was a time when "enhanced pointer precision" drastically affected mouse input, but it was years ago. Now it doesn't change anything for me, and it feels pretty raw overall. If I want some acceleration, I have to go and set it up in the port's settings.

[ChopBlock223]

4 hours ago, JadingTsunami said:

 

There is currently an open discussion on the general topic. The thread here has details.

Interesting back and forth, at least the parts I understand. Adding functional generalized crushers as a 'new feature' somewhere down the line seems like it would be a viable solution. Generalized scrollers could also be interesting (to add things like being able to scroll a wall texture up or down, etc, without having to depend on the value of the offset or a the angle of a separate linedef which will never not cause textures to stop aligning), but I have no idea how adding something like that may affect things.

[Shepardus]

For me, 2.5.1.4 is affected by "enhance pointer precision," while 2.5.1.5 onwards is not. The worst thing about PrBoom+'s mouse code is that everyone seems to have a different experience with it. For some people (including myself) it's fine, no worse than any other port, while for others it's garbage. For some people 2.5.1.4 is unusable while 2.5.1.5 is fine, but for others it's the opposite, and for others still there's no difference.

[seed]

6 hours ago, kraflab said:

It sounds like seed might have "enhanced pointer precision" enabled, which does cause acceleration. Some ports ignore this setting whereas prboom+ obeys it. Some people actually prefer it on (aka shockblast).

 

I do, in fact - can't control my mouse in Windows otherwise. But it's not a good idea to constantly fiddle with it for one game.

 

Could ignoring the setting be made optional then, maybe?

[Da Werecat]

Does it get better for you if you disable it?

[Spectre01]

Is this just happening on my end, or does shooting the Plasma/BFG up close really chunk the framerate in Software mode? I started noticing how 2-shotting Cyberdemons felt weird. For example, starring at a wall I get 151 FPS, and shooting the Plasma Rifle drops me to as low as 59 in the same spot. This also happens in 3 different versions of the port I've checked and with transparency on and off. Can anyone else confirm or deny this happening at 1080p resolution and why this causes such a performance hit?

[Shepardus]

28 minutes ago, Spectre01 said:

Is this just happening on my end, or does shooting the Plasma/BFG up close really chunk the framerate in Software mode? I started noticing how 2-shotting Cyberdemons felt weird. For example, starring at a wall I get 151 FPS, and shooting the Plasma Rifle drops me to as low as 59 in the same spot. This also happens in 3 different versions of the port I've checked and with transparency on and off. Can anyone else confirm or deny this happening at 1080p resolution and why this causes such a performance hit?

I've noticed framerate drops from time to time when landing point-blank BFG shots, so it's not just you.