4 ms·
> execution several times slower by a standard JS VM is no better than no execution Having worked in games for a while I disagree. From a user perspective, I'v
by Arelius 14y ago
> execution several times slower by a standard JS VM is no better than no execution
Having worked in games for a while I disagree. From a user perspective, I've found that when games don't work at all players often feel the developer is too blame, while if it runs but just unplayable slow they are much more open to blame the system they play it on.
And let's be honest, if this is important for any sort of app, games are indeed one of them.
Additionally, I'd much rather all my features work, but have to scale back on visual effects, rather than have to write both a high-performance, and a low-performance version, and still be required to scale back effects.
From my perspective in game development the asm.js approach seems to be a significant win.
- yareally 14y ago> Having worked in games for a while I disagree. From a user perspective, I've found that when games don't work at all players often feel the developer is too blame, while if it runs but just unplayable slow they are much more open to blame the system they play it on. Steam comments on their forums seem to blame developers regardless from just my history of reading them. There might be more arguments about who is to blame (when there's some it runs fine for), but plenty still blame the developer when it runs slow and their system should be able to run it (such as in claims x similar game runs so y should [even if it's not apples and oranges, but users think so anyways]).