PrBoom-Plus, ver. 2.5.1.4

[RjY]

35 minutes ago, Da Werecat said:

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.

If it doesn't find any duplicates, it will revert to previous behaviour, that is, assuming index 255 represents a hole, so if you use index 255 in any patch it will get overwritten.

 

Sadly you need one transparent index because there's only 256 values a byte can take and 256 colours in a palette. So you either consider one index as a representation of a transparent pixel, or you store a mask separately. But if you're going to faff about with separate masks, you might as well spend the time instead converting your internal texture storage to 4 bytes per pixel so there's room for an alpha channel, and it's not such a big leap to true colour textures in software mode but -- I'm getting ahead of myself and not volunteering to write this!

[Gez]

I'd advise having black as both index 0 and index 255 if you're going to make a custom palette.

 

As RjY explains, having a duplicate allows the engine to internally remap pixels around, deciding that one of the duplicates is now the fabled "transparent color" long thought to be index 247. (Because index 247 is a duplicate of index 0, and old tools used it as a transparent color for convenience, even when it was not desired.)

 

If you don't have a duplicate, what happens (at least in ZDoom; RjY can cover for what happens in PrBoom+) is that a "close enough" duplicate will be found. So you will lose a color, except the color you'll lose will be chosen algorithmically by the engine (IIRC, taking the color the closest to the color that is the closest to black: so if index X is the darkest color in the palette, and Y is the second darkest, all Y pixels will be remapped to X, and all transparent pixels will be remapped to Y) instead of choosing which one you lose by making a palette with only 255 unique colors.

[Da Werecat]

I'll stick something into 255 then, I guess. Luckily, there are still parts of the palette that can lose one color without me having to redo much of anything else.

 

Thanks.

[kb1]

On 3/16/2017 at 6:56 PM, RjY said:

(description of texture compositor process)

Thanks for noticing Wiggle Fix! Sorry it detracted from your texture compositor fixes!

Honestly, I got lost on your description of the algorithm, at the "weird 'copy patch pixels down and right'" part. I assume that this is ZDoom's Medusa Effect fix for using transparently patched textures on 2S walls, right? If I try to understand, ZDoom takes the patches, renders all of them into a texture buffer, and then it has either a solid texture, or a texture with some holes in it. If the texture has holes, ZDoom goes to the first hole, and copies the solid pixel from either above or to the left, filling in the hole. It then repeats this process until the texture is solid? Is that what's happening?

 

But you're claiming that this process could miss some holes, so you added the ability to scavenge pixels from below and to the right, as well as above and to the left, thereby ensuring that all holes are filled? Is this what you are describing?

 

Yes, I think GL textures need to be solid, even if one of the colors is designated as transparent. More accurately, I think the fourth byte - the alpha byte is used as an alpha channel. I need to check out the source, I guess, cause, from this description, it seems like it's doing more work than necessary. It seems like it could simply start with a cleared buffer (0x00), render all the patches, then generate an in-memory patch representing a solid texture with the holes filled in with black. Maybe it is doing exactly that, and I just can't tell. But the down/right stuff feels like an "over-engineered" solution, with all due respect. But, that's hard to believe. I think it's more likely that I'm simply missing part of the picture. And, if it works, it works, right? :)

 

So, one question: When will you get a black texture, and when will you get a checkerboard pattern in ZDoom?

[Gez]

26 minutes ago, kb1 said:

When will you get a black texture, and when will you get a checkerboard pattern in ZDoom?

 

You get black background for transparent textures (regardless of patch or no patch) on a non-transparent wall (upper or lower texture, or 1-sided middle texture).

You get HOM on "-" texture on a non-transparent wall.

You get checkerboard for missing textures and flats.

[RjY]

23 hours ago, kb1 said:

Thanks for noticing Wiggle Fix! Sorry it detracted from your texture compositor fixes!

Haha :)

 

23 hours ago, kb1 said:

Honestly, I got lost on your description of the algorithm, at the "weird 'copy patch pixels down and right'" part.

The comment was:

// copy the patch image down and to the right where there are
// holes to eliminate the black halo from bilinear filtering

which explains one reason why you have to do something with holes in patches.

 

23 hours ago, kb1 said:

If I try to understand, ZDoom takes the patches, renders all of them into a texture buffer, and then it has either a solid texture, or a texture with some holes in it. If the texture has holes, ZDoom goes to the first hole, and copies the solid pixel from either above or to the left, filling in the hole. It then repeats this process until the texture is solid? Is that what's happening?

This sounds similar to what PrBoom is doing, yes.

 

23 hours ago, kb1 said:

But you're claiming that this process could miss some holes, so you added the ability to scavenge pixels from below and to the right, as well as above and to the left, thereby ensuring that all holes are filled? Is this what you are describing?

I'm not claiming anything about ZDoom's process. I'm claiming PrBoom's old process, which I replaced, had bugs that could for example leave stray pixels on the edges of the player weapon sprites. I believe this was a bug peculiar to PrBoom/PrBoom+, I don't think other engines had it. There are some pictures on the /vr/ archive: 2334392 2337426 2337558

 

On 17/03/2017 at 11:59 PM, kb1 said:

I need to check out the source, I guess, cause, from this description, it seems like it's doing more work than necessary. It seems like it could simply start with a cleared buffer (0x00), render all the patches, then generate an in-memory patch representing a solid texture with the holes filled in with black.

Indeed, you could just memset to zero and leave the holes untouched, but then you'd get black dots on the edges of transparent patches via rounding error and/or black halos if using one of the software mode filters. An alternative is to detect and ignore the transparent index in the column drawer itself, but I never felt like messing with them.

 

[kb1]

On 3/17/2017 at 8:25 PM, Gez said:

 

You get black background for transparent textures (regardless of patch or no patch) on a non-transparent wall (upper or lower texture, or 1-sided middle texture).

You get HOM on "-" texture on a non-transparent wall.

You get checkerboard for missing textures and flats.

Not sure about the HOM, but the rest of it sounds like a reasonable result. It can be thought of as a convenient way to handle mistakes without simply failing to render, so any approach lets the game continue is better than nothing.

 

 

On 3/18/2017 at 8:30 PM, RjY said:

Haha :)

 

The comment was:

// copy the patch image down and to the right where there are
// holes to eliminate the black halo from bilinear filtering

which explains one reason why you have to do something with holes in patches.

 

This sounds similar to what PrBoom is doing, yes.

 

I'm not claiming anything about ZDoom's process. I'm claiming PrBoom's old process, which I replaced, had bugs that could for example leave stray pixels on the edges of the player weapon sprites. I believe this was a bug peculiar to PrBoom/PrBoom+, I don't think other engines had it. There are some pictures on the /vr/ archive: 2334392 2337426 2337558

 

Indeed, you could just memset to zero and leave the holes untouched, but then you'd get black dots on the edges of transparent patches via rounding error and/or black halos if using one of the software mode filters. An alternative is to detect and ignore the transparent index in the column drawer itself, but I never felt like messing with them.

 

Oh, you replaced PrBoom's process, not ZDoom's. Got ya.

Also, now I understand what you meant about the visual glitches: They occur when using the software filters. Thanks for clearing that up (figuratively and literally :)

 

I must say: The forum software is pretty darn powerful. The Multi-Quote function is awesome! It surprises me how easy it is to do. This could have been a very tricky thing to try to get a web page to do, but the forum software handles the tagging of multiple posts very gracefully.

[kb1]

On 3/18/2017 at 8:30 PM, RjY said:

Haha :)

 

The comment was:

// copy the patch image down and to the right where there are
// holes to eliminate the black halo from bilinear filtering

which explains one reason why you have to do something with holes in patches.

 

This sounds similar to what PrBoom is doing, yes.

 

I'm not claiming anything about ZDoom's process. I'm claiming PrBoom's old process, which I replaced, had bugs that could for example leave stray pixels on the edges of the player weapon sprites. I believe this was a bug peculiar to PrBoom/PrBoom+, I don't think other engines had it. There are some pictures on the /vr/ archive: 2334392 2337426 2337558

 

Indeed, you could just memset to zero and leave the holes untouched, but then you'd get black dots on the edges of transparent patches via rounding error and/or black halos if using one of the software mode filters. An alternative is to detect and ignore the transparent index in the column drawer itself, but I never felt like messing with them.

 

Oh, you replaced PrBoom's process, not ZDoom's. Got ya.

Also, now I understand what you meant about the visual glitches: They occur when using the software filters. Thanks for clearing that up (figuratively and literally :)

[everennui]

Something weird has happened with my version of prBoom 2.5.1.4.

It's almost like I need a turbo button to slow down my computer because it's running really fast. The character movement is very fast and jerky. The monsters move twice as fast and shoot fireballs faster. I didn't adjust any settings in it. Also for some reason there's a secrets bar that all of a sudden turned on and I'm sure I didn't mess with any settings except vertical mouse movement.

What gives?

Edit: I noticed something in the options for game speed and it was set to 150. I really don't remember touching this at all. It didn't change until after I restarted Boom. Was this the problem or did I change something I want to keep at 150? 100 sounds more logical.

Edited March 23, 2017 by everennui

[RjY]

2 hours ago, everennui said:

Edit: I noticed something in the options for game speed and it was set to 150. I really don't remember touching this at all. It didn't change until after I restarted Boom. Was this the problem or did I change something I want to keep at 150? 100 sounds more logical.

The game speed can be changed on the fly by pressing + and - on the numeric keypad. This is useful e.g. when watching long demos but as you have found can be triggered accidentally with confusing results. If it happens again you can press numeric keypad * to reset it to default 100%.

 

As for the secret bar, there is a key F5 which cycles through various styles of HUD, perhaps you pressed it unknowingly. There are a lot of HUD styles, you need to press F5 again 12 or 13 times before it gets back to where it was.

[everennui]

cool. good to know. probably happened when I pressed Alt+F4 to exit (unsuccessfully). I always do that in ZDoom.

[rehelekretep]

what's the difference between the various software modes on glboom+ ?

8 bit

15bit

16 bit

32 bit

 

i couldnt see any visual difference...

[RjY]

1 hour ago, rehelekretep said:

what's the difference between the various software modes on glboom+ ? [...] i couldnt see any visual difference...

• 8bpp: Traditional vanilla-like renderer where pixels are indexes into a 256 entry palette, with Boom extension for translucency. You know what this is already.
• 32bpp: Emulation of above in truecolor (4 bytes per pixel, 8 bits per RGB channel with 8 unused). Still works with colormaps via precalculated lookup tables.
• 15bpp: So-called hicolor -- uses only 2 bytes per pixel, 5 bits per RGB channel with 1 unused. Actually slower than 32bpp last time I checked but maybe useful if you have next to no memory. I believe hicolor must have been a late nineties standard between 256 colour palettes and full truecolor. These days largely pointless AFAICT, maybe nice on ports to unusual hardware?
• 16bpp: older variant of 15bpp with one extra bit for green. Has a slight green tint, looks like you have 1/32 of a radsuit on all the time. If 15bpp is pointless, 16bpp is more so. :)

Other than improved translucency (e.g. the secret soulsphere on cchest2 map29 retains its blue colour instead of turning grey) differences in the higher bit depths from traditional 8bpp paletted renderer are minimal, which is likely intentional (although there are some limitations, e.g. translucency is fixed at 50% "for speed" and spectres always fade to black regardless of palette flashes). However there are a bunch of "filters" that implement in software mode some of the things GL mode can do -- bilinear filtering, sprite edge rounding etc -- and these all look at a lot better with arbitrary colours not restricted to PLAYPAL. But also it's all very old code, was probably more impressive in 2003 when first released in the "technology preview" PrBoom 2.3.0. Not sure what today's users make of it all...

[rehelekretep]

@RjY thanks! i must admit i didnt understand much of that :D

is the take-away that in most cases, the user should use 8 or 32 bit? :p

[RjY]

21 minutes ago, rehelekretep said:

@RjY thanks! i must admit i didnt understand much of that :D

is the take-away that in most cases, the user should use 8 or 32 bit? :p

Heh sorry I like technical detail and it gives other sourceport devs, engine tinkerers, and other belligerents the opportunity to come in and say "that's all wrong, you are stupid" and I end up learning something :)

 

But yeah, pretty much. I'd even go further and say, for software rendering, stick to 8bpp. Unless you're the type of user who likes playing with dozens of settings. Not that there's anything wrong with that of course. But in, as you say, most cases, for software mode I think 8bpp is "good enough".

[kb1]

On 3/25/2017 at 0:46 PM, rehelekretep said:

@RjY thanks! i must admit i didnt understand much of that :D

is the take-away that in most cases, the user should use 8 or 32 bit? :p

8-bit is the original vanilla color depth. On older processors, this mode will almost always be faster than 32-bit rendering. In 8-bit mode, you will have a maximum of 256 colors on the screen at once, so you'll see bands of color transition, especially on floors and ceilings. Also, translucency greatly suffers from a lack of available colors, which becomes obvious when looking through a translucent wall or object.

 

32-bit mode gives you a max of 16-million colors on the screen at once (though, typically you'll see a lot less, but way more than 256). The color bands are replaced with smoothly-transitioning colors, and translucency looks much better. However, the renderer must write 4x the data per frame, and, instead of being able to use a lookup table, each of the red, green, and blue components of a pixel must be calculated "on-the-fly", to handle light shading and translucency. Depending on implementation and processor capability, 32-bit rendering may or may not be A LOT slower. Try both on complex scenes with lots of things, especially translucent things, and compare. Metrics to compare are typically Frame Rate, and Image Quality. Also note that frame rate is also a function of output resolution. Depending on your preferences, a lower resolution output using 32-bit color might look better to you, than a higher-res 8-bit output (if your monitor is good at scaling output, that is).

 

[rehelekretep]

thanks @kb1 thats very helpful

[Da Werecat]

3 hours ago, kb1 said:

smoothly-transitioning colors

PrBoom+ still uses the colormap for lighting, so not much difference in this regard. There's an option to interpolate light diminishing, but it only works on floors and ceilings.

Edited March 28, 2017 by Da Werecat

[everennui]

If I'm understanding this correctly... I can use a combination of actions on a switch if I use what I can only think of as DM Flags. What are these actually called and where can I find them?

Edit: So... Blue key would be (arbitrarily) 10000, Floor lower would be 2000 so I'd put 12000 to combine them. I just don't know what these numbers are called.

Edited March 28, 2017 by everennui

[RjY]

@everennui Boom generalized linedef types. Your editor may have a function to compute them, or if not @fraggle made a web-based calculator.

[everennui]

I guess I understood that part about it. Thank you for the link.

[DOOMGABR[RU]]

I need help with this error

[Ribbiks]

probably not the right thread for this, and you'll definitely need to provide more information.

 

If this was with a wad you downloaded, then odds are it requires zdoom (or related port) to run, as those ports handle textures differently (e.g. allowing wall textures on floors, and vice versa).

 

If it's for a prb+-compatible project you are working on or are involved with, it's possible you have some malformed patches/textures lumps, and should probably post the problematic wad for further examination.

[kb1]

On 3/27/2017 at 7:49 PM, Da Werecat said:

PrBoom+ still uses the colormap for lighting, so not much difference in this regard. There's an option to interpolate light diminishing, but it only works on floors and ceilings.

PrBoom+ does not have a 32-bit software renderer. It may push an 8-bit buffer into a 32-bit buffer for screen blit, but calculations are in 8-bit, if I'm not mistaken.

[Da Werecat]

Translucency doesn't use the palette in this mode.

[DOOMGABR[RU]]

18 hours ago, Ribbiks said:

If it's for a prb+-compatible project you are working on or are involved with, it's possible you have some malformed patches/textures lumps, and should probably post the problematic wad for further examination.

Here you go http://www.mediafire.com/file/i8pzbfz7itolfz8/egregor_build29032017.wad

[VGA]

If you load it in ZDoom or Eternity you can see some errors in the console. Unknown patches in 6 of the textures.

 

 

[damerell]

I just spotted something odd. prboom-plus 2.5.1.4, OpenGL mode, Shader sector lighting model. If I change the gamma correction with F11, the fading to black of distant sectors appears to be removed:

http://www.chiark.greenend.org.uk/~damerell/games/prboomgamma/1-beforegamma.png is the situation before gamma correction. Things looks normal.

http://www.chiark.greenend.org.uk/~damerell/games/prboomgamma/2-aftergamma.png is after gamma correction. The ceiling tiles show the effect very clearly.

If you switch renderer away from and back to OpenGL, things go back to normal. http://www.chiark.greenend.org.uk/~damerell/games/prboomgamma/3-aftergammaandswitch.png shows this - it's still brighter than picture #1 (as one would expect) but it's nothing like picture #2.

[entryway]

I have similar issue with 2514 on Intel HD Graphics. Something is not initialized correctly. Instead of switching to software and back to OpenGL you can try to press <Enter> twice on "sector lighting mode: shaders" for reinit. Magically fixed in 2.5.1.5.test.

Edited April 3, 2017 by entryway

[VGA]

1 hour ago, entryway said:

I have similar issue with 2514 on Intel HD Graphics. Something is not initialized correctly. Instead of switching to software and back to OpenGL you can try to press <Enter> twice on "sector lighting mode: shaders" for reinit. Magically fixed in 2.5.1.5.test.

Spamming Enter is awesome, can you make the menu open with Enter, too, instead of just ESC?