>for example, you wanna update the text on the GUI that says how much gold the player has. you'll update the text after everything that could have influenced the gold this frame has updated (i.e. at the end of the frame).
Modern game engines are pipelined; you render the previous frame logic. In the talk aforementioned, they show a three stages deep pipeline looking like this
This system introduces yet more lag, which is increasingly awful kinesthetically. It makes modern games feel... sticky, sluggish, unresponsive, imprecise. We've gone from instant feedback to ridiculous degrees of input latency.
You press a button. It takes 1 frame for the signal from your USB device to get polled through the OS into your engine. Then it takes 1 frame for the input to affect the logic. Then it takes 1 frame for that change in logic to get "prepared" for rendering. Then it takes 1 frame for the GPU to draw the result. And depending on your video buffering settings and monitor response time, you're still adding a frame until you see the result.
If you're running 60 frames per second, that's an abysmal 83 milliseconds lag on every player input. And that's before network latency.
Last of Us Remastered had +100 milliseconds of input delay. GTA5 was above 150ms. Modern games feel sluggish because of the animations getting more and more realistic. With old games, the input would break the player current animation instantly, today games don't allow that anymore; everything has to be blend together. The input may have to be buffered and analyzed for few "logic" frames before having any effect on the "render logic" frames.
And then there's the output latency of LCD TVs. Seems less of a problem than it used to be, but some older TVs could easily add 50-100ms of latency (particularly if not switched to Game Mode, but even a game mode didn't guarantee great results)
But these days it's hard enough to convince people that 'a cinematic 30fps' really really sucks compared to 60 (or better), and there's an even smaller number of gamers/devs who seem to notice or care about latency issues.
for {
a[i] = something;
b[i] = something;
c[i] = a[i] + b[i]; // can only do a and b at the same time because c depends on them
}
// handle a[0],b[0]
for {
a[i] = something;
b[i] = something;
c[i-1] = a[i-1] + b[i-1]; // can do all 3 at the same time because no deps.
}
// handle c[last]
optimization I saw in a talk about how CPUs can do many instructions at once if they don't depend on each other.
I was unaware of how something like this could play into game engines at the loop level, thanks for the link I'll watch it asap.
https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug...
>for example, you wanna update the text on the GUI that says how much gold the player has. you'll update the text after everything that could have influenced the gold this frame has updated (i.e. at the end of the frame).
Modern game engines are pipelined; you render the previous frame logic. In the talk aforementioned, they show a three stages deep pipeline looking like this
each stage is independent and doesn't require syncing. they call that "frame centric design".