Hacker News Reader

Comment by Scene_Cast2 | Hacker News Reader

Could you use a non-float integer instead? Do GPUs have cheap int % float -> float operations?

1. Integers would make the situation easier, but still overflow after ~50 days. You can't just increment delta every frame; frame times vary significantly and and if you aren't precise to the millisecond things will jump around.

2. It's not exactly cheap, and I don't think compilers put much effort into making sure you actually retain that precision. I have only really used floats in shaders though, and don't know what would happen.

3. I'm pretty sure that in practice you'd lose out on a lot of hardware-accelerated functions, doing trig and interpolations with multiple messy conversions. It's also possible you'd fuck up some compiler optimizations.

> if you aren't precise to the millisecond things will jump around

It is correct that precision is very important here, but, a millisecond is way too coarse: at 120fps, a millisecond is 1/8 of the frame time, and you'd get horrible jitter.

Ehh. The framerate doesn't actually matter that much, because in the end the actual pixel changes color at the same rate regardless of FPS. No shader is periodic at 120 Hz; they're very rarely periodic at even 10 Hz.

10 Hz is already a slow strobe light; 1 ms deltas means that each flash is within ~1% of the correct color.

If you're doing something like raymarching in the pixel shader, then you might want sub-millisecond resolution. In 99% of normal shaders, I don't think so. That kind of precision comes into play more with moving objects, where a tiny time delta can mean the difference between a pixel being completely lit or completely dark. Even then though, bad time resolution is just as likely to manifest as motion blur or something.

I think everyone who responded to you makes a point that just doesn't matter, because it's in a shadow of a much more significant problem:

If your formula involves Π, multiplying it by an integer will produce a float, with its precision problems.

Though you could define pi as 31415 integer... Though if Hwillis is right and originally an integer would overflow after ~50 days, now, being 10000 larger, it would overflow after ~7 minutes.

And finally, if you use sine or cosine, which take radians as input, any whole number passed to them (which probably are at that point converted to floats, but let's assume they aren't) will be a multiple of 57.2957795° expressed in degrees. Almost a sixth of full rotation is way too big of a step for any smooth transition.

Out of curiosity I decided to check if multiplying 1 radian could result with a very big, but visually (due to wrapping around 360°) only a little step:

  print(min((180/pi*i % 360, i) for i in range(1,100000)))

Apparently 19 radians is ~1088.62° (mod 360° =~ 8.62°)

44 radians is ~2521.01° (mod 360° =~ 1.01°)

377 radians is ~21600.509° (mod 360° =~ 0.509°)

710 radians is ~40680.00345° (mod 360° =~ 0.00345°)

The last result is surprisingly good, but isn't it a spoonful of honey in a barrel of tar? :)

BTW, changing min to max in the Python script will also give useful results (close to 360 rather than close to 0). Worse results for low multipliers but better results near the end of the range.

int % float -> float is not a native operation I'm aware of on any CPU or GPU. Even C doesn't have this operation -- the % operator only applies to integers, and the float variant is a function, fmodf(float, float); shading languages are similar. Also note that GPUs don't have any sort of integer division instruction.

I'm confused why you need a global total game-time anyways, or if you have one why it has to be precise. Could you use your precise time in float, and then increment a larger but less-precise total gametime value every 10 minutes?

It doesn't have to be game time, as the article says it could be time since level or some other trigger. It's basically about any time based counter you need for a time based effect, such as a predefined cyclical wind effect on trees or waves in water. The article also explains why it has to be precise, looping effects will behave oddly if the loop is not occurring precisely. Splitting the number into a large part and a precise part doesn't actually solve for anything, it just moves the problem into "how do I make arbitrary effects precisely loop based on the 2 parts of the time" instead of "how do I make arbitrary effects precisely loop based on the time".

If it moves the problem far enough forward in practice it won't matter though. If somebody runs The Witness for 100 days that's on them

It doesn't move it to 100 days, it'd move the problem to 10 minutes. Shaders can't just take a large number as a large piece and small piece unmodified, solving for this in the logic is the same as solving for the original cycle matching problem.

Reply on news.ycombinator.com