JavaScript Super Mario Kart(nihilogic.dk)
nihilogic.dk
JavaScript Super Mario Kart
http://www.nihilogic.dk/labs/mariokart/
8 comments
Not that it changes anything but this is from 2008
So now you take this, and write a NodeJS server, and you could have yourself 2 player SNES through a web browser.
A couple months ago I couldn't sleep and modded vNES[1] to run on a server and host a WebSockets server, and wrote a Javascript client to interact with it so you can control it from the web page. All people looking at the page can simultaneously control the player; I was looking to eventually allow two different people to use controllers 1 and 2 for real multiplayer.
I'm only sure it runs in Chrome, and it gets all sorts of screwed up when more than one person is trying to use it, but you can check it out running Startropics here:
http://balwiki.com/pub/vnes/
Controls are:
[1] http://www.thatsanderskid.com/programming/vnes/index.html
I'm only sure it runs in Chrome, and it gets all sorts of screwed up when more than one person is trying to use it, but you can check it out running Startropics here:
http://balwiki.com/pub/vnes/
Controls are:
D-Pad = Arrow Keys
D = A
F = B
[1] http://www.thatsanderskid.com/programming/vnes/index.html
Pushing emulated console multiplayer through TCP/IP is problematic because consoles and their games are written to expect very low latency because they are meant to be directly connected. I know ZSNES can do TCP/IP multiplayer, but it is impossible on the gameboy/GBA.
This is because communication down the gameboy link cables is two-way and highly timing-sensitive, whereas any lag in controller signals will obviously have no effect on the CPU.
ZNSES multiplayer works through a direct TCP/IP connection, having two (or four depending on how you look at it) HTTP server-roundtrips and node.js in between the two players may create unacceptable latency.
Also: good luck writing a SNES emulator in the browser. The only fully accurate one, written in pure C, still requires a top of the range video card and a dual core machine to run with 100% accuracy. (http://byuu.org/bsnes) Even in 'performance' mode I still get slowdown on my late 2008 macbook. This is emphatically not the fault of the developer.
This is because communication down the gameboy link cables is two-way and highly timing-sensitive, whereas any lag in controller signals will obviously have no effect on the CPU.
ZNSES multiplayer works through a direct TCP/IP connection, having two (or four depending on how you look at it) HTTP server-roundtrips and node.js in between the two players may create unacceptable latency.
Also: good luck writing a SNES emulator in the browser. The only fully accurate one, written in pure C, still requires a top of the range video card and a dual core machine to run with 100% accuracy. (http://byuu.org/bsnes) Even in 'performance' mode I still get slowdown on my late 2008 macbook. This is emphatically not the fault of the developer.
I think that would be due to BSNES's touted "100% accuracy." There are good-enough-for-government-play SNES emulators that work fine on N64-era hardware.
The way to approach this problem isn't to write the emulator to run in the browser, but to build a remote client that controls the emulator running on a more powerful server. Not only do you get the benefit of the server's speed, but if multiple people are playing, you don't have to send machine state over TCP/IP, just graphics data.
Gaikai and OnLive are doing this with current-gen games. Doing it with an SNES would probably be trivial.
This does not, however, solve the issues of game compatibility that you mention in other comments, but in my experience the amount of games that don't work in SNES emulators is trivial.
Gaikai and OnLive are doing this with current-gen games. Doing it with an SNES would probably be trivial.
This does not, however, solve the issues of game compatibility that you mention in other comments, but in my experience the amount of games that don't work in SNES emulators is trivial.
How long is the list of games that zsnes doesn't have 100% accuracy? It had reasonable performance in the Pentium 3 era. We're talking about emulating a 4MHz processor.
>How long is the list of games that zsnes doesn't have 100% accuracy
Plenty of popular games. http://board.zsnes.com/phpBB3/viewforum.php?f=16
Notably, Yoshi's Island glitches out to the point of unplayable-ness in around half a dozen levels under ZSNES, the first one being 'Touch Fuzzy Get Dizzy'. This is the most high profile example.
bsnes is the only emulator that lets you play yoshi's island properly, which happens to be many people's favourite game on the platform.
The problem is down to some games exploiting timing tricks in the graphics subsystem to achieve transparency-like effects and so on. All the emulators apart from bsnes compute the graphics line-by-line, which breaks these tricks. bsnes draws it's output pixel-by-pixel, like a real snes, which is much more computationally intensive.
"The reason is because while a scanline renderer runs at a mere ~15.75khz, a clock-based renderer would run at ~10.75mhz. That may not seem like a lot, but when you are writing an emulator that claims absolutely flawless interprocess communication, that means synchronizing two separate processors over ten million times a second."[1]
All that context-switching makes your processor mad.
The main reason for bsnes is homebrew snes developers' need of a bit-for-bit accurate snes emulator. These people need an emulator that will help them test code they are planning to flash to a cart and run on a real snes. ZSNES and other emulators designed to simply run commercially produced games on their PCs are riddled with hacks and shortcuts, this is what allows them to run fast on low spec machines. However this means that they allow many, many things that a real snes won't, and are useless for development targeted at real hardware.
For more details, see byuu's many rants on the subject, the first of which is here: [1] http://byuu.org/articles/emulation-2/ (Bear in mind it was written ~3 years ago, a lot of the problems he mentions he has since overcome, the aforementioned per-pixel video rendering for example. He discusses this in later essays.)
Plenty of popular games. http://board.zsnes.com/phpBB3/viewforum.php?f=16
Notably, Yoshi's Island glitches out to the point of unplayable-ness in around half a dozen levels under ZSNES, the first one being 'Touch Fuzzy Get Dizzy'. This is the most high profile example.
bsnes is the only emulator that lets you play yoshi's island properly, which happens to be many people's favourite game on the platform.
The problem is down to some games exploiting timing tricks in the graphics subsystem to achieve transparency-like effects and so on. All the emulators apart from bsnes compute the graphics line-by-line, which breaks these tricks. bsnes draws it's output pixel-by-pixel, like a real snes, which is much more computationally intensive.
"The reason is because while a scanline renderer runs at a mere ~15.75khz, a clock-based renderer would run at ~10.75mhz. That may not seem like a lot, but when you are writing an emulator that claims absolutely flawless interprocess communication, that means synchronizing two separate processors over ten million times a second."[1]
All that context-switching makes your processor mad.
The main reason for bsnes is homebrew snes developers' need of a bit-for-bit accurate snes emulator. These people need an emulator that will help them test code they are planning to flash to a cart and run on a real snes. ZSNES and other emulators designed to simply run commercially produced games on their PCs are riddled with hacks and shortcuts, this is what allows them to run fast on low spec machines. However this means that they allow many, many things that a real snes won't, and are useless for development targeted at real hardware.
For more details, see byuu's many rants on the subject, the first of which is here: [1] http://byuu.org/articles/emulation-2/ (Bear in mind it was written ~3 years ago, a lot of the problems he mentions he has since overcome, the aforementioned per-pixel video rendering for example. He discusses this in later essays.)
Strange, I love Yoshi's Island and have beat it many times and have never noticed a problem (at least, haven't noticed it to the point that I would remember it. If it was unplayable, I would've noticed). I'll have to load it up again sometime and see if I see a problem.
Years ago, earlier versions of zsnes did not exhibit this bug. However it used to simply fail to render lots of stuff. What was left behind would still look fine, so you wouldn't notice. Think parallax background layers, sprite effects.
Hmmm. Dare I say <canvas> has arrived?
Brilliant! Now if I can only get it to work on my Blackberry (They run only legacy Java Script), then Blackberry games would not suck, and I'd make a million dollars without having to go through their app store! :)
Starting with the Torch BlackBerry's have a webkit browser and can render on the canvas. (disclaimer I work for RIM on webkit)
[deleted]
Sry.. it does not feel good. It's like alpha stadium. No collision detections, the sprites flickers sometimes, no gifts and stuff. Its like the first lesson of a game development tutorial, where you learn to add basic movement to your sprites.
I think you're overlooking the fact that this was largely done with JavaScript, some light HTML5, and images.
Over two years ago. Emphasis on the over two years ago part.
Over two years ago. Emphasis on the over two years ago part.
In lieu of that, I present to you something much more interesting: A complete step-by-step guide to writing your own fully functioning gameboy emulator in javascript+html5 (without sound.) It's really easy to follow even if you know nothing at all about emulators.
http://imrannazar.com/GameBoy-Emulation-in-JavaScript:-The-C...