JS-VBA-M: World's First Working Webgl based JS GBA emulator!

[ILOVEPIE]

JS-VBA-M

 

 

Hey guys just thought I'd share a project I'm working on. I am porting VBA-M to Javascript using the Emscripten C/C++ to javascript compiler and a modified version of the VBA-M SDL code.

 

Runs natively in browser with no plugins required!

 

Development Progress Picture (I am using Pokemon Ruby as the testcase):

 

[video=youtube]

<div><iframe width="480" height="270" src="https://www.youtube.com/embed/pjCuM6pnI ... ure=oembed" frameborder="0" allowfullscreen="true"></iframe></div>

 

 

Progress:

 

• Get JS-VBA-M to compile. Done.

 

• Fix the command line arguments parsing code. Done.

 

• Get it to load a game and run it. Done.

 

• Get it to display the FPS meter. Done.

 

• Get it to display the game. Done.

 

• Get it to run at at least 48% speed (the cross-compiler promises the program will run at most 4x slower than native when the optimization options are configured correctly, so as my computer runs VBA-M at 87% speed, the JS version should run at 48% speed at it's slowest). WIP (still fiddling with compiler optimization options (getting ₃₈% speed on my laptop)).

 

• Streamline the build system and fix the cmake files to work correctly with emscripten. Todo.

 

Working Version:

http://dl.dropbox.com/u/20328726/vbamjs/index.html

[grantgalitz]

Nice, although Emscripten does not really mean ported. It means you "compiled" it to JavaScript really. I had been working on my own JS GBA emulator, although I've been AFK on IodineGBA (and github in general) for about a month.

 

Also it's not the first: https://github.com/jpfau/gbajs

 

Problem with emscripten is that there are certain conventions that work on the LLVM level that do not work well on the JS level. Low level heap/stack ops often do not play well when compiled via emscripten to js. Not to mention there are many programming conventions fast in C/C++ that are slow in JS that could be substituted with other conventions in JS.

[ILOVEPIE]

Nice, although Emscripten does not really mean ported. It means you "compiled" it to JavaScript really. I had been working on my own JS GBA emulator, although I've been AFK on IodineGBA (and github in general) for about a month.

 

Also it's not the first: https://github.com/jpfau/gbajs

 

Problem with emscripten is that there are certain conventions that work on the LLVM level that do not work well on the JS level. Low level heap/stack ops often do not play well when compiled via emscripten to js. Not to mention there are many programming conventions fast in C/C++ that are slow in JS that could be substituted with other conventions in JS.

While that is very true, Emscripten when set up correctly will automatically convert those things to the correct faster versions in javascript... I get almost a 20% speedup by compiling with some of the options...

I'm getting 20% of the actual device speed with just the default optimisations... im thinking of trying -02 with some other custom optimisations...

[grantgalitz]

Emscripten cannot do some risky optimizations due to edge/unsafe logic conditions. See making jump tables in JS.

[mudlord]

Impressive, but I advise to pay attention to what grantg sez

[ILOVEPIE]

Impressive, but I advise to pay attention to what grantg sez

 

I know what I'm doing, the thing is Grant is right that emscripten has these problems... In some cases.

This is not one of them.

 

But thanks!

 

I just found out it works correctly on the Droidx if you use Opra Mobile.