Tweet
The plasticity of Doom 3 was caused by not doing sRGB<->linear conversions where it was required, which is very important for realistic rendering. The lack of hardware support and also OpenGL API support (no sRGB extensions at the time) was to blame. There was no abuse, just limitations of what was available. PS2.0 shaders couldn't fix it due to the instruction count limit. Most later games, such as Half-Life 2, did it correctly. (also thanks to DX9, which had good sRGB support)
-
-
I've found out that the glitches in Talos Principle are caused by the application, not the driver. The application behaves in a way that is undefined according to the GLSL specification (e.g. version 4.50). The precise explanation is:
Talos Principle calls "discard" in the fragment shader, which causes non-uniform control flow, followed by a function (fwidth) computing partial derivatives, which requires uniform control flow to work properly. Since the shader compiler (correctly) disables fragment shader invocations for "discard", the following partial derivative computations are undefined (meaning the results can be random, causing random effects on the screen).
I would like to see articles about broken games and engines to keep it fair.Comment
Comment