PrBoom-Plus, ver. 2.5.1.4

On 9/4/2019 at 3:27 PM, Shon_RT said:

I have encountered a strange glitch in PrBoom+ 2.5.1.4 where when I watch back demos for some reason all the sound except the game music isn’t played and my controls like pausing the game or stopping the demo are locked and I have to alt F4 to exit or I can click my mouse and that seems to fix the game sounds and demo controls. I haven’t had this problem until recently.

Bern having that "error" for as long as I used prboom. Years. The only guess I have on the spot is hardware.

prboom video settings seem too bright. How do I fix that?

2 hours ago, DoctorFrickinRetro said:

prboom video settings seem too bright. How do I fix that?

Hit f11 to cycle through brightness levels. The default is 0 and tends to look the best.

57 minutes ago, Spectre01 said:

Hit f11 to cycle through brightness levels. The default is 0 and tends to look the best.

big thanks c:

Gamma correction can only go up in conservative ports, which may be a little outdated with modern screens. This could be a suitable (if clumsy) alternative when level 0 is still too bright.

Does the chasecam feature when doing demo playback work like a 3rd person camera that follows you around? I tried it out via Numpad 0 but it just "dropped" the camera and didn't follow me around.

I'd like to use FluidSynth reverb but its strength seems to be set too high. Is there any way to decrease it?

When you run out of ammo with cl9 or higher, PrBoom+ continuously tries to autoswitch to the most preferred weapon and doesn't let the player switch to what they want. E.g. I spent all my cells with the plasmagun and want to use the rocket launcher but the port inserts a bunch of commands to change to ssg (one can notice this by inspecting Boom or MBF demos in XDRE); I have to switch to it first and only then to RL. This patch fixes that and adds an option to disable autoswitching completely.

I am trying to make videos of my demos to upload to YouTube. 

Could someone please give me a guide for dummies on how to use the vid dump command, which I've heard can be very useful for this?

I am using PrBoom+ 2.5.1.4 on Windows 10 and I would like to output an mp4 of a demo. It is also useful for me to be able to put in some moments of looking at the map sometimes, or pauses. 

Autoswitching is so broken it even affects manual switching. Boom had a feature where it allowed you to switch directly to SG while bypassing SSG, but if you try to use it now - SSG will appear anyway, because... well, because it has a higher priority on the list. Duh?

You can edit the list to your preference, but then you'll have SG being preferred when running out of ammo for other weapons, which may or may not be acceptable.

Hello, I'm new to this forum so sorry if this question is stupid for this place: will there ever be any lighting enhancements made to glboom? and if not, is the only acceptable hardware accelerated version of doom GZDoom? I would like to play vanilla/boom compatible wads in glboom instead of GZDoom, but I'm spoiled by the nearly perfect rendition of software rendering in newer versions of GZDoom. The reason I'm looking for hardware acceleration is because I am not a believer that Doom looks better at lower resolutions, I really enjoy being able to see Doom's spritework at full crisp QHD or UHD. So in essense, my dream sourceport would be glboom but with a better software lighting emulation, which I am really hoping would exist someday.

Doesn't glboom-plus have an identical lighting mode? It may be called differently, like "shader" or something.

Shaders is indeed the best sector light mode in GLBoom+ and the closest at emulating Software's diminishing light levels. However, GLBoom+'s renderer is ancient and nowhere near GZDoom's ability to emulate Software in OpenGL. It's one of the aspects, along with sound quality, that could really use an upgrade if development on the port picks up steam again.  

Yeah, the light modes in GlBoom are not as advanced as in GZDoom, it has 4 sectors light modes though, and Shaders is as close as GlBoom gets to a Software-like sector lightning. I think the GZDOOM sector light is essentially GZDoom's "Stardard" sector light.

GZDoom sector light mode is the best for all-around visibility in GLBoom+, especially for dark areas. Shaders has the unfortunate side effect where light diminishes to the point of total darkness in low-lit areas, completely obscuring any monsters there. Meanwhile, in Software mode, the textures and monsters would be seen with some dark grey highlights on them.

To illustrate in a map I recently "finished", containing lots of dark sectors. The Imp is standing in a sector with a brightness of 96.

Using Shaders, you can't see shit past like 1 meter in that sector:

In GZDoom light mode, you can clearly see the Imp but miss out on the diminishing light effect:

And finally, in Software mode (where I forget to turn off my HUD), the Imps shows up as a black outline against a dark grey background:

44 minutes ago, Spectre01 said:

GZDoom sector light mode is the best for all-around visibility in GLBoom+, especially for dark areas.

  Hide contents

 

In GZDoom light mode, you can clearly see the Imp but miss out on the diminishing light effect:

  Hide contents

 

And finally, in Software mode (where I forget to turn off my HUD), the Imps shows up as a black outline against a dark grey background:

  Hide contents

 

That's debatable. Without gamma correction? GZDOOM is definitely the best.

However, gamma correction in GLBOOM seems to work differently, by raising the overall ambient light level of the map, which can be super useful and doesn't have the side effect of making everything washed out. It also has fewer levels (I think 7 or so), versus 32 like the rest (not like it's usable beyond level 6 though, lol).

Right, GLBoom mode has 4 gamma levels, just like Software, and the most flexible gamma correction. But it's also the flattest and least atmospheric of all the lighting option, IMO. I always try to keep gamma at default when I play, unless I'm recording a demo or something and the map is really dark.

7 minutes ago, Spectre01 said:

Right, GLBoom mode has 4 gamma levels, just like Software, and the most flexible gamma correction. But it's also the flattest and least atmospheric of all the lighting option, IMO. I always try to keep gamma at default when I play, unless I'm recording a demo or something and the map is really dark.

Indeed. I like keeping my gamma correction to 0 when playing too, but some maps really need to have it set higher. GLBOOM's does make things look considerably more flat, but if I have to play the "pick your poison" game and choose between washed out/overbright vs flat, yep, I'll definitely choose the latter.

4 minutes ago, seed said:

Indeed. I like keeping my gamma correction to 0 when playing too, but some maps really need to have it set higher. GLBOOM's does make things look considerably more flat, but if I have to play the "pick your poison" game and choose between washed out/overbright vs flat, yep, I'll definitely choose the latter.

I usually change the setting according the map I am playing. For demo recording (like for DWIL), I always choose Glboom lighting mode because you never know when you would come across a dark as hell area. But I am not recording a demo and the map isn't dark, I change the setting to GZdoom lighting mode.

5 hours ago, dontpokethebear said:

Hello, I'm new to this forum so sorry if this question is stupid for this place: will there ever be any lighting enhancements made to glboom? and if not, is the only acceptable hardware accelerated version of doom GZDoom? I would like to play vanilla/boom compatible wads in glboom instead of GZDoom, but I'm spoiled by the nearly perfect rendition of software rendering in newer versions of GZDoom. The reason I'm looking for hardware acceleration is because I am not a believer that Doom looks better at lower resolutions, I really enjoy being able to see Doom's spritework at full crisp QHD or UHD. So in essense, my dream sourceport would be glboom but with a better software lighting emulation, which I am really hoping would exist someday.

GZDoom does support true color rendering which is i reckon the near perfect rendition you speak of.

I do believe there is a case to be made here for GLBoom to recieve some renderer upgrades, but i do not believe it should raise OpenGL requirements. Within the OpenGL2 framework, i reckon you can still do quite a bit in terms of expanding visual fidelity without turning into GZDoom.

5 hours ago, Da Werecat said:

Doesn't glboom-plus have an identical lighting mode? It may be called differently, like "shader" or something.

AFAIK GLBoom-Plus has 3 renderer modes:

• OpenGL 2.0. This is the Shader variant.
• OpenGL 1.3. This along with the Shader mode are the primary renderers.
• OpenGL 1.1. This is a compatibility mode.

Obviously GLBoom is thus not as advanced as GZDoom in its current form and its more akin to GZDoom 1.8.6 and 1.9.x which were OpenGL 1.4 and OpenGL 2.0. Even then, the renderer differs rather significantly i reckon.

Running PrBoom-Plus in windowed mode (in a very recent commit of Graf's fork, but I'm sure the problem is the same in the latest build of the original PRBoom-Plus), Gamma Correction in OpenGL with PrBoom-Plus changes the gamma of the entire desktop if the render mode isn't set to GLBoom. Also on my system, levels are brighter on Software mode than OpenGL with GLBoom rendering.

If you use hardware gamma on a window it will inevitably affect the entire screen. The only way around this is software gamma done in a postprocessing shader.

On 1/17/2020 at 11:24 AM, Redneckerz said:

I do believe there is a case to be made here for GLBoom to recieve some renderer upgrades, but i do not believe it should raise OpenGL requirements. Within the OpenGL2 framework, i reckon you can still do quite a bit in terms of expanding visual fidelity without turning into GZDoom. 

That's really easier said than done, All those useful things for improving visual fidelity are no-gos on real GL2 hardware. It surely will run acceptably if you use it on GL3.3 compatible hardware but this particular combination makes it very unappealing.

This boils down to the problem that those GL2.x Intel chipsets have extremely poor shader performance (mainly courtesy of the low quality drivers)

In the end, trying to get the best out of modern hardware while clinging on to GL2 support is not going to work. The main blocker here would be macOS which doesn't offer ANY post-GL2.1 features in a compatibility profile which you need to run GL 2. (On Linux Open Source you get at least 3.1 which still isn't sufficient.)

There's also another issue: You cannot optimize a renderer for both GL 2 and GL 4. What runs fast on GL 2 runs slow on GL 4 and vice versa.

Any GL 2 renderer today would severely compromise the performance on modern graphics hardware, sometimes to the point where it isn't smooth anymore.

Running into an issue where it seems that V-Sync creates choppy video. Thought it was actually my mouse at first and it drove me nuts, but it turns out that PrBoom+ seems to have some sort of uniquely bizarre problem where V-Sync causes the game to hitch up. Most are small, but it actually created a pretty significant hitch at one point during standard gameplay.

Sorry if this has been brought up before but there's a lot of fucking replies in here.

Is there an updated Mac version of PrBoom+? The latest download on the Sourceforge is from 2016. I couldn't get it to work when I first got this Macbook ~three months ago, but since upgrading to MacOS Catalina it won't even so much as install. Something to do with MacOS dropping support for 32-bit programs it seems.

Would I have to use Wineskin in order to use PrBoom+ on MacOS?

No need for Wine at all - although there has been no official binary release for macOS for a while, the code can still be compiled on Catalina just fine.

Here's prboom-plus-2.5.1.5 for macOS Catalina that I compiled for myself from the SourceForge repo, lemme know if it works for you. Alternatively, you can always compile it yourself ;)

prboom-plus-2.5.1.5.zip

wasn't able to run that exe (our dylibs are in different locations and I'm too lazy for install_name_tool atm :p).

compiling on osx can have a bit of a learning curve (here's my previous post on it, which is potentially outdated by now).

I can also confirm that this runs: https://github.com/alexey-lysiuk/prboom-macos, and has comparatively simple instructions.

Yeah, I suspected some libraries might end up missing (the 1 MB archive kinda gives it away), but I don't have a second mac test it on vOv

24 minutes ago, Ribbiks said:

here's my previous post on it, which is potentially outdated by now

OpenGL paths have been fixed since, so you can install xcode and the dependencies and go straight to step 5 now, though. I also didn't have to set CPPFLAGS/LDFLAGs, but I used homebrew to install the libraries.

Ok, so figuring out RPATHs and install_name_tools requires more effort than I'm prepared to put into this, so I would rather advise to go with the link Ribbiks posted :P

But if anyone wants to dive deeper, here's a link to my gist on github with a guide to building prboom-plus on macos that is up to date. Most likely the executable from my archive will run if you just install homebrew and the required libraries (the 'brew install ...' steps), although installing Xcode might also be needed to get the opengl framework, or you can just go all the way and do the whole thing.

This video reminded me of a thing this port has where invulnerability has one or two colors that crap out. Shouldn't be hard to find, but one of the periods starts around 6:40. It doesn't always happen.

31 minutes ago, Da Werecat said:

This video reminded me of a thing this port has where invulnerability has one or two colors that crap out. Shouldn't be hard to find, but one of the periods starts around 6:40. It doesn't always happen.

This is an error in Doom 2 the Way id Did's modified COLORMAP. It can be traced back to this:

The column of pixels I've highlighted is the darkest color in the blue range, which is actually 0,0,0 RGB. In the inverted Invulnerability palette, it should therefore be pure white, but as you can see in the lowest highlighted pixel constituting the row of inverted Invulnerability colors, it instead shows up as a dark grey.

Simply fix this one pixel and you'll have a bosh lookin' Super Shotgun in D2TWID, among other things with pure black in them.