Forgot your password?
typodupeerror
Emulation (Games) Nintendo Programming Games

A JavaScript Gameboy Emulator, Detailed In 8 Parts 62

Posted by timothy
from the behind-the-scenes dept.
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:
  • ... why? (Score:5, Insightful)

    by Mongoose Disciple (722373) on Friday November 05, 2010 @10:22PM (#34144700)

    I've said it before, and I'll say it again:

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

    And yes, that includes half (but only half!) of the stuff you'll find done in JavaScript in web apps.

  • Ode to JavaScript (Score:4, Insightful)

    by CobaltBlueDW (899284) on Friday November 05, 2010 @10:46PM (#34144818)

    JavaScript is truly a horrifyingly discussing,
    intrinsically retched,
    soul darkening, succubus from the abysmal depths of conceivable depravity.

    To know its stench
    is to know the crippling limitations of our future.
    To recognize its sloven decadence
    and remain indifferent
    is to burn the righteous.

    No faith,
    however moving and spectacular,
    could light a path of its continuation.
    No argument,
    however complex and equivocated,
    could elevate such a encumbering and wearisome burden.

    There is no failure so inadequate,
    or stagnation so bereft of utility
    as that of JavaScript.

    Thankyou.

  • by evilviper (135110) on Saturday November 06, 2010 @12:41AM (#34145312) Journal

    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.

    If your users have access to emacs, but lack a web browser... ...never mind.

    Web browsers are everywhere, because they are useful applications. They weren't written in Flash, or Javascript, or anything like that. That's part of the reason they are useful to begin with.

    I agree that there need to be web interfaces for many things, because, in a pinch, it might be necessary to work that way. But that's a long way from saying you should need an septuple-core CPU, a browser that hasn't been released yet, and a super-high-speed internet connection, to check your e-mail... Google maps is popular, but that's not to say it does anything that the old plain HTML Mapquest didn't do just as well before it came along (and on 100MHz CPUs over dial-up without trouble).

    That's the question, today. Do you need some massive web interface made of hacked up javascript, or do you just need to have a little app on the server that outputs plain old HTML? Yeah, if I can't navigate your site because you use drop-down boxes for all navigation, and omitted a "Go" button in favor of script because you don't like how the single extra button clashes with the design of the site, I say screw you. Unless I've got absolutely no other choice, NoScript and I are going elsewhere. When Slashdot eliminates the "Classic interface" option, I'll be leaving here, too. I use the web for the content, not to experiment with every random idiot's ideas about interface usability. Hell, anyone who has been on the web long enough will tell you what a nightmare it was when every site was laid out differently, before the world collectively standardized on the format everyone is familiar with today.

    Games? Developers are just be stupid by not putting it in a single EXE that can be run directly. Even a seriously locked down computer will let users download and run a file. And if you're on a ridiculously locked down system which doesn't allow even that... maybe you'll have to live without playing that one game on this computer you're obviously not supposed to be playing games on...

  • Re:... why? (Score:3, Insightful)

    by AstrumPreliator (708436) on Saturday November 06, 2010 @02:51AM (#34145714)
    The same reason someone would write an interpreter or compiler for an esoteric programming language such as Brainfuck or Piet. Or make a homebrew computer. It may not be the most practical thing to do with your time, but it's fun and interesting. The only reason a geek needs to do something is, "I want to."
  • by Anonymous Coward on Saturday November 06, 2010 @04:56AM (#34145968)

    That's what happens when you cut and paste your comments from other websites. You bring their errors with you.

    How slovenly and lazy

  • Re:... Impressive. (Score:3, Insightful)

    by Sycraft-fu (314770) on Saturday November 06, 2010 @05:55AM (#34146090)

    That actually is the case. If you look in to it, you find that fully functional Gameboy emulators, with sound and everything, ran well on 486-Pentium class computers. They were written in C/C++ of course, often with some assembly thrown in. The Gameboy is not challenging to emulate since it is low resolution, gray scale (with very few steps), has a small memory, slow simple CPU, and so on.

    All this really demonstrates is that even if your language sucks and runs on a slow platform (webbrowser's interpreters don't count as fast) that eventually there's enough CPU power to throw at it. It isn't really a testament to Javascript, it is a testament to modern CPUs.

  • by tepples (727027) <tepples@nOSpAM.gmail.com> on Saturday November 06, 2010 @10:11AM (#34146928) Homepage Journal

    Web browsers are everywhere, because they are useful applications. They weren't written in Flash, or Javascript, or anything like that. That's part of the reason they are useful to begin with.

    Unlike your application, the web browser has already been approved by the appliance maker or the PC administrator.

    Do you need some massive web interface made of hacked up javascript, or do you just need to have a little app on the server that outputs plain old HTML?

    On machines with an intermittent connection to the Internet, a massive JavaScript interface using a cache manifest and localStorage can be helpful.

    Games? Developers are just be stupid by not putting it in a single EXE that can be run directly.

    This would need the code and data combined into one file, much like a self-extracting archive. That could suffice for Windows, but Mac OS X and Linux can't run Windows EXEs without CrossOver Games or some other Wine variant. JavaScript runs on any platform with a modern browser.

    Even a seriously locked down computer will let users download and run a file.

    Not always. The administrator of a PC used by the public can set Software Restriction Policies [microsoft.com] to block execution of, for example, executables located inside %USERPROFILE% (the user's home directory).

    And if you're on a ridiculously locked down system which doesn't allow even that... maybe you'll have to live without playing that one game on this computer you're obviously not supposed to be playing games on...

    Video game consoles and other set-top appliances typically can't run native binaries that are not digitally signed by the manufacturer of the appliance, but some can run web pages using JavaScript and/or SWFs using ActionScript. Yet the majority of home users routinely buy consoles instead of home theater PCs.

NOWPRINT. NOWPRINT. Clemclone, back to the shadows again. - The Firesign Theater

Working...