[Lykurgos88]

Hi,

I finally decided to take some time to organize this post. Yes, there is a graphical bug in my new Blue Planet installation and it only concerns the Narayana frigate. It seems that there is something wrong with its shader. As a default in the tech room, it shows up as "blue" and in-game is shows as completely "green" (probably combination of yellow from the sun and blue). So far, Narayana is the only ship with this shader bug, and there are no errors when running the debug build.

This is how it looks in the tech room:



In the previous Blue Planet installation it looked "normal".

This is how it looks in-game (screenshot taken from massive battle, but it still looks green in every other mission too):



Attention! It still looks green even if there are no beams around. Every other GTVA and UEF ship looks normal when there is no action.

I'm using the latest Blue planet files, latest drivers for Geforce Gtx 780 and the latest nightly build for FSO. Log file where I look around in tech room is attached in the post.

[attachment DELETED!! by Strong Bad]

[MatthTheGeek]

This sounds like an issue with team colors. Do other UEF capships have this issue?

[DahBlount]

I get this as well and yes, the Karuna and Solaris also have this issue. It's specifically an issue with team color glows. For some reason FSO thinks there is an alpha channel even though there isn't. I'm currently looking into it.

Edit: It appears to only be an issue with DXT1. Taking a further look into the code to see how it treats that compression format.

[Maverick_BB110CB]

I have the same issue. But mine never turns green, it's always blue. And it only affects the Narayana, not the Karuna and Solaris for me.

I first noticed this on the Masyaf - it looked OK in the ending scene of Act 2 and tan it became blue in the Dreamscape. Well, since it's dreamscape I thought that it's supposed to look that way 

Now I realized that I switched the build between acts 2 and 3. So I tested it and the thing happened somewhere between builds e36e9ff and 7badc4d.

[niffiwan]

One of these probably.

...For some reason FSO thinks there is an alpha channel even though there isn't. I'm currently looking into it.

This little sucker thinks that anything with 32 bits-per-pixel has an alpha channel (except PCX files, but not relevant here). If team colour glows are now using (& saving?) the alpha channel of the -misc texture could that be tripping FSO up (although I must admit that I can't see how changing the shader would affect whatever might be calling that function?)

[DahBlount]

Hmm, so bm_has_alpha_channel() only assumes PCX files don't have alpha channels? That's a little odd considering DXT1 has no explicit or interpolated alpha unless you export it with 1 bit alpha (where 0 is black, 1 is white, it can only be one or the other, no value in between). In fact, it's not always 24(25)-bits in depth, since it can be either 4 bpp or 8 bpp depending on the export options. With this, only DXT3 and DXT5 will allow us to make the alpha channel 0 so as to avoid this issue. If you need a fix for right now, just put these into your bpcomplete/data folder.

[niffiwan]

After I slept on it I think that bm_has_alpha_channel() is probably irrelevant.  However, if a DXT1 map (without alpha) is "passed" to the team colours shader, what is the shader going to treat the alpha value as being? i.e. what's the default?  Prior to the changes that didn't matter since only the red/green channels were used.  Maybe the fix is as simple as changing the shaders (or the shaders input) default to be fully opaque (or whatever the map needs to be in order for there to be no team colour displaying)

[niffiwan]

FYI, Swifty has fixed this issue, and the fix should be in the next nightly.

[Lykurgos88]

I tested the new nightly and can confirm, it's fixed. Thank you very much =)