3 ms·

Don't forget the part where they use web tech and waste draw calls like crazy on the UI. These things should literally be banned. edit: not web tech should be

Don't forget the part where they use web tech and waste draw calls like crazy on the UI. These things should literally be banned. edit: not web tech should be banned, but releasing a game with horrible optimisation like this, either by the store selling the game or by the law

chc 3y ago
Using web tech for the UI isn't a problem here. The article, when measuring the performance impact of different rendering phases, describes the time the UI requires as "an irrelevant amount of time."
capableweb 3y ago
Where are you getting this from? I'm literally sitting with the game open right now with the Chrome Devtools connected to it, and I'm seeing no unnecessary modifications on the DOM side of things. Could be that the integrated the Gameface library incorrectly I guess? Still interested in more details from you.
- Pannoniae 3y ago
  Directly from the article: "The last remaining draw calls are used to render all of the different UI elements, both the ones that are drawn into the world as well as the more traditional UI elements like the bottom bar and other controls. Quite a lot of draw calls are used for the Gameface-powered UI elements, though ultimately these calls are very fast compared to the rest of the rendering process. " With this minimalistic, flat-style soulless UI, the correct number of draw calls spent on UI should be single digits....
  - capableweb 3y ago
    Not sure what kind of projects you've worked on before, but the ones I've been involved in, you wouldn't spend time optimizing something taking <1% of render time when other parts are heavily affecting the final render time for each frame. Why on earth would they try to optimize how the UI renders when they're having big issues elsewhere?
    - Pannoniae 3y ago
      Sorry, my initial comment probably come off quite differently. It's not that "using web UI" is the reason why this game has awful performance, that's more like a bellwether for the studio's priorities. It's absolutely not the most important, or even in the top 10 most important problems here, but it shows really illustratively how much they care about making a game which performs in an acceptable way. (which is: not that much) Also, it's not even one or two high-poly models dragging the performance down, what I was aiming at is that the game suffers from death by a thousand cuts - the LoDs are only a part of the issue, almost every part of the game is done in a sub-optimal way. So while the UI is not a significant part of the frame time, if they fix the most glaring performance issues, they will find that there won't be a silver bullet, the game is just a pile of small performance problems all the way down.
      - jsnell 3y ago
        > It's not that "using web UI" is the reason why this game has awful performance, that's more like a bellwether for the studio's priorities. All it shows is that optimizing something that was already fast enough was not a priority. But why would you want it to be?
        kbelder 3y ago
        Sometimes you can take those small design decisions as indicative of how decisions are made in a company. I remember back when Apple removed the SD card slot from their phone. It wasn't a deal-breaking change, because their phones had lots of memory built in... but at the time, it seemed to me that the decision makers that did that, would continue to make similar decisions, each one making me unhappier and unhappier. So I bought accordingly. And I feel justified in retrospect. Way back in the design stages of this game, somebody though that using web tech for their UI was a good idea, and it didn't get vetoed. That indicates bad judgement somewhere in the chain. Who knows whether it's developers, managers, or what... but the best predictor of bad decisions is previous bad decisions. It's at least a dysfunction smell.
        3y ago
  - alright2565 3y ago
    The author calls out render passes that take 100us, and considers this pass too fast to give a number to. Why does it matter if it's 5 render calls or 500? The developers clearly have plenty of work to do optimizing the other 70ms, it doesn't make sense for them to spend any time working on this.
- rstat1 3y ago
  "Quite a lot of draw calls are used for the Gameface-powered UI elements, though ultimately these calls are very fast compared to the rest of the rendering process." Literally quoted from the article. Standard 2D UI like that can be done in as little a single draw call (or so I have read, never actually done it)
  - lyu07282 3y ago
    If you composite on the CPU I guess? no that React/Webpack UI is actually a pretty good solution to complex game UIs. It offers great DX while the performance penalty is miniscule compared to a huge deferred render pipeline. Btw the last Sim City used the web platform for UI too.
    - rstat1 3y ago
      the last Sim City is not something that should be held as a model of what to do here. Great "DX" now when your building it, but good luck maintaining it over the long term.
johnnyanmac 3y ago
Ehh, I've had ideas to try and bridge the web stack to game development. As much as I hate JS, I've hated every other GUI system in games even more, except IMGUI (which isn't necessarily flexible enough for production UI). So why not utilize the decades of knowledge from an industry who's entire paradigm is improving UI workflows. Of course, it's a butt ton easier said than done, but if the industry could utilize flash for years after it died, I see a glimmer of hope. >releasing a game with horrible optimisation like this, either by the store selling the game or by the law you really want the government to regulate video games because you can't run a frame in 16ms? Talk about a slippery slope.

chc 3y ago

Using web tech for the UI isn't a problem here. The article, when measuring the performance impact of different rendering phases, describes the time the UI requires as "an irrelevant amount of time."

capableweb 3y ago

Where are you getting this from? I'm literally sitting with the game open right now with the Chrome Devtools connected to it, and I'm seeing no unnecessary modifications on the DOM side of things. Could be that the integrated the Gameface library incorrectly I guess? Still interested in more details from you.

Pannoniae 3y ago
Directly from the article: "The last remaining draw calls are used to render all of the different UI elements, both the ones that are drawn into the world as well as the more traditional UI elements like the bottom bar and other controls. Quite a lot of draw calls are used for the Gameface-powered UI elements, though ultimately these calls are very fast compared to the rest of the rendering process. " With this minimalistic, flat-style soulless UI, the correct number of draw calls spent on UI should be single digits....
- capableweb 3y ago
  Not sure what kind of projects you've worked on before, but the ones I've been involved in, you wouldn't spend time optimizing something taking <1% of render time when other parts are heavily affecting the final render time for each frame. Why on earth would they try to optimize how the UI renders when they're having big issues elsewhere?
  - Pannoniae 3y ago
    Sorry, my initial comment probably come off quite differently. It's not that "using web UI" is the reason why this game has awful performance, that's more like a bellwether for the studio's priorities. It's absolutely not the most important, or even in the top 10 most important problems here, but it shows really illustratively how much they care about making a game which performs in an acceptable way. (which is: not that much) Also, it's not even one or two high-poly models dragging the performance down, what I was aiming at is that the game suffers from death by a thousand cuts - the LoDs are only a part of the issue, almost every part of the game is done in a sub-optimal way. So while the UI is not a significant part of the frame time, if they fix the most glaring performance issues, they will find that there won't be a silver bullet, the game is just a pile of small performance problems all the way down.
    - jsnell 3y ago
      > It's not that "using web UI" is the reason why this game has awful performance, that's more like a bellwether for the studio's priorities. All it shows is that optimizing something that was already fast enough was not a priority. But why would you want it to be?
      - kbelder 3y ago
        Sometimes you can take those small design decisions as indicative of how decisions are made in a company. I remember back when Apple removed the SD card slot from their phone. It wasn't a deal-breaking change, because their phones had lots of memory built in... but at the time, it seemed to me that the decision makers that did that, would continue to make similar decisions, each one making me unhappier and unhappier. So I bought accordingly. And I feel justified in retrospect. Way back in the design stages of this game, somebody though that using web tech for their UI was a good idea, and it didn't get vetoed. That indicates bad judgement somewhere in the chain. Who knows whether it's developers, managers, or what... but the best predictor of bad decisions is previous bad decisions. It's at least a dysfunction smell.
        3y ago
- alright2565 3y ago
  The author calls out render passes that take 100us, and considers this pass too fast to give a number to. Why does it matter if it's 5 render calls or 500? The developers clearly have plenty of work to do optimizing the other 70ms, it doesn't make sense for them to spend any time working on this.
rstat1 3y ago
"Quite a lot of draw calls are used for the Gameface-powered UI elements, though ultimately these calls are very fast compared to the rest of the rendering process." Literally quoted from the article. Standard 2D UI like that can be done in as little a single draw call (or so I have read, never actually done it)
- lyu07282 3y ago
  If you composite on the CPU I guess? no that React/Webpack UI is actually a pretty good solution to complex game UIs. It offers great DX while the performance penalty is miniscule compared to a huge deferred render pipeline. Btw the last Sim City used the web platform for UI too.
  - rstat1 3y ago
    the last Sim City is not something that should be held as a model of what to do here. Great "DX" now when your building it, but good luck maintaining it over the long term.

johnnyanmac 3y ago

Ehh, I've had ideas to try and bridge the web stack to game development. As much as I hate JS, I've hated every other GUI system in games even more, except IMGUI (which isn't necessarily flexible enough for production UI). So why not utilize the decades of knowledge from an industry who's entire paradigm is improving UI workflows. Of course, it's a butt ton easier said than done, but if the industry could utilize flash for years after it died, I see a glimmer of hope. >releasing a game with horrible optimisation like this, either by the store selling the game or by the law you really want the government to regulate video games because you can't run a frame in 16ms? Talk about a slippery slope.