Slashdot Mirror
A JavaScript Gameboy Emulator, Detailed In 8 Parts
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."
...but whenever I use one, I can't help but think "I sure wish this was written in Javascript, so there wouldn't be any way to save my game. Saved games are for pussies. And sure, it wouldn't support sound, but who needs that when you've got the beautiful noise of your computer fans running on full blast, thanks to its excessive CPU usage!"
Both sound and client-side data storage are features of HTML5.
Real men write their GB emulators in Minecraft.
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 about this while writing my NES emulator in flash.
I read through these articles hoping for some insight on dynamically generated sound, but it doesn't look like he's gotten that far.
Things you think are in the Constitution, but are not.
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.
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.
Indeed. https://wiki.mozilla.org/Audio_Data_API#Writing_Audio and https://github.com/corbanbrook/dsp.js are closer to what's needed for realtime synthesis. Hopefully it will make its way to other browsers too.
And here's a Vic20 emulator in Javascript HTML5
http://www.mdawson.net/vic20beta/vic20.php
Saying that you shouldn't write this in JavaScript because of the limitations of JavaScript in web browsers is like saying people shouldn't write Apps in Java because Applets are limited. It's not JavaScript that is the problem per se, but the limitations of the Interpreter. If you want to write something like this in JavaScript, you should consider compiling the JavaScript instead.
Using the Unity Framework ( http://unity3d.com ), you could write the emulator in JavaScript, compile it, and have a cross platform emulator that would work on Mac, PC, Wii, Iphone, Android, and PS3 with hardware accelerated 3d, support for sound, etc. Something like 20-25 of the top 100 Iphone Apps were made using Unity, and it is a pretty good platform for making 3d games.
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 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.