The witness game wiki11/12/2022 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 game wiki 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 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |