8 ms·

Computers are so amazing. This incredibly complex and mathematically intensive process we just read about? It happens 30-144 times every second. And this is jus

Computers are so amazing. This incredibly complex and mathematically intensive process we just read about? It happens 30-144 times every second. And this is just the logic to render the scene - there's the additional input logic, game simulation logic, sound logic, and I'm sure dozens of other things that happen once a frame to make a game run smoothly.

Siyo 11y ago
It's funny when you contrast it to web applications. It just shows the layers and layers of bad, inefficient abstractions we've built over the years. For example, re-drawing when resizing the Slack chat window can take up to a second. In that time I could have rendered the Deus Ex scene at 1080p at the highest settings 60+ times.
- angersock 11y ago
  I really, really hate it when people point at a web browser and a modern game engine and then say "Look how sloppy and horrible and inefficient the web is!" Seriously, just stop for a second and use your head. First, that game? Probably using precompiled logic--especially as games in the last decade have gotten objectively harder to mod. The browser must deal with any arbitrary code shoved at it, and handle modifications to its scene graph (the DOM) at any time. These modifications may include creating more script code, pulling in networked resources, or any other damn fool thing. Second, that game is only going to run on a narrow selection of hardware. It's not going to run on a machine from ten years ago, probably. It's not going to run on a machine ten years from now, probably. Third, that game is built to use files and formats specifically made for itself. It's not dealing with old goofy image formats. It's not dealing with potentially malformed XML documents. It's not dealing with any number of things, because those have been trimmed away and pre-verified. Fourth, that game is never going to have to scale from a multiple-socket workstation all the way down to a handheld phone or shell script. It's really silly to point at a hyperoptimized purpose-built tool and claim it is somehow massively better than a platform for distributing massively-varied media and documents. EDIT: Downvote away--but first, write a purpose-built pipeline for deferred rendering, and then a real-time app in Angular, for example. If you haven't done both of these things, you probably don't know what you're raging about.
  - charliefg 11y ago
    I think many would agree with you, that most modern browsers with the expected features are pretty bloody efficient pieces of software. I believe what OP was saying was that the layers of abstraction used in building web application on top of the foundation the browser provides -- while really useful -- are also inefficient. This is to be expected since they do not usually have access to the full capabilities of the operating system and hardware.
  - reitzensteinm 11y ago
    I have done both of those things (though my real time web app is written in React/cljs), and I agree entirely with the grandparent. The difference isn't in the technical details, the difference is that a chat app with a 1 second redraw can succeed in the marketplace, whereas a game with a 1 second redraw will never be played. The bloat and inefficient abstractions grow to the limit of our tolerance. If CPUs had hit the wall at 66mhz single core, that chat app would somehow still take the same 1s to redraw. Of course, it would probably be written in something like NaCL and have significantly more engineering effort put into optimization, with a browser stack engineered for high performance.
    - sliverstorm 11y ago
      The bloat and inefficient abstractions grow to the limit of our tolerance. Which is tragic in some ways IMO. It means every system is always optimized to the level of misery where you are just barely not willing to do something about it. Which when you think about it sounds kind of like what you would expect from a lesser circle of hell.
    - robmcm 11y ago
      Apparently in the early days of HDTV, cable/satellite companies would slowly reduce the quality of broadcasts until people started complaining. At which point they stopped. When BBC HD was a channel, its quanily was black and white to everything else, now even they are in on the reduced bandwidth game :(
  - WolfeReader 11y ago
- andrepd 11y ago
  Makes me wonder, as a non-web developer, would it be possible in principle to develop for the web in a low-level language like C/C++? What I mean is, is it only impractical and inconvenient for the developer, or is it fundamentally impossible?
  - corysama 11y ago
    It's certainly possible today with emscripten. And, for an old C++ fart like me, it's rather tempting. I'm not saying it's advisable though...
  - bentcorner 11y ago
    Definitely possible, but it's up to you whether or not you're willing to take the time to do it. Modern web apps "deploy" nicely and play well with modern OSs, but at the end of the day you're downloading a bunch of code and running it. Nothing says you couldn't have an OS that downloads compiled binaries and executes them for your web app. A browser just makes it easier to design a page with clicky buttons and text boxes.
  - golergka 11y ago
    Javascript as an abstraction allows developer to have a significantly lower skill level. Remember designer that was upset that she was presented with a FizzBuzz on an interview, which she couldn't solve? She can write websites in Javascript, and actually provide value for people. And this is not only about the beginner developers. I'm a game developer myself, and I use garbage-collected C# with Unity engine instead of pure C++. This means that my games won't have performance or graphics of Human Revolution, but I'm able to prototype and change game logic much faster.
  - pjc50 11y ago
    Your javascript is JIT-compiled and can be extremely fast (see asm.js). Conversely you can have extremely percieved-slow C++ applications (giant office suites etc.). It's not the speed of the language. This is like rookies swapping out multiplications for logical shifts and thinking it should make a big difference. It's the computational complexity. What would "develop for the web in a low-level language" even mean? An assembler interface to the DOM isn't going to help. The problem is the computational complexity of the task. Every CSS rule has potentially to be re-applied to every DOM object every time you change anything. Especially the sizing and layout ones. Because they're all interdependent, paralellism won't save you here. By comparison, games are so fast because pixels can be parallelised. You could build an alt-web if you had a suitably sealed VM running code in any language with access to the rendering portal and a security-enforcing network abstraction. This was what Java applets were supposed to be, and Flash is somewhat, but they had three problems: - fixed size: ability to cope with resize or different devices not built in - not as secure as hoped (javascript-to-local-user exploits have been very rare by comparison) - too slow to start up and too willing to hog resources when they did.
- jim_greco 11y ago
  What slack are you running? Slack or any web app doesn't take a second to redraw on resize.
- xaduha 11y ago
  Many games use Scaleform to create UI, which uses Adobe Flash. And I think it's possible to create UI using WebGL for example. Your comparison is just plain stupid. If you don't want to use these abstractions you can opt out, for the most part.
- sebastianconcpt 11y ago
  That's why I found fundamentally interesting the approach of famo.us It uses powerful rendering for mundane widgets (plus uses physics lo layout objects) so your JavaScrip programmed web apps and smartphone apps can do +60fps.
- warfangle 11y ago
  Games have to optimize for performance - if your game doesn't run smoothly on typical market hardware, it's a market failure (generally). Web applications have to optimize for flexibility of development. Performance is certainly important, but at a very different level (usually network and data retrieval) compared to games (massive SIMD operations).

Siyo 11y ago

It's funny when you contrast it to web applications. It just shows the layers and layers of bad, inefficient abstractions we've built over the years. For example, re-drawing when resizing the Slack chat window can take up to a second. In that time I could have rendered the Deus Ex scene at 1080p at the highest settings 60+ times.

angersock 11y ago
I really, really hate it when people point at a web browser and a modern game engine and then say "Look how sloppy and horrible and inefficient the web is!" Seriously, just stop for a second and use your head. First, that game? Probably using precompiled logic--especially as games in the last decade have gotten objectively harder to mod. The browser must deal with any arbitrary code shoved at it, and handle modifications to its scene graph (the DOM) at any time. These modifications may include creating more script code, pulling in networked resources, or any other damn fool thing. Second, that game is only going to run on a narrow selection of hardware. It's not going to run on a machine from ten years ago, probably. It's not going to run on a machine ten years from now, probably. Third, that game is built to use files and formats specifically made for itself. It's not dealing with old goofy image formats. It's not dealing with potentially malformed XML documents. It's not dealing with any number of things, because those have been trimmed away and pre-verified. Fourth, that game is never going to have to scale from a multiple-socket workstation all the way down to a handheld phone or shell script. It's really silly to point at a hyperoptimized purpose-built tool and claim it is somehow massively better than a platform for distributing massively-varied media and documents. EDIT: Downvote away--but first, write a purpose-built pipeline for deferred rendering, and then a real-time app in Angular, for example. If you haven't done both of these things, you probably don't know what you're raging about.
- charliefg 11y ago
  I think many would agree with you, that most modern browsers with the expected features are pretty bloody efficient pieces of software. I believe what OP was saying was that the layers of abstraction used in building web application on top of the foundation the browser provides -- while really useful -- are also inefficient. This is to be expected since they do not usually have access to the full capabilities of the operating system and hardware.
- reitzensteinm 11y ago
  I have done both of those things (though my real time web app is written in React/cljs), and I agree entirely with the grandparent. The difference isn't in the technical details, the difference is that a chat app with a 1 second redraw can succeed in the marketplace, whereas a game with a 1 second redraw will never be played. The bloat and inefficient abstractions grow to the limit of our tolerance. If CPUs had hit the wall at 66mhz single core, that chat app would somehow still take the same 1s to redraw. Of course, it would probably be written in something like NaCL and have significantly more engineering effort put into optimization, with a browser stack engineered for high performance.
  - sliverstorm 11y ago
    The bloat and inefficient abstractions grow to the limit of our tolerance. Which is tragic in some ways IMO. It means every system is always optimized to the level of misery where you are just barely not willing to do something about it. Which when you think about it sounds kind of like what you would expect from a lesser circle of hell.
  - robmcm 11y ago
    Apparently in the early days of HDTV, cable/satellite companies would slowly reduce the quality of broadcasts until people started complaining. At which point they stopped. When BBC HD was a channel, its quanily was black and white to everything else, now even they are in on the reduced bandwidth game :(
- WolfeReader 11y ago
andrepd 11y ago
Makes me wonder, as a non-web developer, would it be possible in principle to develop for the web in a low-level language like C/C++? What I mean is, is it only impractical and inconvenient for the developer, or is it fundamentally impossible?
- corysama 11y ago
  It's certainly possible today with emscripten. And, for an old C++ fart like me, it's rather tempting. I'm not saying it's advisable though...
- bentcorner 11y ago
  Definitely possible, but it's up to you whether or not you're willing to take the time to do it. Modern web apps "deploy" nicely and play well with modern OSs, but at the end of the day you're downloading a bunch of code and running it. Nothing says you couldn't have an OS that downloads compiled binaries and executes them for your web app. A browser just makes it easier to design a page with clicky buttons and text boxes.
- golergka 11y ago
  Javascript as an abstraction allows developer to have a significantly lower skill level. Remember designer that was upset that she was presented with a FizzBuzz on an interview, which she couldn't solve? She can write websites in Javascript, and actually provide value for people. And this is not only about the beginner developers. I'm a game developer myself, and I use garbage-collected C# with Unity engine instead of pure C++. This means that my games won't have performance or graphics of Human Revolution, but I'm able to prototype and change game logic much faster.
- pjc50 11y ago
  Your javascript is JIT-compiled and can be extremely fast (see asm.js). Conversely you can have extremely percieved-slow C++ applications (giant office suites etc.). It's not the speed of the language. This is like rookies swapping out multiplications for logical shifts and thinking it should make a big difference. It's the computational complexity. What would "develop for the web in a low-level language" even mean? An assembler interface to the DOM isn't going to help. The problem is the computational complexity of the task. Every CSS rule has potentially to be re-applied to every DOM object every time you change anything. Especially the sizing and layout ones. Because they're all interdependent, paralellism won't save you here. By comparison, games are so fast because pixels can be parallelised. You could build an alt-web if you had a suitably sealed VM running code in any language with access to the rendering portal and a security-enforcing network abstraction. This was what Java applets were supposed to be, and Flash is somewhat, but they had three problems: - fixed size: ability to cope with resize or different devices not built in - not as secure as hoped (javascript-to-local-user exploits have been very rare by comparison) - too slow to start up and too willing to hog resources when they did.
jim_greco 11y ago
What slack are you running? Slack or any web app doesn't take a second to redraw on resize.
xaduha 11y ago
Many games use Scaleform to create UI, which uses Adobe Flash. And I think it's possible to create UI using WebGL for example. Your comparison is just plain stupid. If you don't want to use these abstractions you can opt out, for the most part.
sebastianconcpt 11y ago
That's why I found fundamentally interesting the approach of famo.us It uses powerful rendering for mundane widgets (plus uses physics lo layout objects) so your JavaScrip programmed web apps and smartphone apps can do +60fps.
warfangle 11y ago
Games have to optimize for performance - if your game doesn't run smoothly on typical market hardware, it's a market failure (generally). Web applications have to optimize for flexibility of development. Performance is certainly important, but at a very different level (usually network and data retrieval) compared to games (massive SIMD operations).