PrBoom-Plus, ver. 2.5.1.4

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!

1 person likes this

Share this post


Link to post

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.

2 people like this

Share this post


Link to post

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.

Share this post


Link to post
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?

Edited by kb1
Edited to reduce forum space

Posted (edited)

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
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.

Share this post


Link to post
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 :)

Share this post


Link to post

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 by everennui
1 person likes this

Share this post


Link to post
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.

1 person likes this

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now