Ported is different from emulated though. Ported involves altering the game itself to run on a different platform. Emulation is building a virtual version of the original platform that does "translation" of sorts between the original platform's methods/attributes/etc and the new platform, leaving the game itself unaltered.
Or just have the user load a rom locally, like I do with my little NES ROM painter[0]. Nintendo strikes down hard on emulation like this. Although I see why he chose DKC, that is one beautiful GBC game.
What would be even more interesting is a JIT-based emulator that worked by compiling bytecode into Javascript, then relying on the browser to compile it back into machine code.
A machine-independent, JIT-compiled JS emulator might actually end up being faster than some purely-interpreted native-code emulators. And unlike a purely native JIT emulator, it wouldn't need a compilation component (the browser would do that itself).
Obviously such a thing would be dramatically slower than a native JIT emulator -- but surprisingly few emulators are JIT-based.
(Possible catch: I know for a fact that some Nintendo DS games use small amounts of self-modifying code. This probably is true of previous generations, too.)
Not a good idea with hand-coded ROMs for CPUs that are in single-digit MHz that use interrupts liberally, it would cause code cache invalidation a lot.
Some stats for SML2 running (Audio ON (web audio for mac in about:flags for chrome, mozAudio for Firefox 4), scaling OFF):
anyone else really sick of posts about "[old game/game system] replicated using HTML5"? make something new and worthwhile rather than pandering to geeks for a change
19 comments
[ 3.3 ms ] story [ 54.3 ms ] threadEdit: Here's the home page, with a full UI: http://www.grantgalitz.org/gameboy/
http://www.zophar.net/pdroms/gameboy.html
[0]http://www.mattgreer.org/exercise/1nespaint
The URL linked above now redirects to the homebrew ROM.
Edit: Oops, I overwrote the redirect, sorry. Try http://www.grantgalitz.org/CrazyZone/
[edit: fix confirmed]
A machine-independent, JIT-compiled JS emulator might actually end up being faster than some purely-interpreted native-code emulators. And unlike a purely native JIT emulator, it wouldn't need a compilation component (the browser would do that itself).
Obviously such a thing would be dramatically slower than a native JIT emulator -- but surprisingly few emulators are JIT-based.
(Possible catch: I know for a fact that some Nintendo DS games use small amounts of self-modifying code. This probably is true of previous generations, too.)
Some stats for SML2 running (Audio ON (web audio for mac in about:flags for chrome, mozAudio for Firefox 4), scaling OFF):
Chrome 12: http://i.imgur.com/JjpT5.jpg 27.0% CPU load
Firefox 4: http://i.imgur.com/yEzzw.jpg 68.6% CPU load
Getting this in Chrome 10.
I think your project needs a little love.
z is B
shift is Select
return is Start
D-Pad is Joypad