Unity’s frame pipeline wasn’t implemented from scratch. Click on the image to see it in full size: Since platform selection and various settings significantly affect it, this article will assume a Windows Standalone player with multithreaded rendering enabled, graphics jobs disabled, vsync enabled and QualitySettings.maxQueuedFrames set to 2 running on a 144 Hz monitor without dropping any frames. With that knowledge in mind, let’s take a look at a typical frame timeline in Unity 2020.1. If VSync is enabled, this additionally synchronizes to the start of the display’s VBLANK period. Most commonly, this is implemented by waiting until some previous frame is flipped to the front buffer (also known as the screen buffer). Since different pipeline stages take different amounts of time, we need to artificially halt the faster ones so they don’t get ahead too much.Or perhaps the player rolled their face on the keyboard, which made input processing take longer. Perhaps this frame has more objects on the screen than the last, which would make rendering take longer. Each pipeline stage takes a different amount of time every frame.
However, even that is a simplification of what actually happens every frame in the engine: Pipelining the engine changes the frame time from being equal to the sum of all pipeline stages to being equal to the longest one. In both of these cases, individual parts of the game loop take the same amount of time, but the second case executes them in parallel, which allows it to push out more than twice as many frames in the same amount of time.
0 kommentar(er)
