84
Stop blaming teeth for Cities: Skylines 2 performance problems, say devs
(www.rockpapershotgun.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 29 Oct 2023
84 points (100.0% liked)
Gaming
30547 readers
127 users here now
From video gaming to card games and stuff in between, if it's gaming you can probably discuss it here!
Please Note: Gaming memes are permitted to be posted on Meme Mondays, but will otherwise be removed in an effort to allow other discussions to take place.
See also Gaming's sister community Tabletop Gaming.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
That's not a fair comparison. I see people upset because the car isn't a masarati, when they didn't build a masarati. They built a van. I don't need to go 100km/h, I needed something that could carry all of these items I have. And for me, that runs fine.
I will say that I have a new(ish) gaming rig, built about 3 years ago. I do think minimum requirements are jokingly out of date, and those needed to be upped to not mislead people. I don't think even a 1000 series GTX card could play this on minimum settings, let alone a 900. It's better PR just to be up front and say "Look, those cards just aren't going to cut it. If you can't play day one, we're sorry, but we're excited to see you at your next upgrade" rather than lie and say it'll be fine.
I think it is. Note that I wrote 30km/h, not 200km/h. (In case you're American, 30km/h is about 18mph.)
The Last of Us Part 1 is another example. We know it should run better on our hardware (at least with low-graphics settings) because we have already seen the original game run far better on less capable hardware. Yet this one fails to do so even at the lowest possible settings.
Even Baldur's Gate 3, despite being otherwise wonderful, has some glaring hit-and-miss performance issues (think 8 fps at 1080p) that show up on hardware that can handle similar games easily. You don't need to be a software engineer to compare it to Divinity: Original Sin 2, adjust for a few years of hardware inflation, and have a rough idea of how it should perform at moderate-to-low settings.
I don't doubt that those people exist, but I believe they are outliers. Most of the complaints I see about underperforming games in the past year or so are from people with very reasonable expectations. If most of the gripes you've seen are from teeth-blaming Masarati-entitled loudmouths, I suspect it has more to do with the forums you frequent than anything else.
You cannot directly compare PC specs with those of a console. TLoU was made by Naughty Dog who are well known for squeezing absurd amounts or performance out of console hardware. The way to do this by leveraging a platforms specific strong points. The engine is very likely designed around the strengths of the console’s hardware.
PCs have a different architecture from consoles, with different trade-offs. For example: PCs are designed to be modular. You can replace graphics cards, processors, RAM, etc. This comes at a cost. One such cost is that a PC GPU has to have it’s own discrete RAM. There is a performance penalty to this. On a console things can be much more tightly integrated. I/O on a PS5 is a good example. It’s not just a fast SSD, it’s also a storage controller with more priority levels, it’s also a storage controller that interfaces directly with the GPU cache, etc.
Sigh... You conveniently deleted important parts of my comment, such as "at least with low-graphics settings" and "adjust for a few years of hardware inflation", and completely ignored the fact that I am talking about cases of abnormally bad performance compared to entire categories of games. The straw man you're arguing against is not what I wrote.
No, that just supports my theory. Graphics settings usually scale really well, that's the reason they are adjustable by the end-user in the first place. Those should not cause any of the issues you are talking about. The problems lie in parts that take advantage of certain architectural differences.
A hypothetical example that highlights a real architectural difference between consoles and PCs:
Say you have a large chunk of data and you need to perform some kind of operation on all this data. Say, adjust the contents of buffer A based on the contents of buffer B. It's all pretty much the same: read some data from A and B, perform some operation on it, write back the results to A. Just for millions of data points. There are many things you could be doing that follow such a pattern. You know who's really good at doing a similar operation millions of times? The GPU! It was made specifically to perform such operations. So as a smart console game developer you decide to leverage the GPU for this task instead of doing it on the CPU. You write a small compute kernel, some lines in your CPU code to invoke it. Boom, super fast operation.
Now imagine you're tasked with porting this code to the PC. Now, suddenly this super fast operation is dog slow. Why? Because it's data generated by the CPU, and the result is needed by the CPU. The console developer was just using the GPU for this one operation that's part of a larger piece of code to take advantage of the parallel performance of the GPU. On PC, however, this won't fly. The GPU cannot access this data because it's on a separate card with it's own RAM. The only way to get to the CPU is through the (relatively slow) PCIe bus. So now you have to copy the data to the GPU, perform the operation, and then copy the data back to system RAM. All over the limited bandwidth of the PCIe bus, that's already being used for graphics-related tasks as well. On a console this is completely free, the GPU and CPU share the same memory so handing data back and forth is a zero-cost operation. On PC this may take so much time that it's actually faster to do on the CPU, even though the CPU takes much more time to perform the operation, simply to avoid the overhead of copying the data back and forth.
If an engine uses such an optimisation this will never run well on the PC, regardless of how fast your GPU is. You'd need a lot of years of 'hardware inflation' before either doing it on the CPU or doing it on the GPU + 2 times the copy overhead is faster than just doing it on the GPU of the console with zero overhead.
In fact, things like this is why Apple moved away from dedicated GPUs in favour of a unified memory model. If you design your engine around such an architecture you can reach impressive performance gains. A good example of this is how Affinity Photo designed their app around the 'ideal GPU' that didn't exist yet at the time, but which they were expecting to in the future. One with unified memory. When Apple finally released it's M-series SoCs they finally had a GPU architecture that matched their predictions and when benchmarked with their code the M1 Max beat the crap out of a $6000 AMD Radeon Pro W6900X. Note that the AMD part is still much faster if you measure raw performance, it's just that the system architecture doesn't allow you to leverage that power in this particular use-case.
It's not just how fast the individual components are, it's how well the are integrated and with a modular system like a PC this is always going to cause a performance bottleneck.
I mean, you kinda do, though. You have no idea what's going on under the hood in Divinity versus Baldur's Gate. Even if the graphics are similar and the UI looks the same, there could well be much more complex systems involved. Given that they've developed a faithful and fairly wide-ranging representation of D&D 5e, I'm willing to bet that ended up being a lot more involved than their own proprietary system.
That game was just one example, but since you seem interested in singling it out:
Turn-based game rules cannot explain the awful graphics performance that game has, even at idle, on some systems. (Not even D&D 5e, which I happen to know in detail.)
Graphics engine enhancements might explain it, but in that case, the developers should have included options to disable those enhancements.
I haven't reverse engineered the code, but some of the behaviors I've seen in that game smell strongly of decisions/mistakes that I would expect from a game that was rushed, such as lack of occlusion culling. Others smell like mistakes that are common among programmers who haven't yet learned how to use the graphics APIs efficiently, such as rapid-fire operations that should instead be batched. Still others could be explained by poor texture and/or model scaling techniques. As a software engineer, the bad performance in this particular game looks like it could come from a combination of several different factors. None of them are new in this field. All of them can usually be avoided or mitigated.
In any case, the point is that none of that analysis matters for the sake of this discussion, because a community with experience using products doesn't have to be experienced in building them in order to notice when something is wrong. It's not fair to categorically dismiss their criticism.
(Thankfully, the Baldur's Gate 3 developers haven't dismissed it. Instead, they are working on improving it. Better late than never.)