Then, any number you type into a tweak file, that has no more than 3 digits after the decimal, will result in an integer number of times around the circle. How do we ensure that, easily, in a way that people don't have to think about? Pick, for time_max, a number of seconds that is 10 to some integer power - for example, 1000. Since we have a factor of 2*PI in there, this means that our wave will be flawless any time freq*time_max is an integer. So cos(freq*time_max*2*PI) also has to be 1, in other words, the cosine has to have gone around the circle an integer number of times. The constraint you have to meet, for your cosine waves to match up when the timer resets, is that they all have to evaluate to 1 at whatever the max time is - because when you reset to time = 0, you will get cos(freq*0*2*PI), which is 1. For example, if you want to make a cosine wave that is seamless across time, you can make the wave with a period of 1 minute, or half a minute, or 1/3 a minute, etc, and firstly this is annoying because when designers want to tune stuff, they have to know this, and it's unwieldy and confusing, and secondly, these numbers cannot be represented exactly in floating-point numbers either, so you're adding imprecision that way.īut there is an old graphics programmer trick that solves this very cleanly, that I think has been around for a long time (I first heard of it from Ignacio when we were working on The Witness).įor our cosine wave example mentioned above, we are going to be evaluating some function like cos(freq*time*2*PI), where 'time' is just the wall clock time according to the game, and 'freq' is some parameter controlling the frequency of the cosine wave, that we want it to be very easy for designers to adjust without introducing problems. But if you want your effects to be seamless, they all have to match up exactly at the 1-minute boundary, which makes tuning things difficult and annoying. You could pick a fixed amount of time, like I don't know, every minute, and at the end of the minute the time is back at 0 and you keep going. One way to solve this is not to let the current time grow indefinitely - at some point, you reset it to 0. Long before this time, you'd start to see jitteriness in animation, things not matching up to where you'd expect them to be, etc. That is really very high and a recipe for all kinds of numerical problems you don't expect - if you add the delta time to the current time, in a 32-bit float, the delta time is almost completely destroyed because there is not enough precision in the number. At which point the ratio of the current time to the frame time is like 250,000 / (1/60) = 15 million.
The witness mac crack Pc#
If the game is running at 60fps (which on PC these days is considered maybe a slow frame rate!), that's 0.017 seconds per frame, and we might be doing math that involves both this dt and the current time. Those numbers don't seem super big, but at the same time, we also deal with numbers that are small. If someone leaves the game running for 3 days (a certification requirement on consoles!), it would get up over 250,000. If that number is measured in seconds, then after 10 minutes it will be around 600, after 2 hours it will be 7200, etc. That time variable counts upward, maybe from the time the level started, or the time the game started. In shaders, we often want to have a time variable, controlled by the CPU, that we can use to help generate effects.
Most of the time it's not an issue and programmers don't think about it, but there are some times when it can be an issue. This is a general thing about computers, not just graphics (it is the price we pay for being able to pretend we can store real numbers in small amounts of memory). In general, with floating point numbers, there is a problem with loss of precision when you do computations involving large numbers added to small numbers the small numbers tend to get dropped and go toward zero. There's one other place where fog snaps right now, and that is in time - it is probably pretty easy to fix, though the explanation might be a little unexpected so I am Ccing it to the team as a general knowledge transfer thing. (I was sending an email today about a simple trick we use in the shader system, and it seemed easy and useful to share that email publicly, so, here you go!)
0 kommentar(er)
