garrysmod-issues
garrysmod-issues copied to clipboard
Facepunch
RGB Corruption
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:
I see it too. Also happens with surface.drawRect in 3D contexts such as ENT:Draw().
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.
Also I have all post processing off, so something to do with the unlitgeneric shader or surface.drawrect.
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.
I remember this as well, but I think the post was in the old Next Update section.
This is a bug I ran across recently where the values I was putting in from photoshop were significantly off by a few RGB values.
Pixel color values aren't linear and don't blend linearly so they need gamma correction.
after some testing, the values:
15
22
30
38
48
58
72
88
110
112
114
159
167
170
172
174
176
179
238
cannot be represented in a standard rendertarget
edit: $linearwrite 1 fixes the problem. The surface lib may need to be updated to use this material flag
