RGB Corruption - Githubissues

10853 commented 8 years ago

Details

On-screen RGB values do not correspond to the values specified in the Lua source files.

Failed attempts to figure this our by myself

Asked other people on my Steam contact list. All of them were experiencing the same problem. No joy.
Uninstalled GMod. Deleted all leftover files. Unsubscribed from all addons. Verified file cache. No joy.
Did a web search to determine if it might be an issue with nVidia GPUs specifically. No joy.
Took a very close look at GMod's Lua codebase to see if I can find anything. No joy.
Tried to disable postprocessing via Lua. No joy.
Tried to run GMod after disabling nearly all of the Lua files it's shipped with. No joy.
Reinstalled the game. Twice. No joy.
Using dynamically generated albedo-less vmt files featuring the $color shader parameter. No joy.
Tried using DX8 instead of a newer version. It works, but it's DX8 mode, so it gets a no joy as well.
Tried drawing panels via Awesomium. Joy is an illusion. Happiness does not exist. Only pain is real.
Tried posting on the Facepunch forums a month ago. Hearing circadas beatboxing in the distance now.

The only way I managed to coerce the game into drawing the correct colors in DX9+ mode was by using png files containing a single pixel in the color I want to display. This kinda works, but only while drawing elements that are fully opaque. The moment I try cranking down an element's alpha value is the moment I start getting weird bugs again.

Things I didn't try

I don't have Steam installed on any of the Linux systems I have at my disposal and I doubt that trying to recreate this bug on any of them would be a particularly helpful affair, so I spared myself the time investment. I've just about zero interest in touching anything Apple-related with a six-foot pole, so I didn't look into that, either.

Steps to reproduce

Take this snippet of code:

Frame = vgui.Create( "DFrame" ) Frame:SetPos( 10, 10 ) Frame:SetSize( 400, 200 )

ColorButton = vgui.Create( "DColorButton", Frame ) ColorButton:SetPos( 50, 50 ) ColorButton:SetSize( 100, 30 ) ColorButton:SetColor( Color( 000, 110, 160 ) )

Take a screenshot, then sample the button's blue color (any other element would've done as well). Instead of 0, 110, 160 I'm getting a read-out of 0, 111, 162. Not too bad, you say? Well, yeah, in this particular instance it's merely annoying, but it gets very notable once you start mucking about with alpha values in order to draw something a little more advanced than a flat, opaque color. Low-alpha white on a dark background tends to be particularly horrifying to behold.

For what it's worth, offsets appear to be consistent from player to player.

Anything else?

Yeah. Please fix this. Frontend work is painful enough as-is - I'd really prefer not to suffer flashbacks to my HTML/CSS days every time I run out of excuses to do backend work instead. Pretty please? :camel:

thegrb93 commented 8 years ago

I see it too. Also happens with surface.drawRect in 3D contexts such as ENT:Draw().

robotboy655 commented 8 years ago

It probably happens with the entire rendering pipeline and is probably fault of Source's Rendering, which would take ages to pin point if that is even physically possible.

thegrb93 commented 8 years ago

Also I have all post processing off, so something to do with the unlitgeneric shader or surface.drawrect.

willox commented 8 years ago

If memory serves correct, this was a purposeful change from TF2 during the Garry's Mod 13 beta. Maybe somebody else remembers or can find the FP post I'm thinking of.