←back to thread

3883 points kuroguro | 5 comments | | HN request time: 0.357s | source
Show context
faebi ◴[] No.26296673[source]
Wow, many people argue how optimized GTA was and then this. I wonder how much money they lost because of this. I often stopped playing because it just took too long to load.
replies(9): >>26296692 #>>26296720 #>>26296775 #>>26296786 #>>26296791 #>>26296828 #>>26297077 #>>26297196 #>>26300316 #
formerly_proven ◴[] No.26297196[source]
GTA V (the single player game) is quite well optimized and needs a frame rate limiter on most newer systems because it will run at over ~180 fps, at which point the engine starts to barf all over itself.

GTA Online is a huge, enormously buggy and slow mess that will generally struggle to run at 80 fps on a top-of-the-line 2020 system (think 10900K at over 5 GHz with a 3090) and will almost never cross the 120 fps threshold no matter how fast your system is and how low the settings are.

replies(1): >>26297317 #
1. ecf ◴[] No.26297317[source]
> at which point the engine starts to barf all over itself.

I’m really confused as to why games are determining anything whatsoever based on the refresh rate of the screen.

Skyrim has this same problem and not being able to play over 60fps is the reason I haven’t touched the game in years.

replies(4): >>26297539 #>>26297778 #>>26298753 #>>26300634 #
2. megameter ◴[] No.26297539[source]
It's a coding strategy intended to optimize around console refresh targets first and then "do whatever" for PC build.

Generally, a AAA console game will target 30hz or 60hz. Therefore the timing loop is built to serve updates at a steady pace of 30 or 60, with limiting if it goes faster. Many game engines also interpolate animations separately from the rest of the gameplay, allowing them to float at different refresh rates. Many game engines further will also decouple AI routine tick rates from physics to spread out the load. Many game engines now also interleave updates and kick off the next frame before the first is complete, using clever buffering and multithreaded job code. All told, timing in games is one of those hazard zones where the dependencies are both numerous and invisible.

When you bring this piece of intricate engineering over to PC and crank up the numbers, you hit edge cases. Things break. It's usually possible to rework the design to get better framerate independence, but doing do would be invasive - you'd be changing assumptions that are now baked into the content. It isn't just fixing one routine.

3. gridspy ◴[] No.26297778[source]
Because if you run the simulation at a different frame-rate from the rendering it is a huge amount more work. Suddenly you have to start marshaling data through intermediate data structures and apply interpolation to everything.

If you then try to run the simulation in parallel with the rendering (rather than between some frames) it is even more work, since inter-thread communication is hard.

This stuff might seem easy for very good programmers, however on a game you want to hire a wide range of programmer skill and "game-play programmers" tend to be weaker on the pure programming front (their skills lie elsewhere)

4. AndriyKunitsyn ◴[] No.26298753[source]
Because unfortunately, in order to draw something on the screen, you need to determine what you draw first. So, before each screen refresh, a thing called "game simulation tick" happens.
5. SSLy ◴[] No.26300634[source]
>Skyrim has this same problem and not being able to play over 60fps is the reason I haven’t touched the game in years.

https://www.nexusmods.com/skyrimspecialedition/mods/34705 >Refresh rate uncap for exclusive fullscreen mode.