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:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

The number it gave was 0 (with no other context I thought it may have been a stylized period).

I assume that Emscripten can compile any C/C++ code, since it is just a compiler that has a different backend, but I didn't look into how the file reading code works. PetitFS is just code, so it should compile, but I didn't look to see if under the hood Uzem builds an actual SD image that can be read and traversed using raw SD reading commands. Given a directory of files, that should be fairly trivial (on Linux at least) by creating a loopback filesystem, formatting it as FAT16, then copying the files into that directory. And then any raw reading commands could look at that image exactly as if it was a real SD card assuming we actually emulate raw SD card commands.
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:Awesome!!! :D That's a big thing. When announcing a game, folks will be able to play it on the spot in their browser. Really cool.
:D

I did put a Web-based Emulator section on the wiki page for Bugz, but playing it well is highly dependent on the processor and video card.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

I'm looking for feedback from people with older computers, and from people who have Firefox and/or Chrome installed on their phones. This doesn't run 100% on my 3 year old phone, but it's the fastest I've seen it run on my phone so far.

http://uzebox.net/bugz-lock-texture/uzem.html

It is based off Jubatian's linebuffer branch, but all of the scaling is done on the GPU. This version doesn't render to a SDL_Surface at all, internally it renders directly to the linebuffer every 1820 clocks, so there are fewer conditionals for the pixel rendering in the main loop, and then after each scanline is finished it applies the palette as it copies the first 1440 pixels of that scanline into part of the backbuffer of a 1440x224 pixel texture, and then when all scanlines are finished rendering, it locks the texture to flip its front and back buffer and begins the process again.

Edit: Using that version compiled natively with vsync disabled, and the

Code: Select all

while (audioRing.isFull())SDL_Delay(1);
commented out so it runs as fast as it can, I can record videos (sending ffmpeg the full 1440x224 buffer, and the raw audio sample) while I'm playing the game at a constant 36 MHz emulation speed on my 5 year old laptop. :D
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Jubatian »

On my aging computer (2.2GHz Core 2 Duo) it is a bit slow, but playable, so I guess as long as there is no music, it goes well enough to get some of the look and feel. Maybe I would be able to finish level one at once... :p (Damn, I am miserable at platformers).

As a suggestion maybe you should also compile one without any graphics output, just showing the achieved processor emulation speed, and upload that to some testing site. We could then compare how much the graphics output matters on various computers / browsers, and how much the AVR emulation (of course then make the megahertz output visible somewhere on the original as well), which would be good in the long run to figure out what kind of rendering method works best for Emscripten.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

Jubatian wrote:On my aging computer (2.2GHz Core 2 Duo) it is a bit slow, but playable, so I guess as long as there is no music, it goes well enough to get some of the look and feel. Maybe I would be able to finish level one at once... :p (Damn, I am miserable at platformers).

As a suggestion maybe you should also compile one without any graphics output, just showing the achieved processor emulation speed, and upload that to some testing site. We could then compare how much the graphics output matters on various computers / browsers, and how much the AVR emulation (of course then make the megahertz output visible somewhere on the original as well), which would be good in the long run to figure out what kind of rendering method works best for Emscripten.
Cool.

I still need to figure out how to get it to measure time. When I try to do it the normal way it hangs the browser. I imagine that I'll need to call into JavaScript for that.

BTW: Uze, I submitted a pull request to officially add Emscripten support, so I don't have to keep making these changes to every build/branch that I test. It's all conditionalized and disabled by default, but it allows me to build a native version and an Emscripten version from the same set of source code, just by uncommenting a line in the Makefile :D

Edit: Here is a version that can measure the speed, but it's tricky, because when I limit the speed to 60fps, it runs as fast as it can for 1M clock cycles, and then not at all until the next 1/60th of a second, and then it runs as fast as it can for another 1M clocks. I had to average it out over 100 calls to my "one_iter" function, and then it gave me a good number. That could also be why the sounds are funny sometimes. I don't know of any other way to limit the speed that doesn't lock up the browser, and if I tell it to only run for 28636360/60 cycles ever 1/60th of a second, it runs way slower than it should, because that doesn't take into the account the time that the browser spends doing other things.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem ported to HTML5/JavaScript

Post by D3thAdd3r »

On Firefox I am hitting ~27.2Mhz, whereas this same laptop could only run the native 1.19 at best case maybe 24mhz. With Chrome I am getting about 21.5mhz. So on Firefox it is quite playable on a slow PC with what you just posted. I do notice that the sound appears to have noticeable latency which I'd guess to be around 150-200ms, which I don't recall in the previous versions. Of course I just tried refreshing the page and it's gone now.
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:On Firefox I am hitting ~27.2Mhz, whereas this same laptop could only run the native 1.19 at best case maybe 24mhz. With Chrome I am getting about 21.5mhz. So on Firefox it is quite playable on a slow PC with what you just posted. I do notice that the sound appears to have noticeable latency which I'd guess to be around 150-200ms, which I don't recall in the previous versions. Of course I just tried refreshing the page and it's gone now.
Wait, the web version runs faster than the native version!? That doesn't sound right.

Switch to the uzem140 branch with:

Code: Select all

git checkout uzem140
And then make sure you edit your Makefile and uncomment just the:

Code: Select all

ARCH=native
line, and change the RELEASE_CPPFLAGS line to:

Code: Select all

RELEASE_CPPFLAGS = $(CPPFLAGS) -Ofast -flto -fwhole-program
then do a make clean, followed by a make.

The web version is doing link-time optimization, and there is a further optimization pass being done at the JavaScript level, but the native version should always be faster.

Edit: Added the most important thing; make sure you are compiling from the uzem140 branch.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem ported to HTML5/JavaScript

Post by D3thAdd3r »

No I have yet to install SDL2, I was comparing speeds to the prior version I compiled on MinGW (uzem 1.19). With the web version that fast, I think 1.4 will run full speed natively; which would be anazing because I can actually do music/sound on my laptop.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to HTML5/JavaScript

Post by Artcfox »

After fixing some undefined behavior in SDEmulator.cpp, I am now able to successfully play games that use the SD card in the web-version of Uzem.

The music is a bit taxing on the processor, and I had to overcome some memory hurdles that didn't pop up until I uploaded it to a remote server, but I finally have Alter Ego working!
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem ported to HTML5/JavaScript

Post by D3thAdd3r »

You have this thing beat, wow.

Works perfect on my PC. On my phone using firefox or the generic builtin browser it throws an exception and wont run for whatever reason.
Post Reply