Uzem ported to HTML5/JavaScript

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Uzem ported to HTML5/JavaScript

Post by Artcfox »

I used the Emscripten compiler to compile Uzem into optimized JavaScript that can be loaded with Firefox or Chrome.

Image

I'm not sure how to get the audio to sound completely correct, but it's surprisingly playable!

I don't have a web server, so I just zipped up the HTML and JavaScript files and attached them to this post.

You'll need WebGL support, and probably a really fast computer. ;)

If we can get the audio part sorted out, I'm envisioning embedded Uzem into each game's wiki page.

Edit: I added a wiki page describing the entire start-to-finish process of publishing a Uzebox game to the web.
Attachments
loderunner.zip
Extract locally, or install these files on a webserver, and open with Firefox or Chrome. WebGL support required, and a fast computer recommended.
(223.86 KiB) Downloaded 657 times
Last edited by Artcfox on Sun Oct 18, 2015 6:21 pm, edited 2 times in total.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem ported to HTML5/JavaScript

Post by D3thAdd3r »

For those that want to try it:http://uzebox.net/uzem.html. That server is under on and off heavy modification so don't count on reliability for up time.

Hey wow, you go man, my head is spinning all this Uzem progress you are busting out. Very cool, though yes I should say I my laptop does not have a prayer with this :lol:
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

D3thAdd3r wrote:For those that want to try it:http://uzebox.net/uzem.html. That server is under on and off heavy modification so don't count on reliability for up time.

Hey wow, you go man, my head is spinning all this Uzem progress you are busting out. Very cool, though yes I should say I my laptop does not have a prayer with this :lol:
Thank you for hosting it!

Well, I've tried and failed to create a good "level complete" sound effect for my game, and this is how I'm procrastinating.

I didn't want to pollute my system with this Emscripten SDK in case it didn't work, so the funny thing is I'm doing all of this in RAM from a Debian 8.2 Live CD. I was like "Oh, maybe I'll just back up my working directory to the cloud," but the emsdk_portable directory after it got done compiling everything it needed is 13 GB. I at least backed up the changes that I made to Uzem to support this, but I really want to get the uzem140 branch with SDL2 support ported over, since that should run a lot faster than this version, which is based on the code from the master branch. I'm thinking about adding #ifdef flags around the Emscripten stuff so it can be checked in on the official branch and conditionally compiled with a makefile target: make emscripten

Edit: I can actually get it to go faster depending on how many calls to uzebox.exec() I make per iteration that the browser calls the main loop, but if I try to do too many, then I'll get the dreaded "A script has stopped, would you like to kill it?" message box. The version you're hosting now only does 1M calls to uzebox.exec() each time the browser framework calls it.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem ported to HTML5/JavaScript

Post by D3thAdd3r »

That would be neat to have. It is pretty interesting to see Uzem running on my cellphone too, I'm not sure what kind of a priority it should be, but is there some way to get input to the canvas without a keyboard? Not too critical as my Galaxy S5 runs slow enough to hear clearly the individual sound effects steps, so I was wondering since I haven't gotten this to run full speed, what is wrong with the audio? From what I can tell the sound effects seem correct pitches for Loderunner, maybe it is just slow/choppy since the buffer keeps running dry.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

D3thAdd3r wrote:That would be neat to have. It is pretty interesting to see Uzem running on my cellphone too, I'm not sure what kind of a priority it should be, but is there some way to get input to the canvas without a keyboard? Not too critical as my Galaxy S5 runs slow enough to hear clearly the individual sound effects steps, so I was wondering since I haven't gotten this to run full speed, what is wrong with the audio? From what I can tell the sound effects seem correct pitches for Loderunner, maybe it is just slow/choppy since the buffer keeps running dry.
If your phone supports USB OTG, and you have an adapter, you can plug a keyboard directly into your phone. Otherwise you're stuck using a bluetooth keyboard.

I don't think that threads are supported, so I'm guessing (a very wild guess) that it's using cooperative multi-tasking to run the audio at the same time. I should try it with sounds disabled to see if it improves the frame rate, but really I should change it so it only renders 240x224 and then scale that up. Really the render width should be a command line option, so at the point where we're reading the raw value from the PORT we can just keep every X byte and drop the rest on the floor. And then Mode 3 games should run much faster on the desktop, and probably on cell phones too. ;)

Here's what it looks like running on my Nexus 5:



And I'm shocked that it also runs decently well in Chrome on my laptop.

Edit: It turns out that it is the 15700 Hz sample rate is part of the reason why the sounds are all choppy. As soon as I changed that to 16000 the sounds are not as choppy. I guess SDL just does a terrible job when it has to convert them. If we can resample and pitch shift them ourselves, that might be another optimization for Uzem on the desktop, though I don't know if we could do it faster than SDL does. I'm guessing that it's also exhausting the buffer, but I can't be sure.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

I incorporated Jubatian's recent optimizations into the HTML5/JavaScript port.

While my computer is still not fast enough to keep up with the music in Megatris, it's getting closer!
Attachments
megatris.zip
Megatris compiled down to HTML5/JavaScript with Jubatian's recent optimizations
(223.04 KiB) Downloaded 646 times
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem ported to HTML5/JavaScript

Post by D3thAdd3r »

User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by uze6666 »

:o That's a pretty impressive feat, congrats! There was an attempt made sometime to port to flash but it was never finished. On my main pc it runs very slow, but on my Surface Pro 3, probably 85%, so very playable! For sure if uzem code would be better to start with, we could be running it full speed on recent machines. I haven't look at emscritem, but it's a C to Javascript compiler? What about SDL, how is it
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

uze6666 wrote::o That's a pretty impressive feat, congrats! There was an attempt made sometime to port to flash but it was never finished. On my main pc it runs very slow, but on my Surface Pro 3, probably 85%, so very playable! For sure if uzem code would be better to start with, we could be running it full speed on recent machines. I haven't look at emscritem, but it's a C to Javascript compiler? What about SDL, how is it
Thanks, though it didn't require too much effort (just a couple hours at most). The Emscripten compiler uses LLVM to generate an intermediate representation, and then it gets optimized and sent to the Asm.js backend, which is a very restrictive subset of JavaScript that gets special treatment by web browsers in that it can almost be translated 1:1 into equivalent machine language instructions of the host computer. SDL is supported natively by Emscripten, and that part gets compiled down into WebGL I believe. There are a few SDL functions you can't use, so I just crudely gutted that functionality out of Uzem, and replaced the SDL_Delay calls with usleep calls, since the framework will kill the application if it ever hits an SDL_Delay call.

Any portable program written in C/C++, that doesn't rely on closed source 3rd parties should be able to compiled with Emscripten.

I just wanted to see if it would work at all, so I used the master branch with SDL1, but I read that SDL2 is supported as well, so I may try to get that working too.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by uze6666 »

Artcfox wrote:
uze6666 wrote::o That's a pretty impressive feat, congrats! There was an attempt made sometime to port to flash but it was never finished. On my main pc it runs very slow, but on my Surface Pro 3, probably 85%, so very playable! For sure if uzem code would be better to start with, we could be running it full speed on recent machines. I haven't look at emscritem, but it's a C to Javascript compiler? What about SDL, how is it
Thanks, though it didn't require too much effort (just a couple hours at most). The Emscripten compiler uses LLVM to generate an intermediate representation, and then it gets optimized and sent to the Asm.js backend, which is a very restrictive subset of JavaScript that gets special treatment by web browsers in that it can almost be translated 1:1 into equivalent machine language instructions of the host computer. SDL is supported natively by Emscripten, and that part gets compiled down into WebGL I believe. There are a few SDL functions you can't use, so I just crudely gutted that functionality out of Uzem, and replaced the SDL_Delay calls with usleep calls, since the framework will kill the application if it ever hits an SDL_Delay call.

Any portable program written in C/C++, that doesn't rely on closed source 3rd parties should be able to compiled with Emscripten.

I just wanted to see if it would work at all, so I used the master branch with SDL1, but I read that SDL2 is supported as well, so I may try to get that working too.
Pretty awesome stuff, thanks for the explanation. I had heard about it and asm.js, but it's the first I see something out of it.
Post Reply