Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
N64js: an N64 emulator in JavaScript (hulkholden.github.com)
133 points by micheljansen on Aug 16, 2012 | hide | past | favorite | 20 comments


Tried it with two different ROM formats .z64 and .v64 and it wouldn't run.

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.

[1]http://n64js.blogspot.co.uk/


Tried it with a Super Mario 64.z64 and it worked, but died with a Wave Race.v64.

Atwood's Law again.


Yeh, I was using Diddy Kong Racing and it failed with both formats. It's tempted me to get my N64 down from the attic though :)


I think most N64 emulator devs start with Mario 64 as it was one of the first games and probably most documented.

Coincidentally, I've been looking at this https://github.com/paulscode/mupen64plus-ae/ for my phone, it works fine on my Android tablet.


Hi - I wrote n64js.

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.


You're awesome dude. Hope you get to finish this project!


For some perspective, i remember running 'core64' running mario64 full speed on a 200mhz pentium, although IIRC that was all it would run.


I believe you are referring to Corn: http://en.wikipedia.org/wiki/Corn_(emulator)

Running around in Mario 64 on a Celeron 233 with 3d being rendered in software blew my mind.


I remember UltraHLE, it came out in 99! http://en.wikipedia.org/wiki/UltraHLE


Star Fox 64 took awhile to get started but then the intro was going at full speed and looked good. Once it got to the start screen things slowed down again and become unplayable. Still, pretty impressive!


Reminded of this incredible Ars Technica article on why it's so hard to build a good emulator. In short, you need to emulate all of the hardware features and all of the bugs, which have now become features that some games depend on.

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


Be sure to repost this when GoldenEye 007 is working. Especially if multiplayer is working (I assume it would be entirely harder to get actual online multiplayer working, right? Did N64 have any real multiplayer functionality? Either online or N64 to N64 direct connection?)


I personally didn't even have an internet connection when I got my N64 :P

There was no online mode and AFAIK no way to multiplayer across multiple consoles. Multiplayer was 2-4 players slit-screen on one console.


Considering how hot my laptop gets just running mupen64plus, and how slow anything with webgl is, I can't imagine this being playable for quite some time. I imagine it was just a proof of concept.



I am wondering how the emulator performs. JS seems not a right language for this kind of tasks.


Did you visit the website? JS isn't chosen for explicit performance. It's chosen because it can sit in a browser.


Think about it. Nintendo 64 was released around 15 years ago. Its CPU was somewhat slower than the CPUs that typically run modern browsers.


Processor speed is near irrelevant. The processors that ended up in gaming consoles are both extremely complex and unique. More important than that, they were pushed to the absolute limit using specific programming tricks that work only on that processor by devs that had the official Nintendo dev kit. Not to mention full documentation, upwards of 5+ years of dev experience with that specific console, while also surrounded by people who know the ins and outs of the console better than Nintendo.

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.


Think about it. You need a 3ghz machine just to emulate the SNES accurately. With C++.

Doing an N64 in JS will not work.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: