Basically, all game physics simulation will only remain stable up to a certain “refresh rate”. Look up Numerical Analysis, an entire field dedicated to studying algorithms that work with limited precision. It’s likely (I am not a Bethesda core engine coder) to do with the limited precision available on computers. In fact, given the erratic behaviour (flying animals, things getting stuck in each other and so on), they are likely allowing a variable delta in their Physics and their sim is breaking down due to precision issues. They may well do the latter, and they will still have problems if they allow their simulation to run too fast. Can’t stress this enough, you don’t need to justify movies, eating habits or video games to some sort of moral standard. Don’t try and justify yourself with something you don’t know, don’t try and pretend your choice is somehow better than others, people are generally very happy with their purchase, I know it isn’t clear in today’s ignorant social climate but you actually can have a personal preference WITHOUT having to somehow justify it to yourself as the single correct option. No pausing or stuttering for me and i’m used to it with my SLI setup on PC, experienced many a stutter on games that didn’t support SLI. I heard the fps were terrible indoors and was pleasently surprised by not having any noticable slowdown indoors, only some sporadic slowdown in wierd, arbitrary wasteland areas. Played it all day yesterday ON PS4 and only experienced one bug in which my subtitles loaded a line behind the dialog in one conversation. Lol, the obligatory “this is why i” argument. As long as you scale everything on the actual time passed then it doesn’t matter if the frame rate is 30 or 250, the game will run at the right speed regardless. If 16ms passed maybe your object moves 1 unit down. Then you just scale all the movements based on that difference in time (called delta time, or delta milliseconds). When the next frame goes to be drawn, instead of guessing that 16ms have passed, the engine can just check how much time actually has passed since the last frame was rendered. That’s why the second question is better.
When the frame rate goes up to 144, now everything is running fast because all the while you’re making an assumption inside your logic.
But when the frame rate drops to 30, everything now takes twice as long because you’re assuming 16ms have passed when in reality 33ms have passed. You assume that maybe you’re targeting 60fps so you guess that 16ms has passed and you base your physics calculations on that assumption. If you ask the first question, you don’t know how much time has passed, you only know one frame has passed. Where are things now? One frame has passed.Ģ. There are two ways you can ask the question:ġ. It appears that’s what they’ve done, but it shouldn’t be that way.
0 kommentar(er)
