The page for Precision Issues claims that:
lowp is at least an 9 bit valuemediump is at least a 16 bit valuehighp is at least a 32 bit value
This is true for some implementations, but according to the GLSL ES 1.0 spec, section 4.5, the actual guarantees are:
lowp : Can represent integers from -256 to 256mediump: Can represent integers from -1024 to 1024highp: Can represent integers from -65536 to 65536
These are not off by one errors, those are the ranges listed in the spec. Integers in GLSL ES 1.0 are NOT guaranteed to be two's complement either.
I understand how this error occoured, because the ranges listed ARE the correct ranges for GLSL ES 3.0, used for WebGL 2 (see the GLSL ES 3.0 spec, section 4.5).
Bit counts are in general unreliable in GLSL ES 1.0, as it isn't explicitly stated anywhere in the specs how wide any given type is. This also applies to floats, but I feel it is less of an issue there.
The page for Precision Issues claims that:
lowpis at least an 9 bit valuemediumpis at least a 16 bit valuehighpis at least a 32 bit valueThis is true for some implementations, but according to the GLSL ES 1.0 spec, section 4.5, the actual guarantees are:
lowp: Can represent integers from -256 to 256mediump: Can represent integers from -1024 to 1024highp: Can represent integers from -65536 to 65536These are not off by one errors, those are the ranges listed in the spec. Integers in GLSL ES 1.0 are NOT guaranteed to be two's complement either.
I understand how this error occoured, because the ranges listed ARE the correct ranges for GLSL ES 3.0, used for WebGL 2 (see the GLSL ES 3.0 spec, section 4.5).
Bit counts are in general unreliable in GLSL ES 1.0, as it isn't explicitly stated anywhere in the specs how wide any given type is. This also applies to floats, but I feel it is less of an issue there.