Yet another application of “Atwood’s Law“:
Currently it runs in all modern browsers, but only Chrome’s
<canvas/> performs well enough at this point to really be playable. With WebGL coming to Firefox and WebKit we’ll hopefully see a lot more of this kind of stuff in the future.
@Boris: Interesting note. I was basing my comment on the authors note about Chrome having a better optimized canvas.
(As an aside: why oh why didn’t Firefox just use one of the many solutions for generically generating native machine code in an architecture independent way? LLVM, for instance.)
Yeah, I mailed the author. The tweak he mentions was actually due to a change in how the script interfaces with Chrome’s canvas; not sure yet whether it was working around a bug in said canvas (or rather imageData) or in V8….
Just to be clear, in my m-c build I se us spending 3% of the time in canvas painting. This is while getting somewhere in the 8-15fps range (depending on ROM).
@Boris: I wonder if JSNES is perhaps the next SunSpider? At a minimum it’s more entertaining than any other JS benchmark that I know of 😉 .
Because a) the roms have to be kept server side b) once Nintendo sees this project, they’ll likely push for a cease-and-desist regarding the storage of roms for everyone to play online.
Plus binary data support is just ideal for the future of this project.
But who knows, maybe he’ll add Google Gears support in the future (and hopefully support to go along with it).
@Hugh: Clearly the project should just add a file upload mechanism, to use local ROMs.
The performance issues in WebKit turned out to be due to dictionary-vs-object property caching heuristics making a wrong guess. As of http://trac.webkit.org/changeset/48573 it’s running at full speed.
@David Smith: Most excellent. That explains why Chrome was recommended and Safari got no mention.