4 ms·

Game engines and browsers have radically different architectures and performance/productivity requirements. Computing polygons is basically applying one functio

Game engines and browsers have radically different architectures and performance/productivity requirements. Computing polygons is basically applying one function to an array of values and is delegated to the GPU, so its no wonder they easily reach 60 FPS with hundred of thousands of polygons per frame. A better comparison would be against the performance of game logic, which in a game engine can easily become the bottleneck from all the conditionals, random memory accesses and sequential dependencies. And even there they don't sit on nearly as many layers of abstractions as a web page does. This comes at the cost of productivity; building a web site is a few orders of magnitude more productive than using the latest game engines. Of course, sitting on the DOM and its many quirks as well as its reflow/redraw cycles can make it harder to reach 60FPS in the browser. But at least you're saving yourself from a world of low-level pain.

andrepd 11y ago
So essentially you are sacrificing your end result for an easier time for yourself, the developer.
- jeremiep 11y ago
  You're sacrificing performance, not the end result. However, a lot of the performance tricks do carry over (such as object pooling for example.) But for 99% of the web this doesn't matter at all. I'll take declarative over imperative any day if it means I can spend the saved time polishing the product instead of debugging or optimizing. You have no idea the amount of debugging and optimizing which goes into developing a video game. Having worked on both I can say time spent debugging/optimizing is at least an order of magnitude more than for web applications. Its much worse when you're using an in-house engine as well.
- deleted 11y ago
  [deleted]
- egeozcan 11y ago
  You are sacrificing your end result every time you don't spend a lifetime designing a custom processor for your application with an instruction set specific to your use case and instead have an easier time living like a normal human being.
  - kitsunesoba 11y ago
    I think there’s a balance to be struck between developer convenience and product quality+performance. If every developer leaned to the extreme convenience we’d quickly end up with a lot of unusable software.
    - jeremiep 11y ago
      True, but that balance is going to be different for every application domains. At the end of the day, one of the few metrics which really matters is the return on investment. A lot of software can afford iterative improvements as well, so its a great idea to start off with extreme convenience and optimize as you scale.
  - andrepd 11y ago
    You can go to extremes, as your preposterous mine-the-silicon-and-smelt-the-chip approach, or you can go to the sort of extremes that makes opening a news article grind my high-end phone to a halt for 20 seconds.
    - egeozcan 11y ago
      That news source is then bloated and unoptimized. There are also a lot of bloated and slow native apps. I don't see your point.
ksk 11y ago
>building a web site is a few orders of magnitude more productive than using the latest game engines. How have you come to this conclusion?
- nacs 11y ago
  If you've ever tried to do even the most basic of UI's in game engines, you'll quickly see the truth in that statement. Even "easy" things on the web like text input boxes, scaling for different resolutions while keeping text crisp, and scrollable content areas are much harder in a game engine.
- jeremiep 11y ago
  I've done both for a living.
  - ksk 11y ago
    So your argument is, for YOU :- game programming is less productive than building a website. That's fine then. I wouldn't disagree with someones personal experience. I thought you were making a general argument that applies to everyone.
    - jeremiep 11y ago
      I was merely saying I learned its less productive by actually developing both video games and web applications instead of simply reading about it. It may be personal experience but it doesn't change the fact that you're working on a much lower level in a game engine with long iteration times while a browser reloads almost instantly and builds on layers after layers of abstractions. That argument still applies to everyone.
kitsunesoba 11y ago
It’s also worth noting that the web technologies were initially (and still mostly, actually) designed to layout documents, not to craft highly graphical, interactive, animated application UIs. If this is the direction the web is going, I think it’s worth considering a shift to technologies better suited for the task (QML, for instance, looks like a great preexisting application-centric alternative to HTML). Old browsers that don’t support this tech would be taken care of by HTML polyfills until adoption of new browser versions is high enough.
- keithy 11y ago
  Well if you think about it, the netflix UI is pretty much a bunch of documents. It's a gallery of images, and each image has its own document. The DOM is a dinosaur unfortunately, it just gets the job done for most basic websites. CSS is also a language made for the DOM. The thing is, the DOM isn't required for a web page. Netflix could have coded up their entire UI on a Javascript 2D game engine and could have ended up with a faster app for sure. But CSS and the DOM make it much easier to work with text + links, that imo it's worth it for the performance drop of animations.
  - cmaggard 11y ago
    Not to mention the nightmare that accessibility would be if you were just rendering polygons on a canvas.
- CarVac 11y ago
  I'd certainly be all for web pages with QML performance. QML is a tremendously easy way to leverage OpenGL acceleration.
Retric 11y ago
AAA games are a long way from that. GPU's shaders v3.0 are Turing complete. PS: Top graphics cars AMD Radeon R9 295X2 is 11+ TFlops, 1920 x 1080 x 60 = 124 million. So, these cards have ~100,000 Flops per pixel per frame @1080p.
- jeremiep 11y ago
  I know, I spent a few months this year simplifying shader code designed for the PS4 in order to run on mobile devices. We basically had to scale down from SM5 to SM3, not an easy task :) Its not because shaders are now turing complete that its a free pass to use these features all over the place, they often come with a noticeable performance cost, which I admit is lesser and lesser every year, but still. Also, having recently completed the port of a next-gen AAA title, I can definitely say most shaders stay far from turing completeness, even on current consoles. We shipped the game with at least 75k generated shaders and I'm fairly certain less than 20% of them made use of those features. Finally, the numbers you mention are from an ideal benchmark case and assuming GPU usage is maximized. Real world conditions will definitely lower these numbers. Modern consoles GPUs have dozens of metrics in their profilers and every single one of them can be a major bottleneck. Its near impossible to achieve 100% GPU usage in a game. We're happy above 80%.

andrepd 11y ago

So essentially you are sacrificing your end result for an easier time for yourself, the developer.

jeremiep 11y ago
You're sacrificing performance, not the end result. However, a lot of the performance tricks do carry over (such as object pooling for example.) But for 99% of the web this doesn't matter at all. I'll take declarative over imperative any day if it means I can spend the saved time polishing the product instead of debugging or optimizing. You have no idea the amount of debugging and optimizing which goes into developing a video game. Having worked on both I can say time spent debugging/optimizing is at least an order of magnitude more than for web applications. Its much worse when you're using an in-house engine as well.
deleted 11y ago
[deleted]
egeozcan 11y ago
You are sacrificing your end result every time you don't spend a lifetime designing a custom processor for your application with an instruction set specific to your use case and instead have an easier time living like a normal human being.
- kitsunesoba 11y ago
  I think there’s a balance to be struck between developer convenience and product quality+performance. If every developer leaned to the extreme convenience we’d quickly end up with a lot of unusable software.
  - jeremiep 11y ago
    True, but that balance is going to be different for every application domains. At the end of the day, one of the few metrics which really matters is the return on investment. A lot of software can afford iterative improvements as well, so its a great idea to start off with extreme convenience and optimize as you scale.
- andrepd 11y ago
  You can go to extremes, as your preposterous mine-the-silicon-and-smelt-the-chip approach, or you can go to the sort of extremes that makes opening a news article grind my high-end phone to a halt for 20 seconds.
  - egeozcan 11y ago
    That news source is then bloated and unoptimized. There are also a lot of bloated and slow native apps. I don't see your point.

ksk 11y ago

>building a web site is a few orders of magnitude more productive than using the latest game engines. How have you come to this conclusion?

nacs 11y ago
If you've ever tried to do even the most basic of UI's in game engines, you'll quickly see the truth in that statement. Even "easy" things on the web like text input boxes, scaling for different resolutions while keeping text crisp, and scrollable content areas are much harder in a game engine.
jeremiep 11y ago
I've done both for a living.
- ksk 11y ago
  So your argument is, for YOU :- game programming is less productive than building a website. That's fine then. I wouldn't disagree with someones personal experience. I thought you were making a general argument that applies to everyone.
  - jeremiep 11y ago
    I was merely saying I learned its less productive by actually developing both video games and web applications instead of simply reading about it. It may be personal experience but it doesn't change the fact that you're working on a much lower level in a game engine with long iteration times while a browser reloads almost instantly and builds on layers after layers of abstractions. That argument still applies to everyone.

kitsunesoba 11y ago

It’s also worth noting that the web technologies were initially (and still mostly, actually) designed to layout documents, not to craft highly graphical, interactive, animated application UIs. If this is the direction the web is going, I think it’s worth considering a shift to technologies better suited for the task (QML, for instance, looks like a great preexisting application-centric alternative to HTML). Old browsers that don’t support this tech would be taken care of by HTML polyfills until adoption of new browser versions is high enough.

keithy 11y ago
Well if you think about it, the netflix UI is pretty much a bunch of documents. It's a gallery of images, and each image has its own document. The DOM is a dinosaur unfortunately, it just gets the job done for most basic websites. CSS is also a language made for the DOM. The thing is, the DOM isn't required for a web page. Netflix could have coded up their entire UI on a Javascript 2D game engine and could have ended up with a faster app for sure. But CSS and the DOM make it much easier to work with text + links, that imo it's worth it for the performance drop of animations.
- cmaggard 11y ago
  Not to mention the nightmare that accessibility would be if you were just rendering polygons on a canvas.
CarVac 11y ago
I'd certainly be all for web pages with QML performance. QML is a tremendously easy way to leverage OpenGL acceleration.

Retric 11y ago

AAA games are a long way from that. GPU's shaders v3.0 are Turing complete. PS: Top graphics cars AMD Radeon R9 295X2 is 11+ TFlops, 1920 x 1080 x 60 = 124 million. So, these cards have ~100,000 Flops per pixel per frame @1080p.

jeremiep 11y ago
I know, I spent a few months this year simplifying shader code designed for the PS4 in order to run on mobile devices. We basically had to scale down from SM5 to SM3, not an easy task :) Its not because shaders are now turing complete that its a free pass to use these features all over the place, they often come with a noticeable performance cost, which I admit is lesser and lesser every year, but still. Also, having recently completed the port of a next-gen AAA title, I can definitely say most shaders stay far from turing completeness, even on current consoles. We shipped the game with at least 75k generated shaders and I'm fairly certain less than 20% of them made use of those features. Finally, the numbers you mention are from an ideal benchmark case and assuming GPU usage is maximized. Real world conditions will definitely lower these numbers. Modern consoles GPUs have dozens of metrics in their profilers and every single one of them can be a major bottleneck. Its near impossible to achieve 100% GPU usage in a game. We're happy above 80%.