re shader: I passed 1.0 from the vertex shader to the fragment shader. It didn't always occur, but occurred frequently on enough geometry to make a considerable

re shader: I passed 1.0 from the vertex shader to the fragment shader. It didn't always occur, but occurred frequently on enough geometry to make a considerable flicker when shifting the geometries position. When I checked the values when outputting them as color, there was no difference from one pixel to the next (suggesting a minor variation). When I floored/truncated the value in the fragment shader, and outputted the result as either red or green (0.0 is red, and 1.0 is green). The result was blocked stripes of red surrounded by green. Prior to doing this, I had changed the precession of float to highp and made sure the vertex shader was passing in 1.0. re desktop processor: I can't remember the generation of processor, but it was likely designed in 2008-2009. For some background, we used to generate a large set of tests and results that we could test against our framework. Some of those tests required results computed using trig functions. The results of those trig functions would be slightly (but very noticeably) off the results we were expecting (ie, run on any other machine we had). I'd love to think floating point is always reliable, and in most cases, it's accurate enough. But sometimes, it becomes a problem and the hardware isn't as reliable as we'd like. FiftyThree had a very similar issue when they were implementing their smug tool: http://making.fiftythree.com/the-precision-behind-blend/ http://making.fiftythree.com/the-precision-behind-blend/