# Hard Steps on Water Shader

When using one of the exercises we saw that the water simulation was for some reason degrading over time t0 t1 t2

To animate the wave, a floating point number “t” was given and increased by 0.001 in 30 Hz. The “shader” calculates the sine wave by using the sin-operation, based on the “x”, “y” and “t” value of the current pixel. To not let the calculation of “t” overflow a MathUtils.equals (t, 2.51f) was used to check, whether we need to reset “t” to “tO”.

Using a value range from (0.0–1.0] was used for t. Instead of MathUtils.equals(..), t %= 1.0f was used.

Never compare floats for equality! Use GreateOrEqual compares, or even better, setup a periodic function for assigning values to “t”. As soon as you calculate floats, the assumption of equality does not hold. For instance adding a value to another increases the space of the ULP (Unit in the last place), comparable to the precision of the value, needs, so the values get less reliable. Since this was done, equals, was checking if the two values were inside their ULP, but it was always outside.

This sample snipped is an extraction of the problem. It result in follwing output:

1.9899986 == 2.0f? false .. LibGdx.isEqual()? false
1.9999986 == 2.0f? false .. LibGdx.isEqual()? false
2.0099986 == 2.0f? false .. LibGdx.isEqual()? false
2.0199986 == 2.0f? false .. LibGdx.isEqual()? false
2.0299985 == 2.0f? false .. LibGdx.isEqual()? false

This means, that close to the expected value of 2.0f, a comparisson always fails.

We are always looking for talented developers, UI/UX designers and product managers, check out the latest openings here

We have recently spent 4 days developing 4 apps to help refugees during project #refugeeswelcome #hackweek15. More on the story here

Mario Bodemann