CoronaTotalTime

The bare minima on OpenGLES2 are quite easy to overflow, cf. the "Qualifiers" section in the cheat sheet. For instance, even before floating-point numbers become integer-only or start incrementing by 2, 4, etc. we would get very crude interpolation, with the results relying upon such values becoming quite choppy. With mediump and 2¹⁰ = 1024 full integers, we can only interpolate by steps of .25 from 128 to 256, so roughly the time from 2-4 minutes! Followed by increments of 1/2 between 256 and 512, then down to 1 next, and so on.

This gloomy scenario only captures part of what's going on, of course. The time is actually maintained in Lua as a single-precision float, with a rather more generous 23-bit mantissa. Furthermore, a huge number of shaders could use a MUCH smaller value derived from the time, e.g. those built on simple patterns or trigonometric functions that have narrow periods such as some low multiple of π. In these cases the shader could receive, say, the transformed result or TrueTotalTime % X or sin(N * TrueTotalTime).

In practice, I don't know if a wide selection of functions is necessary; those listed above are probably the most seen in the wild, maybe with some utilities for a gcd or lcm of several periods. In theory a Lua function could be pcall()'d as well, but rendering might be where that happens and that seems to occur amid a lockdown, of sorts. In any event, it seems appropriate alongside isTimeDependent as a parameter to graphics.defineEffect, perhaps along with a couple arguments.

---

I guess the flags, function, etc. would go in the Program. By the looks of it (for the current "GL" implementation), we can put this before the loop in ApplyUniforms and transform the time if the timestamp is behind.

EDIT: This is in now in probation—and submitted—with three choices: modulo, pingpong, and sine. (I'm also deliberating some sort of 1D noise.)

---

I consider this low- to medium-priority, especially since workarounds exist.