PrBoom+ 2.6.66 (Jun 20, 2023)

[Shepardus]

Technically most of those features can be replicated in GZDoom with mods or keybinds set through the console, though it can be quite an undertaking to set things up just the way you want, or to even know what exactly you want.

[JadingTsunami]

6 hours ago, Delfino Furioso said:

ah it's a feature of the opengl renderer since glboom+ and it shows up only after the monster has taken damage

 

In your config file, you can edit the "health_bar_*" settings to customize the health bar display. Enemy health at or below the health_bar_green level will display the health bar.

 

The example below will always show health bars over enemies.

 

Quote

health_bar                        1
health_bar_full_length            1
health_bar_red                    50
health_bar_yellow                 80
health_bar_green                  100

 

 

[Trar]

On 4/21/2022 at 7:20 PM, Gregor said:

Switching from GZDoom to a PrBoom-derived port can be tough at first. Was the same for me. I hated PrBoom+, its menus, how it looked and how much it limited my ability to change everything to my liking. For instance, i always had the chaingun on RMB, but PrBoom+ didn't allow mapping weapons to mouse buttons at the time. I only switched ports when DSDA came out, because it included a lot of the features PRBoom+ lacked that i considered dealbreakers. But in the end, you don't play DSDA/PrBoom+ for its fancy bells&whistles. You play it for the more authentic feel and handling that it brings when compared to GZDoom, besides speedrunning and demo recording. There's a certain beauty to its simplicity and the feeling of playing wads the way they're "meant to be played". Or to put it slightly more combatively: GZDoom is for casuals, Prboom+ for purists.

If you are serious about "broadening your horizon" than you must accept that other ports are not trying to be like GZDoom. They generally go for more of a vanilla feel but without being all barebones vanilla like Crispy or Chocolate. GZDoom is a great port, though, and i still use it all the time.

 

This right here is why I decided to try PrBoom, even though I had no idea DSDA-Doom was its active successor. I didn't know about the backspace thing until I read your post, either, so thank you for that.

 

Would still like "smooth chainsaw bobbing" as a QOL feature in DSDA-Doom though, since weapon and view bobbing are purely visual effects in it now.

[Gregor]

16 minutes ago, Trar said:

 

This right here is why I decided to try PrBoom, even though I had no idea DSDA-Doom was its active successor. I didn't know about the backspace thing until I read your post, either, so thank you for that.

 

Would still like "smooth chainsaw bobbing" as a QOL feature in DSDA-Doom though, since weapon and view bobbing are purely visual effects in it now.

Glad to have been of help. Ask in the DSDA thread about that chainsaw option potentially being included in a future built. Might take some time though. There's quite a backlog of new features to be introduced into DSDA as i understand it, and it's all handled by kraflab more or less.

[Trar]

5 minutes ago, Gregor said:

Glad to have been of help. Ask in the DSDA thread about that chainsaw option potentially being included in a future built. Might take some time though. There's quite a backlog of new features to be introduced into DSDA as i understand it, and it's all handled by kraflab more or less.

 

Went and did that. I'll try Woof/Pooch and see if those are more to my liking. I guess this is the price of having high attention to detail.

[nobleflame]

What's the best midi player in PrBoom+ UMAPINFO? 


I'm currently using portmidi and SDL, but fluidsynth sounds off to me.

 

Any recommendations for better soundfonts to use?

[GoneAway]

I believe there are threads with sound font recommendations. If you do a search you should find them, and you'll find lots of ideas.

[Dweller Dark]

I've never used a soundfont with portmidi or SDL, but Doomkid has some good posts listing and/or linking popular soundfonts on here and on YouTube. I personally use 8MbGM_Enhanced18 with fluidsynth because it sounds more instrumental and clearer to me than Arachno or other similar soundfonts. But you can find anything from SC-55 and the like, to console soundfonts (SNES, etc), and so on. There are a few paid ones I've heard of through different threads as well.

[Shadow Hog]

I use MIDIMapper and LoopMIDI to pipe the MIDI data into the Roland Sound Canvas VA VSTi running in SC-55 mkII mode, myself. That would be through PortMIDI in the in-game menu.

[Blue Phoenix]

I think there is a bug with color translation in sprites.  When a sprite uses color translation in PRBoom its darker over all and the darker shades are dark brown and dark gray instead of the correct color.

[rzh]

On 6/18/2022 at 6:10 AM, Blue Phoenix said:

I think there is a bug with color translation in sprites.  When a sprite uses color translation in PRBoom its darker over all and the darker shades are dark brown and dark gray instead of the correct color.

Are you using the 8-bit software renderer?

[Blue Phoenix]

7 minutes ago, rzh said:

Are you using the 8-bit software renderer?

no.  I use opengl.  Right now I flipped between the video modes and the bug persisted in all of them.

This effect is very noticeable with translation into red as there are brown and black where there shouldn't be

For a demonstration Jamal Jones has Hell Knights and Barons Translated into Brown and Red.

On map E1M17 early on there is temple that requires 2 key, inside are 2 Hell Knight and a teleporter which  takes you to a tower with 2 Barons whose abs are covered in black and brown gunk, unlike other port which their upper torsos are all red.

 

[Shepardus]

15 hours ago, Blue Phoenix said:

no.  I use opengl.  Right now I flipped between the video modes and the bug persisted in all of them.

This effect is very noticeable with translation into red as there are brown and black where there shouldn't be

For a demonstration Jamal Jones has Hell Knights and Barons Translated into Brown and Red.

On map E1M17 early on there is temple that requires 2 key, inside are 2 Hell Knight and a teleporter which  takes you to a tower with 2 Barons whose abs are covered in black and brown gunk, unlike other port which their upper torsos are all red.

Would you mind sharing some screenshots? I just took a look at this in a bunch of different source ports (PrBoom+ software/OpenGL, Woof, Crispy Doom normal/truecolor, GZDoom hardware/software, Eternity), using notarget and noclip cheats to get a good look without the monsters moving around, and in all of them they looked about the same shade of brown to me, not what I'd call red. Edit: Scratch that I'm looking at the wrong enemies lol

 

Okay I see what you mean now, I'll post some screenshots.

 

PrBoom+ (and dsda-doom):

This was taken with the OpenGL renderer but the barons' abs look about the same in software.

 

Crispy Doom (and every other source port I tried):

Edited June 29, 2022 by Shepardus

[JadingTsunami]

On 6/28/2022 at 6:38 AM, Blue Phoenix said:

no.  I use opengl.  Right now I flipped between the video modes and the bug persisted in all of them.

 

15 hours ago, Shepardus said:

Okay I see what you mean now, I'll post some screenshots.

 

That's just how Doom's colormap looks in general. The darker reds are brownish.

 

PrBoom applies the translation based on the colormap rather than the palette directly. I don't know why this is but others may know.

 

I suspect it has been this way for a long time, presumably to permit dynamic colormap swaps.

[fabian]

Isn't `colormaps[0]` usually a direct mapping to the palette colors? 

[JadingTsunami]

44 minutes ago, fabian said:

Isn't `colormaps[0]` usually a direct mapping to the palette colors? 

 

Yeah, but it's being shifted for some reason. Removing the shift would make it looks similar to or same as other ports, I think.

 

 

[Blue Phoenix]

2 hours ago, JadingTsunami said:

 

 

That's just how Doom's colormap looks in general. The darker reds are brownish.

 

PrBoom applies the translation based on the colormap rather than the palette directly. I don't know why this is but others may know.

 

I suspect it has been this way for a long time, presumably to permit dynamic colormap swaps.

The barons still have brown on them on full bright.

[JadingTsunami]

15 minutes ago, Blue Phoenix said:

The barons still have brown on them on full bright.

 

Yes, the effect is not reversed by altering brightness. The remap is happening against the colormap in a way that darkens the sprites (or gives such an appearance).

 

It can be undone by removing that darkening effect. In fact I don't really know why it is there. But others may have some idea.

[DawidKoz09xD]

On 9/22/2015 at 9:02 AM, fabian said:

The latest version 2.6.2 of PrBoom+ with UMAPINFO support has been released on Feb 11, 2022.

 

Source tarballs and the changelog can be found here:

 

https://github.com/coelckers/prboom-plus/releases/tag/v2.6.2

 

Windows 32-bit binaries are available here:

 

https://github.com/coelckers/prboom-plus/releases/download/v2.6.2/prboom-plus-262-w32.zip

Where is glboom plus in the 2.6.2 release? Is it missing or what?

[JadingTsunami]

13 minutes ago, DawidKoz09xD said:

Where is glboom plus in the 2.6.2 release? Is it missing or what?

 

There's no more glboom, just a single unified binary. You can use software or GL renderers without relaunching.

[fabian]

OpenGL support has been merged into the main executable. 

[DawidKoz09xD]

23 hours ago, JadingTsunami said:

 

There's no more glboom, just a single unified binary. You can use software or GL renderers without relaunching.

OK how to turn on opengl render? I am stupid btw.

[JadingTsunami]

9 minutes ago, DawidKoz09xD said:

OK how to turn on opengl render? I am stupid btw.

 

(Main Menu) -> Options -> General -> Video Mode -> OpenGL

 

 

[ChopBlock223]

On 6/29/2022 at 7:14 AM, Shepardus said:

Would you mind sharing some screenshots? I just took a look at this in a bunch of different source ports (PrBoom+ software/OpenGL, Woof, Crispy Doom normal/truecolor, GZDoom hardware/software, Eternity), using notarget and noclip cheats to get a good look without the monsters moving around, and in all of them they looked about the same shade of brown to me, not what I'd call red. Edit: Scratch that I'm looking at the wrong enemies lol

 

Okay I see what you mean now, I'll post some screenshots.

 

PrBoom+ (and dsda-doom):

This was taken with the OpenGL renderer but the barons' abs look about the same in software.

 

Crispy Doom (and every other source port I tried):

IMO it looks better in OpenGL here as there's more contrast giving the shading more depth, the other ports that keep them a purer red has less contrast and they look washed out and flat (especially in contrast to their naturally shaded legs)

It's not a fully pure red, but I think it conveys the intended look well enough.

 

I'm assuming they're working with Vanilla limitations, as they're relying on palette translation, so retouching the sprites to maybe add dithering as to make the red to brown look smoother wouldn't be an option. The relatively limited range of this shade of red would have it come out brown anyway in the dark.

[nobleflame]

34 minutes ago, ChopBlock223 said:

IMO it looks better in OpenGL here as there's more contrast giving the shading more depth, the other ports that keep them a purer red has less contrast and they look washed out and flat (especially in contrast to their naturally shaded legs)

It's not a fully pure red, but I think it conveys the intended look well enough.

 

I'm assuming they're working with Vanilla limitations, as they're relying on palette translation, so retouching the sprites to maybe add dithering as to make the red to brown look smoother wouldn't be an option. The relatively limited range of this shade of red would have it come out brown anyway in the dark.

 

I agree, the top shots look better in terms of detail / shading. Not sure this is a bug, more of a quirk of opengl.

[JadingTsunami]

51 minutes ago, nobleflame said:

I agree, the top shots look better in terms of detail / shading. Not sure this is a bug, more of a quirk of opengl.

 

1 hour ago, ChopBlock223 said:

IMO it looks better in OpenGL here

 

To be clear this is not a case of OpenGL vs. Software rendering.

 

This is why, as noted here (emphasis mine):

 

On 6/28/2022 at 10:14 PM, Shepardus said:

This was taken with the OpenGL renderer but the barons' abs look about the same in software.

 

What's happening is that PrBoom+ is doing the palette translation and is (possibly intentionally?) darkening the sprites at the same time.

 

Why this was done is not clear to me. It could be reversed easily but I would prefer to understand why it's there first before recommending any change.

[DawidKoz09xD]

On 7/5/2022 at 4:03 PM, JadingTsunami said:

 

(Main Menu) -> Options -> General -> Video Mode -> OpenGL

 

 

kk thanks m8

[Blue Phoenix]

On 7/6/2022 at 6:43 PM, ChopBlock223 said:

IMO it looks better in OpenGL here as there's more contrast giving the shading more depth, the other ports that keep them a purer red has less contrast and they look washed out and flat (especially in contrast to their naturally shaded legs)

It's not a fully pure red, but I think it conveys the intended look well enough.

 

I'm assuming they're working with Vanilla limitations, as they're relying on palette translation, so retouching the sprites to maybe add dithering as to make the red to brown look smoother wouldn't be an option. The relatively limited range of this shade of red would have it come out brown anyway in the dark.

There is a newer version internally with better contrast:

GZdoom

Doom2.exe(DOSBox)

 

consequently in PRBoom they look awful:

Opengl

8 Bit

[Kotzugi]

My OpenGL sector light mode seems to be borked. I'm speedrunning a map but it's quite dark, so I'm trying to use GZDoom instead of GLBoom. Halfway through, the lights go dark again. If I then go back and select the same option, it goes light for a little while, and then goes back again. The same happens if I switch to shaders. It was not much of a problem before, now it happens all the time (perhaps within 30 seconds of playing).

 

I made a 45 seconds nomo demo (where it happened twice) and when I adjust it at the beginning, the switch doesn't happen afterwards. Only when I play or record.

 

I'm no expert so perhaps I'm missing something simple. I haven't changed any of the default options AFAIK. Using prboom-plus-262-w32. Cheers

[JadingTsunami]

1 hour ago, Kotzugi said:

My OpenGL sector light mode seems to be borked. I'm speedrunning a map but it's quite dark, so I'm trying to use GZDoom instead of GLBoom. Halfway through, the lights go dark again. If I then go back and select the same option, it goes light for a little while, and then goes back again. The same happens if I switch to shaders. It was not much of a problem before, now it happens all the time (perhaps within 30 seconds of playing).

 

I made a 45 seconds nomo demo (where it happened twice) and when I adjust it at the beginning, the switch doesn't happen afterwards. Only when I play or record.

 

I'm no expert so perhaps I'm missing something simple. I haven't changed any of the default options AFAIK. Using prboom-plus-262-w32. Cheers

 

How are you brightening the map? Are you adjusting gamma or relying on the fact that some of the lighting options just appear brighter for some reason?

 

Also, what are your system details (OS, graphics card, etc.)?