PrBoom-Plus, ver. 2.5.1.4

Can anyone help me figure out a framerate issue?

In capped framerate mode, it seems to run choppy on every video setting. I'm using Windows 10. I had an identical issue in Crispy Doom until I set it to look to the DirectX video driver, and a similar issue in Eternity until I set it to SDL GL2D.

Also, is there any way to automatically set the automap colors to match the original game? Or a reference for setting its colors manually? Not a huge fan of how many extra hints the default PrBoom+ map builds in.

Otherwise it's a very good port and I'd like to get it working.

kraflab said:

In the most recent 2.5.1.5 test build, my mouse sensitivity is noticeably different than in 2.5.1.4, with the same exact settings in the config file, also verified in the interface in-game.

Is there a way to fully compensate for these mouse movement differences in the newest tested build? In 2.5.1.4, I have my mouse sensitivity to 10, but this setting is far too low in 2.5.1.5. Cranking the sensitivity up to 30 comes close to matching the speed in 2.5.1.4, but the overall mouse movement is still very different.

To specify, in 2.5.1.5, I am not able to turn with the same precision as 2.5.1.4, as if my movements are being dampened. I have to assume mouse acceleration isn't at fault here since that's still set to 0 in my config. However, it really does seem like some sort of noticeable mouse smoothing is being applied, and there's no setting to control that. The difference is very obvious when jumping between versions and just quickly turning back and forth.

Cipher said:

In capped framerate mode, it seems to run choppy on every video setting. I'm using Windows 10. I had an identical issue in Crispy Doom until I set it to look to the DirectX video driver, and a similar issue in Eternity until I set it to SDL GL2D.

Try to set sdl_videodriver in prboom-plus.cfg to "directx" if you're using SDL1 prb+ (2.5.1.4).

Or a reference for setting its [automap] colors manually?

Options->Setup->Automap->2nd and 3rd pages.

38_ViTa_38 said:

Try to set sdl_videodriver in prboom-plus.cfg to "directx" if you're using SDL1 prb+ (2.5.1.4).

Huh. It was that easy. Thanks!

38_ViTa_38 said:

Options->Setup->Automap->2nd and 3rd pages.

That's not what he meant. When he said reference, he meant a reference, as in a picture or file that already has the correct colors that he can then use to correct the colors in his own config file. I would also greatly like one.

So this problem is connected to SDL2 somehow? Weird...

Cipher said:

Also, is there any way to automatically set the automap colors to match the original game? Or a reference for setting its colors manually?

There's no automatic way, but you can open prboom-plus.cfg or glboom-plus.cfg in a text editor and replace the "Automap settings" section with these values:

# Automap settings
mapcolor_back             0xf7
mapcolor_grid             0x68
mapcolor_wall             0xb0
mapcolor_fchg             0x40
mapcolor_cchg             0xe7
mapcolor_clsd             0xe7
mapcolor_rkey             0x70
mapcolor_bkey             0x70
mapcolor_ykey             0x70
mapcolor_rdor             0x0
mapcolor_bdor             0x0
mapcolor_ydor             0x0
mapcolor_tele             0x0
mapcolor_secr             0x0
mapcolor_exit             0x0
mapcolor_unsn             0x63
mapcolor_flat             0x61
mapcolor_sprt             0x70
mapcolor_item             0x70
mapcolor_hair             0xd0
mapcolor_sngl             0xd0
mapcolor_me               0x70
mapcolor_enemy            0x70
mapcolor_frnd             0x70
map_secret_after              0
map_point_coord               0
map_level_stat                0
automapmode               0x9
map_always_updates            1
map_grid_size               128
map_scroll_speed              8
map_wheel_zoom                1
map_use_multisamling          0
map_overlay_pos_x             0
map_overlay_pos_y             0
map_overlay_pos_width       320
map_overlay_pos_height      200
map_things_appearance         0

If you're using GLBoom+, you'll also have to disable "Textured Display" to remove the flats rendering.

PrBoom+ does irrevocably change the way a few things are rendered in the automap, but these settings will get you 99% of the way towards matching the original look.

Comparison for reference/funsies:

Revenant100 said:

To specify, in 2.5.1.5, I am not able to turn with the same precision as 2.5.1.4, as if my movements are being dampened. I have to assume mouse acceleration isn't at fault here since that's still set to 0 in my config. However, it really does seem like some sort of noticeable mouse smoothing is being applied, and there's no setting to control that. The difference is very obvious when jumping between versions and just quickly turning back and forth.

If you're running Windows, in the Windows registry, there's a section dedicated to mouse acceleration. The Mouse Control Panel properties apparently don't let you completely turn off this mouse acceleration, and programs cannot do it either (though they may try to cancel it out with tricky algorithms - don't know if PrBoom is doing that or not); but there's a registry hack that does it. I'm sorry that I can't direct you towards it now, but hit up Google - I've heard that that works. Someone else, please confirm.

EDIT: In re-reading, I noticed that you said it changed since last version, so the registry hack might not be the way to go, but then again, it may improve things a different way. I'd love to hear from someone that actually did the registry change: How did it work? Did it improve precision? Did it make the mouse feel more "like vanilla in good ol' DOS"?

In response to mouse sensitivity: SDL2 grabs "raw" mouse input, unaffected by the Windows operating system, whereas SDL1's mouse input is affected by options such as "Enhance pointer precision". If you're used to the Windows acceleration and can't cope, you'll just have to ask any SDL2-migrating source port to emulate it. Here's an article on the subject.

Revenant100 said:

There's no automatic way, but you can open prboom-plus.cfg or glboom-plus.cfg in a text editor and replace the "Automap settings" section with these values:

Thanks for this. It's exactly what I was looking for. I'd fiddled around with changing some of the colors on my own, but wasn't sure I was winding up as close to vanilla as I wanted.

Revenant100 said:

Comparison for reference/funsies:
http://i.imgur.com/6eGh7Ae.png http://i.imgur.com/mGjFWsp.png

That automap stretching...

Aside from ports like Chocolate Doom and its derivatives, what ports actually try to keep the correct aspect ratio for the automap?

Is it possible to fix ludicrm map 3 glitch in software? I assume it's related to some overflows because everything becomes fine after pressing the switch.

Any chance of GLBoom+ getting resize filters besides ScaleX? xBRZ would be nice.

38_ViTa_38 said:

Is it possible to fix ludicrm map 3 glitch in software? I assume it's related to some overflows because everything becomes fine after pressing the switch.

hope it fixed now

It works fine now, thanks.

What's wrong with linedef 11 in GO4IT.WAD? In software a part of it seems to suffer from bad calculations, as you can see in this video.



Edit: prboom-plus fails to cross-compile on Debian for Windows with mingw-w64 because #include is case-sensitive:

../../src/e6y.c: At top level:
../../src/e6y.c:1296:22: fatal error: Mmsystem.h: Нет такого файла или каталога
 #include <Mmsystem.h>

Mac release seems broken for me. When I try to run it, the launcher works but the game draws an empty window then it disappers. The process is still running (pegging a CPU core) but nothing is displayed.

Tried zapping ~/Library/Application Support/Prboom-Plus, but no joy.

GL render seems ok , just software broken.

is that the old 2.5.1.3 dmg?

fwiw the latest source compiles and runs nicely on Mac (barring a quirk or two that makes the sdl2 version unusable for certain things :p)

Ribbiks said:

is that the old 2.5.1.3 dmg?

Yes.

Ribbiks said:

fwiw the latest source compiles and runs nicely on Mac (barring a quirk or two that makes the sdl2 version unusable for certain things :p)

Good to know, thanks!

Edit: needed to fudge LDFLAGS and disable-gl, but otherwise does the trick!

if gl-graphics is important to you just have to make some symlinks that point from where the libraries actually are to where prb+ is willing to look for them.

this post might have some helpful details, though it seems with every new os X those GL libs move somewhere else :p

When I'm playing sometimes it happens that the weapon switches to another one and then it keeps to switch back to that weapon if I try to change it, even if I don't have anymore ammo for it. Other times it also happens that for a few seconds it automatically moves into a certain direction, and then I can move normally again.
Does anyone know something about these problems?

Sounds like a keyboard problem.

Why does PrBoom+ tolerate textures without patches instead of quitting with error? And why is it a black pattern instead of an obvious checkerboard pattern? Because of this, I can bet that unaware authors are gonna assume that 0-patch texture means black. I just updated Eternity to also render black (it used to exit with error), because ZDoom is also on this bandwagon, and I don't want wads to look worse in Eternity than in PrBoom+ (because of the blackness assumption), but I really wish it was checkerboard instead.

27 minutes ago, printz said:

Why does PrBoom+ tolerate textures without patches instead of quitting with error? And why is it a black pattern instead of an obvious checkerboard pattern? Because of this, I can bet that unaware authors are gonna assume that 0-patch texture means black. I just updated Eternity to also render black (it used to exit with error), because ZDoom is also on this bandwagon, and I don't want wads to look worse in Eternity than in PrBoom+ (because of the blackness assumption), but I really wish it was checkerboard instead.

By also adding the functionality to Eternity, you are effectively condoning the behavior (not a criticism - I understand and sympathize with your reasoning).

 

You could go other ways with it: Menu/command-line/console option, defaulted to checkerboard pattern, put back the error code, or maybe soften it (display a bug in the console). Arguably, the black texture is more presentable than the checkerboard pattern, for people that just want to play the damn wad. Question: Does this also affect missing patches? Do they also get painted black, or checkerboard, or just HOM? I would think those should show checkerboard, as it can only occur as a mistake, whereby a map author could conceivably purposefully make a 0-patch texture.

I thought ZDoom *did* use a checkerboard. Maybe they switched to black. Just use checkerboard in Eternity. And fix boom 242 whilst you're at it :P

Ok, both your and kb's opinion make me reconsider. It would be harmless to use checkerboard. Just like how so called vanilla maps are tainted by TFE.

On 13/3/2017 at 8:08 PM, Memfis said:

Sounds like a keyboard problem.

Guess you are right, I tried with a different keyboard and I didn't had those problems anymore.

9 hours ago, printz said:

Ok, both your and kb's opinion make me reconsider. It would be harmless to use checkerboard. Just like how so called vanilla maps are tainted by TFE.

Could the black output be an artifact of the texture compositor? Like it zeros out its buffer before loading patches, PNGs, turning flats into walls, etc? (I really need to brush up on the various port's progress).

Personally, I'm very happy for the raw mouse input. The way Windows acceleration affected the controls before was almost insufferable, and there was no clean way to reduce the acceleration because of it. I'm assuming it's possible to emulate the old forced acceleration somewhat by cranking up the acceleration slider in the menu? Not that I need it.

 

On 28.02.2017 at 9:03 AM, Danfun64 said:

That automap stretching...

Aside from ports like Chocolate Doom and its derivatives, what ports actually try to keep the correct aspect ratio for the automap?

I'm not sure stretching things vertically can be called "correct" in this case.

On 15/03/2017 at 9:18 PM, printz said:

Why does PrBoom+ tolerate textures without patches instead of quitting with error?

I guess it was to allow playing some wad or other that was otherwise broken. Not sure exactly which one, but an analogous case, allowing unknown texture names in R_TextureNumForName is one of the things you need to do in order to allow Deus Vult map05 to run unmodified. Another example: a change allowing sfx #0 to play without crashing the game was made recently for Luducrium.

 

On 15/03/2017 at 9:18 PM, printz said:

And why is it a black pattern instead of an obvious checkerboard pattern? Because of this, I can bet that unaware authors are gonna assume that 0-patch texture means black.

It's not quite a black pattern but a fill-in-the-holes-with-adjacent-pixels pattern, as I explain below, but kb1 is already onto the right answer.

 

12 hours ago, Jon said:

I thought ZDoom *did* use a checkerboard. Maybe they switched to black.

I believe ZDoom uses a checkerboard for unknown/missing textures/flats, but fills in holes in known textures with black when they're used on solid segs.

 

50 minutes ago, kb1 said:

Could the black output be an artifact of the texture compositor? Like it zeros out its buffer before loading patches, PNGs, turning flats into walls, etc? (I really need to brush up on the various port's progress).

That's exactly right. That's how it works now. Originally it worked like this:

 

- Allocate enough memory for width x height pixels (as bytes, indices into the palette), column major order.

- memset the lot to 0xff (a horrible shade of pink, you know the one that id's graphics editor used to represent transparency)

- render the patch columns into the space as appropriate

- compute a run-length encoding of transparent parts of columns so you can skip them more easily when drawing transparent patches

- finally do this weird "copy patch pixels down and right" to fill in the holes of a patch/texture that had transparent parts.

 

You need a bitmap to turn into a GL texture, you can't just use Doom's old patch format on a graphics card. I think there was a comment to that effect anyway, I don't know or care much about hardware rendering.

 

You also need to fill in the pink holes with the adjacent colour of the texture. This is because you get rounding error in the column drawers, and read the texture pixel next to the one you really want. To minimise the effect of this you copy the edges of the patch into the holes left by transparent parts.

 

This is what the final "copy patch pixels down and right" operation was meant to achieve, but I didn't understand exactly why it worked the way it did, especially since it didn't work very well in certain cases, in particular it left really noticable pink pixels around the edges of some of the player weapon sprites, which we'd get bug reports about occasionally. Also joe-ilya posted a screenshot where he'd deliberately filled INTERPIC with 0xff pink and drawn something on it, and the patch compositor predictably made a complete mess of it.

 

So a couple of years ago I changed two things: firstly instead of copying pixels infinitely down and right until you meet the edge of the graphic I copied them outwards into transparent regions in all four directions. This nicely fixed the bugs with rendered weapon sprites. (Sadly for me, when 2.5.1.4 released, I think everybody was too busy praising wigglefix to notice. But, I digress.)

 

Anyway, the other thing: instead of always using 0xff, you search for a palette index which is duplicated, and call one of those transparent. You can then rewrite source pixels that use the transparent index to use the duplicate, and avoid confusing the patch compositor by using a palette entry that it thinks is a "hole". I believe ZDoom does the same, even insisting that a PLAYPAL has a duplicate of entry zero, and I also noted even highly-deduplicated PLAYPALs such as BTSX's preserve having a single duplicate entry, so I figured this could be relied upon.

In all palettes I tried this with, you always get 0 as the first duplicate, so that ends up being defined as transparent, and the patch initialised to it, so you get black in the holes.

My current palette for the thing I'm working on doesn't have any duplicates. Should I insert one? I'd rather not if I could avoid it.