Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Emulation (Games) Nintendo Programming Games

A JavaScript Gameboy Emulator, Detailed In 8 Parts 62

Two9A writes "JavaScript has shed its image of being a limited language, tied to DOM manipulation in a browser; in recent years, new engines and frameworks have given JS a reputation as a language capable of bigger things. Mix this in with the new elements of HTML5, and you have the capacity to emulate a game console or other system, with full graphical output. This series of articles looks in detail at how an emulator is written in JavaScript, using the example of the Gameboy handheld: starting at the CPU, and (as of part 8) running a copy of Tetris."
This discussion has been archived. No new comments can be posted.

A JavaScript Gameboy Emulator, Detailed In 8 Parts

Comments Filter:
  • Sound? (Score:5, Interesting)

    by Mr. Sketch ( 111112 ) <mister...sketch@@@gmail...com> on Friday November 05, 2010 @08:44PM (#34144462)

    I'm curious how he plans on handling dynamically generated sound from the GB ROM. Doing CPU and Graphics are usually the easy parts of emulating, but getting smooth dynamic sound without much latency is the challenge I've had to deal with when doing web-based emulators. Most web-based systems are designed to load a static set of sounds from a server, not dynamically generate them in the code.

    Flash 10 provides some dynamic sound capability, but it has a rather large latency (~250ms). I blogged [cgarcade.com] about this while writing my NES emulator in flash [cgarcade.com].

    I read through these articles hoping for some insight on dynamically generated sound, but it doesn't look like he's gotten that far.

  • Permission denied (Score:3, Interesting)

    by tepples ( 727027 ) <tepples AT gmail DOT com> on Friday November 05, 2010 @09:46PM (#34144812) Homepage Journal

    You can write damn near anything in JavaScript if you really want to, but the better question is if you should.

    If your users have access to a web browser but lack the privileges to install a native client on machines that they use, then you have no choice but to write your application in a language that runs inside the web browser. This is often the case in break rooms, public libraries, and university computer labs, where the user isn't the owner, or with locked-down appliances, where even the owner of the device isn't an administrator.

  • Re:Sound? (Score:3, Interesting)

    by Mr. Sketch ( 111112 ) <mister...sketch@@@gmail...com> on Friday November 05, 2010 @10:03PM (#34144898)

    That Mozilla link is along the lines of what I was thinking of for dynamic audio. Too bad it's not supported by all browsers, but it would be a start. With some proper architecture, it should be easy enough to add support for other browsers when they support a similar feature.


    I should probably start looking at what it would take to port my Flash NES emulator to JavaScript. I wrote it in Haxe [haxe.org] with the goal of doing a JS version at some point. However, at the time, only Chrome could even come close to running the JS fast enough, but now most modern browsers should be fast enough (I'll have to do some performance tests). It should just require minor tweaking to replace the flash calls with JS/HTML5 calls without having to re-do and re-work the bulk of the logic.

It is contrary to reasoning to say that there is a vacuum or space in which there is absolutely nothing. -- Descartes