3 ms·

Yes, there is definitely a disparity between native code and Javascript running in the browser. Yes, different browsers have different performace bottlenecks, a

Yes, there is definitely a disparity between native code and Javascript running in the browser. Yes, different browsers have different performace bottlenecks, and yes, different hardware configurations and GPU also have a huge impact. On the other hand, you're talking about having problems recreating games that ran on 16Mhz CPUs with 1MB of RAM, which makes me somewhat sceptical. I don't mean to be disparaging, but I expect that there's something in your main game loop that is killing your performance, and that even if you ported it to asm.js or C++ you would still have the same bottlenecks (perhaps masked better on modern hardware by the better native performance). As a counter-example, a reasonably complete and functional HTML5 port of a game from the 90s: http://www.adityaravishankar.com/projects/games/command-and-conquer/ http://www.adityaravishankar.com/projects/games/command-and-...

willvarfar 13y ago
Doubtless it'll come down to some silly mistakes, like having a `for(var attrname in obj)` (as was the construct that caused V8 to unoptimise their Oz game, link above). I've been coding for long enough - started with the ZX81 and 286 - to know we're all mortal. The tools for finding this stuff suck. The tools for finding and fixing this stuff for just a handful of mainstream browsers - Firefox, Chrome and Safari - suck. I want Chrome and Firefox to show code hotness inline in their script browser panes of their developer tools. I want profiling to work for web workers. I want all this without needing to compile my own copy of V8 (as Google advocate in the video above). Just when profiling, electric-fencing and static analysis begin to become mainstream for C++ developers, we're thrown back to basics in browsers. Just because wanting to see asset load and understand the fold are mainstream profiling problems for people making shopping websites, doesn't mean browsers aren't going to get used more and more for gaming-style workloads and will need the profiling and debugging tools that problem demands.

willvarfar 13y ago

Doubtless it'll come down to some silly mistakes, like having a `for(var attrname in obj)` (as was the construct that caused V8 to unoptimise their Oz game, link above). I've been coding for long enough - started with the ZX81 and 286 - to know we're all mortal. The tools for finding this stuff suck. The tools for finding and fixing this stuff for just a handful of mainstream browsers - Firefox, Chrome and Safari - suck. I want Chrome and Firefox to show code hotness inline in their script browser panes of their developer tools. I want profiling to work for web workers. I want all this without needing to compile my own copy of V8 (as Google advocate in the video above). Just when profiling, electric-fencing and static analysis begin to become mainstream for C++ developers, we're thrown back to basics in browsers. Just because wanting to see asset load and understand the fold are mainstream profiling problems for people making shopping websites, doesn't mean browsers aren't going to get used more and more for gaming-style workloads and will need the profiling and debugging tools that problem demands.