4 ms·

I think it works if you do it over a generation (of people). Never give a kid less than 50ms of latency and they won’t even realize they’re missing out. The w

I think it works if you do it over a generation (of people). Never give a kid less than 50ms of latency and they won’t even realize they’re missing out. The whole industry will attack the goal from multiple angles and make it happen. I think making GPU ownership expensive to improve the value proposition of streaming services is one of the goals. On paper I think it should be a total failure. In reality, I tried the RTX 3080 tier of GeForce Now and I couldn’t notice the input latency playing Last Epoch. If triple buffering was accepted, 3 frames of latency for streaming will be too, won’t it? I hope it fails because never owning anything sucks, but I think it’ll be extremely successful.

norwalkbear 4y ago
Latency perception is highly game dependent. I worked on the netcode for EA games at one point in my life. The highly popular battle royal and competitive shooters will never go cloud.
hypertele-Xii 4y ago
Triple buffering does not inherently introduce any latency. It's a technique of using more memory to smooth out synchronization issues. Single buffering: You're drawing pixels directly on screen. Problem: Drawing isn't instant across whole screen, so human eye sees a blend of old and new image (and since screens draw top to bottom, this produces a horizontal "tear" somewhere, thus "screen tearing"). Double buffering: You're drawing pixels on a hidden screen while the previous image is displayed, then flip screens. This flip action is so fast it's practically instant, so tearing is solved. However, screens can only flip at set intervals (refresh rate). Problem: What if your drawing finishes even a little bit late, just after refresh rate sync? Now your program has to wait for the next opportunity to flip, which just makes everything hang. Triple buffering: 3 is the magic number to fix all these problems. You always have two virtual screens to flip between, and a third one you can draw to regardless of flipping.
- cpeterso 4y ago
  But isn’t the drawn screen always two frames (32 ms) behind the game loop’s current frame?
  - hypertele-Xii 4y ago
    No. If the game renders on time, what you see on screen is always the latest completed image that was ready at previous vsync. With two buffers, if you render too long and miss vsync and then call flip() which waits until the next vsync, you're wasting the frame waiting (because the system can only swap buffers at vsync, to prevent tearing). The third buffer only exists so that the game can start working on the next frame, while two of the buffers are "locked" (one on screen, other ready for display, third available).
kbelder 4y ago
>Never give a kid less than 50ms of latency and they won’t even realize they’re missing out. The majority of the people now think 24 frames a second looks natural and 60fps looks fake. They're twisted by their malevolent environment into a wrong and unnatural state, like elves into orcs.

norwalkbear 4y ago

Latency perception is highly game dependent. I worked on the netcode for EA games at one point in my life. The highly popular battle royal and competitive shooters will never go cloud.

hypertele-Xii 4y ago

Triple buffering does not inherently introduce any latency. It's a technique of using more memory to smooth out synchronization issues. Single buffering: You're drawing pixels directly on screen. Problem: Drawing isn't instant across whole screen, so human eye sees a blend of old and new image (and since screens draw top to bottom, this produces a horizontal "tear" somewhere, thus "screen tearing"). Double buffering: You're drawing pixels on a hidden screen while the previous image is displayed, then flip screens. This flip action is so fast it's practically instant, so tearing is solved. However, screens can only flip at set intervals (refresh rate). Problem: What if your drawing finishes even a little bit late, just after refresh rate sync? Now your program has to wait for the next opportunity to flip, which just makes everything hang. Triple buffering: 3 is the magic number to fix all these problems. You always have two virtual screens to flip between, and a third one you can draw to regardless of flipping.

cpeterso 4y ago
But isn’t the drawn screen always two frames (32 ms) behind the game loop’s current frame?
- hypertele-Xii 4y ago
  No. If the game renders on time, what you see on screen is always the latest completed image that was ready at previous vsync. With two buffers, if you render too long and miss vsync and then call flip() which waits until the next vsync, you're wasting the frame waiting (because the system can only swap buffers at vsync, to prevent tearing). The third buffer only exists so that the game can start working on the next frame, while two of the buffers are "locked" (one on screen, other ready for display, third available).

kbelder 4y ago

>Never give a kid less than 50ms of latency and they won’t even realize they’re missing out. The majority of the people now think 24 frames a second looks natural and 60fps looks fake. They're twisted by their malevolent environment into a wrong and unnatural state, like elves into orcs.