Is it really necessary to distinguish between foreground and background colors in the translucency table?

[Mistake]

Quake 2 has only one translucency table, yet it uses it in place of two, specifically 33% and 66% translucency, since two colors can blend into two new ones depending on the translucency of the foreground color, and you can see that SRB2 uses duplicates of the same tables, like 10% and 90% translucency.
Would it be possible to use the Quake 2 method instead?

 

[Nev3r]

If I understand correctly, what you suggest is to reuse remap table lumps which have a mirrored counterpart - it could probably be possible to do for the translucency and additive blending, but it most likely no longer applies for other blend modes. I overall don't think it's an optimization worth dealing with for these 2 blend cases since the memory footprint from the additional remap table lumps is very tiny.

 

[Mistake]

If I understand correctly, what you suggest is to reuse remap table lumps which have a mirrored counterpart - it could probably be possible to do for the translucency and additive blending, but it most likely no longer applies for other blend modes. I overall don't think it's an optimization worth dealing with for these 2 blend cases since the memory footprint from the additional remap table lumps is very tiny.

It's not about the memory, it's about taking place of the more valuable translucency tables of 5%, 15%, 25%, 35% and 45% translucency, totalling to only one more than how many tables the game currently has, if you replaced all*
the duplicates with the ones I mentioned.

*you said "for these 2 blend cases" but the two tables I mentioned were only one example, the game has a duplicate for everything below 50% translucency.

Post automatically merged: Feb 28, 2022

Also, I should have clarified that when I wrote "two colors can blend into 2 new ones" I meant the combination of the same two colors.
For example, 10% translucent white on top of black gives a slightly darker shade of white, and 10% translucent black on top of white gives a slightly lighter shade of black, and you can use both resulting colors (darker white and lighter black) on either white on top of black or the other way around, this way you get the effect of two translucency tables using only one.

 

[Nev3r]

It's not about the memory, it's about taking place of the more valuable translucency tables of 5%, 15%, 25%, 35% and 45% translucency, totalling to only one more than how many tables the game currently has, if you replaced all*
the duplicates with the ones I mentioned.

*you said "for these 2 blend cases" but the two tables I mentioned were only one example, the game has a duplicate for everything below 50% translucency.

By 2 blend cases, I meant the translucency and additive blend tables, sorry I wasn't very clear - SRB2 currently supports several blend modes, in addition to the regular translucency blending which used to have; I believe they are internally generated on game launch, but they're there, each with their own set of tables like the translucency has.

I am aware that, as far as regular translucency blending goes, due to the way the intervals are set up, the 10% and 90% tables are transposed counterparts, and the same goes for 20-80, 30-70, 40-60, even 50 with itself. And I believe this also happens with the additive blending mode. So what I understand you're suggesting is to recycle the tables with redundant transposed equivalents.

What I meant earlier is, that I believe the rest of blend modes don't meet this transposition rule due to the nature of their operations, and thus you could no longer apply this transposition trick on them.

 

[Mistake]

By 2 blend cases, I meant the translucency and additive blend tables, sorry I wasn't very clear - SRB2 currently supports several blend modes, in addition to the regular translucency blending which used to have; I believe they are internally generated on game launch, but they're there, each with their own set of tables like the translucency has.

I am aware that, as far as regular translucency blending goes, due to the way the intervals are set up, the 10% and 90% tables are transposed counterparts, and the same goes for 20-80, 30-70, 40-60, even 50 with itself. And I believe this also happens with the additive blending mode. So what I understand you're suggesting is to recycle the tables with redundant transposed equivalents.

What I meant earlier is, that I believe the rest of blend modes don't meet this transposition rule due to the nature of their operations, and thus you could no longer apply this transposition trick on them.

I see now, thanks for making it clearer.
From what I understand, the game has a lookup table only for translucency, but other modes like additive don't since they are automatically generated, right?

By the way, sorry for not researching things further, I didn't know blend modes existed and I focused on only what I was familiar with, which is lookup tables used for translucency, that's why I was only aiming for feature requests that extended its capability to be smoother.

Post automatically merged: Feb 28, 2022

What I meant earlier is, that I believe the rest of blend modes don't meet this transposition rule due to the nature of their operations, and thus you could no longer apply this transposition trick on them.

I understand, but is it possible to exclude them? I only need smoother translucency without the extra blends.