Invalid SRB2 2.2.10 pre2; Major regression in translucent FoF rendering.

[Mr Beagle]

First off, the file.

MAP01

MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.

www.mediafire.com

The bug, a commit between the first and second prerelease broke the rendering of alpha textures when using the intangible, translucent FOF type. The parts of the texture that are supposed to be completely opaque are partially transparent instead (in OpenGL, software rendering is even worse with transparency not working at all on the planes).

 

[sphere]

Actually, this is not a regression. 2.2.10 pre2 happened to fix a "bug" with setting a translucent FOF's alpha value, which is affecting this case.

If you look at the wiki page for any translucent FOF type, like https://wiki.srb2.org/wiki/Linedef_type_221, the opacity of the FOF is supposed to be set by a value between #000 and #255 in the upper texture field. Since 2.2.10 pre2, it also accepts an additional number to set a blending mode, which changed how the upper texture field was processed internally.

Looking at the provided map, the upper texture field doesn't contain a #-prefixed numerical value, but instead seems to have a texture name. This is not supposed to do anything and should leave the FOF half-transparent (as it is in pre2), but it seems like texture names used to get interpreted as #255, which is definitely unintended behavior. As such, correcting the FOF's upper texture field to #255 in the provided map makes it display the way you want.

Also, the white areas of the texture in Software can be cut, by setting the "[13] Cut cyan pixels" flag on the control linedef.

 

[Mr Beagle]

Thanks, I did not know I was actually abusing a bug that was creating unintended behavior. I guess it makes more sense the way it works now.