by Graf Zahl wrote:There's one thing that's often forgotten with such high refresh rates, though:
They literally reduce the time the CPU has to produce both the game logic and the scene rendering in half, so this may end up having to choose between higher frame rates and more complex gameplay.
Not necessarily. Games can update logic at a fixed rate but render at a much higher rate by interpolating between the two logic states. With rendering and frame interpolation on a separate thread, you could run the logic update over multiple rendered frames, as long as the app is properly structured to calculate a new logic state separately from what the rendering thread is using to draw. Once the new state is ready, there would need to be some synchronization for the rendering thread to begin using the now-complete state, but it doesn't need to run the whole logic at that point in between drawing. Modern games split physics, AI, pathing, and other updates into different threads that update at different rates (the Bullet physics library does this; physics internally update at a set delta to help maintain stable simulations and keep CPU load in check, but the app can step the physics simulation with more fine-grained timing that gets you interpolated "physics frames").
