N64js: an N64 emulator in JavaScript
hulkholden.github.com
hulkholden.github.com
Edit: I took a look at the technical information on his blog[1] and found:
"It's still far from being playable. I mean, you can run around in Super Mario 64, but it's not particularly enjoyable. Various other games boot, but there are lots of bugs, graphics glitches and slowness. Realistically, I think it's going to be a long time before enough of these issues are fixed that n64js could be considered 'usable'."
Still, cool that he got it working at all.
Atwood's Law again.
Coincidentally, I've been looking at this https://github.com/paulscode/mupen64plus-ae/ for my phone, it works fine on my Android tablet.
Yes, it's true that Super Mario 64 is one of the easiest roms to get running as it uses relatively few features.
The format (z64 vs v64) shouldn't matter - I byteswap the file on load. I don't handle compressed roms though.
A few other roms that should boot: mario kart, wetrix, aeroguage, extreme-g, pilot wings, star fox. I haven't tested many others yet - let me know if you have success with anything else!
One thing to bear in mind: reload the page when you switch roms. There's some state I'm not resetting properly which breaks everything quite horribly. Sorry for the lameness - I'll try to get this fixed ASAP.
If you open the debug pane, you should get some debug output which gives you some clue as to why the rom failed to boot (usually unhandled memory accesses, unimplemented save format, unimplemented instruction, something like that). For the games that do boot, there are still some cpu bugs which prevent them from passing the CIC-chip's CRC check. E.g. GoldenEye and Zelda OoT both seem to fail in this way.
Running around in Mario 64 on a Celeron 233 with 3d being rendered in software blew my mind.
"It is possible for a well-optimized, speed-oriented SNES emulator to run at full speed using only 300MHz of processing power. You will also end up with hundreds of obscure bugs.
What typically happens is that the problems are specifically hacked around. Both ZSNES and Snes9X contain internal lists of the most popular fifty or so games. When you load those games, the emulators tweak their timing values and patch out certain areas of code to get these games running. It's an improvement over the Nesticle days of the games themselves being hacked externally, but it is still cheating, regardless of the visual end results.
The casual gamer who only plays the most popular twenty or so titles will see no visible differences between an emulator requiring 300MHz and another requiring 3GHz, so they will of course go with the former. Although I do respect and appreciate speed-oriented emulators, one concerned with accuracy can't help but lament the way this approach stalls progress. Without more players using the more accurate emulators, we won't find the bugs in all the games the emulator supports. The more people we have playing the games in the way they were intended, the better the emulator can become as issues are found and stomped out—not by fixing specific code for each game, but by fixing the accuracy of the emulator."
http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o...
There was no online mode and AFAIK no way to multiplayer across multiple consoles. Multiplayer was 2-4 players slit-screen on one console.
Doing an N64 in JS will not work.
Emulating an N64 will continue to be difficult long after x64 processors have outstripped it in terms of speed by hundreds and hundreds of times. It will continue to require an HLE design to be playable until even after that. Then, maybe after we have an LLE N64 emulator, HLE JS N64 emulation will be within the realm of playable.