Comments on: JSNES JavaScript NES emulator

By: Robert

Robert — Tue, 22 Sep 2009 02:33:57 +0000

@David Smith: Most excellent. That explains why Chrome was recommended and Safari got no mention.

By: David Smith

David Smith — Mon, 21 Sep 2009 20:29:24 +0000

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.

By: Anonymous

Anonymous — Mon, 21 Sep 2009 06:54:39 +0000

@Hugh: Clearly the project should just add a file upload mechanism, to use local ROMs.

By: Hugh Isaacs II

Hugh Isaacs II — Mon, 21 Sep 2009 04:03:24 +0000

The #1 problem I have with this product currently, is the lack of binary data support in Javascript.

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).

By: Robert

Robert — Mon, 21 Sep 2009 03:17:27 +0000

@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 .

By: Boris

Boris — Mon, 21 Sep 2009 02:18:17 +0000

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).

By: Robert

Robert — Mon, 21 Sep 2009 00:27:49 +0000

@Boris: Interesting note. I was basing my comment on the authors note about Chrome having a better optimized canvas.

By: Anonymous

Anonymous — Mon, 21 Sep 2009 00:00:36 +0000

64-bit Linux user here; hopefully Firefox 3.6 with its x86_64 JIT support for JavaScript will speed this up from 6fps.

(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.)

By: Boris

Boris — Sun, 20 Sep 2009 18:01:00 +0000

The limiting factor here is not canvas (which is the same in chrome and Safari, by the way) but the javascript engine doing the emulation. I seriously doubt webgl will change anything here.