
JavaScript Super Mario Kart - DanielRibeiro
http://www.nihilogic.dk/labs/mariokart/
======
JonnieCache
There used to be a demo floating around where someone had hacked this together
with the firefox nightlies' support for the orientation sensor that allowed to
your drive the kart by tilting your device. It worked for macbook as well as
smartphones. Unfortunately the page is now down :(
<http://dougt.org/random/orientationdemo/index.xhtml>

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...](http://imrannazar.com/GameBoy-Emulation-in-
JavaScript:-The-CPU)

------
thehodge
Not that it changes anything but this is from 2008

------
dstein
So now you take this, and write a NodeJS server, and you could have yourself 2
player SNES through a web browser.

~~~
JonnieCache
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.

~~~
tl
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.

~~~
JonnieCache
_> 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.)

~~~
JoelJ
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.

~~~
JonnieCache
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.

------
kellysutton
Hmmm. Dare I say <canvas> has arrived?

------
robinduckett
[http://blog.nihilogic.dk/2008/05/javascript-super-mario-
kart...](http://blog.nihilogic.dk/2008/05/javascript-super-mario-kart.html)

------
winternett
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! :)

~~~
icefox
Starting with the Torch BlackBerry's have a webkit browser and can render on
the canvas. (disclaimer I work for RIM on webkit)

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

~~~
thisisblurry
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.

