Emscripten port, for running in web browsers

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Emscripten port, for running in web browsers

Postby dreamlayers » 2014-1-24 @ 18:42

I've been working on an Emscripten port of DOSBox. I started a branch from the SVN revision closest to 0.74. It is published as the em-dosbox-0.74 branch at my em-dosbox repository on GitHub.

I wouldn't call it complete, but it runs many games well in Firefox. Chrome's JavaScript interpreter runs asm.js more slowly, but it can still run many real mode games with only minor sound glitches. Here are some demos:
The biggest difficulty when porting to Emscripten is that you must return control to the browser for the page to be updated. If you don't return control, Firefox freezes. There isn't any function you can call to accomplish this. (SDL_Delay() and usleep() will just busy wait.) My port uses a simple hack, causing the second DOSBOX_RunMachine() call to set up the Emscripten main loop. So, you can run mount once to gain access to files, and then you can run the desired executable via the main loop. The shell still cannot be used interactively. The src/packager.py script can create the files needed to run games. It's not ideal, but it can run a lot of things, even Windows 3.1. The possibility of DOSBOX_RunMachine() nesting makes a proper solution tricky.

The port also includes a Python script which transforms the CPU cores, using an array of function pointers instead of the main switch statement, with cases transformed into functions. This runs a lot faster in Chrome, because it can't optimize large switch statements. It even seems to run a bit faster in Firefox.

More information is available in README.md on GitHub.
dreamlayers
Newbie
 
Posts: 6
Joined: 2014-1-22 @ 18:57

Re: Emscripten port, for running in web browsers

Postby danoon » 2014-1-24 @ 22:30

I take it that this is with the normal core. Performance isn't as bad as I would have thought with the normal core. I wonder if would be possible to output something to asm.js with a js dynamic core.
danoon
Member
 
Posts: 111
Joined: 2011-1-04 @ 19:12

Re: Emscripten port, for running in web browsers

Postby dreamlayers » 2014-1-25 @ 18:01

This is with core=simple, so running the simple core unless there was a need to switch to the normal core. I set it up this way earlier, when the port was much slower due to Emscripten bugs. It's still this way because I don't see any disadvantages compared to starting with the normal core.

I've thought a bit about dynamic recompilation, but I haven't done any work with that. It's certainly possible, though asm.js makes it a bit tricky. Code needs to be packaged in asm.js modules, which are basically functions which get compiled and return one or more asm.js functions you can actually use. Once a module has been compiled, there doesn't seem to be any way to make changes to its code, but it's possible to produce new modules.
dreamlayers
Newbie
 
Posts: 6
Joined: 2014-1-22 @ 18:57

Re: Emscripten port, for running in web browsers

Postby koun » 2014-2-09 @ 22:48

Impressive. Works nicely, even on some mobile devices.
I am, however, wondering why it is necessary to have a custom packaging system instead of, e.g., zip.
koun
Newbie
 
Posts: 29
Joined: 2004-2-11 @ 19:59

Re: Emscripten port, for running in web browsers

Postby dreamlayers » 2014-2-10 @ 03:45

The packager uses the system used by Emscripten, the compiler used in this port. The custom part is really only a wrapper around the Emscripten packager which makes it easier to use in this application. It also adds command line arguments that make DOSBox run the game automatically.

I realize that zip would be even easier to use, and it has the advantage of not requiring Python or Emscripten to be installed. I will take a look at what's needed to add this support.
dreamlayers
Newbie
 
Posts: 6
Joined: 2014-1-22 @ 18:57

Re: Emscripten port, for running in web browsers

Postby koun » 2014-2-10 @ 22:52

I didn't know Emscripten has its own package format, but it makes sense as it has to fake a file-system. (I never used Emscripten, but porting Java to JS via GWT has similar characteristics, especially the need to replace the main loop with timeouts to let the browser update and repaint.) IMHO zips containing an "autoexec.bat" in the root would be the easiest way possible. I think there is a zip-mount patch for Dosbox that might contain the required functionality (if it does not just call a compiled zip lib).
Comparing the performance of the demos on different systems (incl. mobile devices) and in different browsers is quite interesting. Could you please add a Doom 'timedemo' to your demos for benchmarking?
koun
Newbie
 
Posts: 29
Joined: 2004-2-11 @ 19:59

Re: Emscripten port, for running in web browsers

Postby koun » 2014-2-18 @ 18:40

I managed to get Emscripten (more or less) working on my Windows machine and am now able to package software for dosbox.js. I haven't tried much, yet, but I'm really impressed.

However, I got one thing that I really hope can be fixed: After the program you run finishes, in most cases, the output to the console is not visible. So many benchmarks are unusable, because I cannot read the result. It would be great if the output to the command prompt right after the program closes would be/stay visible. Alternatively it would be cool if stdout and stderr could be piped out of Dosbox, but I don't know if Dosbox has any way to do this.

I also made a script that changes the aspect ratio of the canvas to the (to my knowledge) correct 4:3, increases the canvas size if there is room and fixes full screen for both Firefox (right AR) and Chrome (actually increased size). (I guess the full screen fix actually belongs into Emscripen itself.) You can try it out by adding the following at the end of the head of the HTML generated by the packager.

Code: Select all
<script>
   window.onload = function() {
      // ensure correct 4:3 aspect ratio (height 480 instead of 400) and increase size if browser view port is large enough
      var cs = document.createElement("Style");
      cs.appendChild(document.createTextNode(window.innerHeight < 850 ? "#canvas { width: 640px; height: 480px }" : "#canvas { width: 800px; height: 600px }"));
      document.head.appendChild(cs);
      
      // ensure correct full screen size and aspect ratio
      var canEl = document.getElementById("canvas");
      var reqFuncName = (canEl.mozRequestFullScreen || canEl.webkitRequestFullScreen || {"name": "requestFullScreen"}).name;
      document.addEventListener(reqFuncName.slice(0, -"requestFullScreen".length) + "fullscreenchange", function (evt) {
         if(document.mozFullScreen || document.webkitIsFullScreen || document.fullScreen || document.isFullScreen) {
            var w = canEl.clientWidth;
            var h = canEl.clientHeight;
            var factor = Math.min(screen.width / w, screen.height / h);
            canEl.setAttribute("style", "width: " + Math.round(w * factor) + "px !important; height: " + Math.round(h * factor) + "px !important;");
         } else {
            canEl.removeAttribute("style");
         }
      }, false);
      // in Firefox full screen must be set to the parent of the canvas to allow resizing the canvas for correct aspect ratio
      if(reqFuncName == "mozRequestFullScreen") {
         canEl[reqFuncName] = function() {
            this.parentNode[reqFuncName].apply(this.parentNode, arguments);
         };
      }
   }
</script>
koun
Newbie
 
Posts: 29
Joined: 2004-2-11 @ 19:59

Re: Emscripten port, for running in web browsers

Postby divinity » 2014-5-19 @ 17:40

Hi,

i also managed to get EMDosbox to work with Emscripten on my Ubuntu machine. I also implemented IPX (UDP) with SDL_net-1.2.8 which seems to work
because i can see the "NETWORK" option in Command & Conquer DOS version. This only happens when IPX is available. (at least i think so)
The only problem is that i cannot start the Server or connect to it because the command line seems not to work. ("IPXNET STARTSERVER", "IPXNET CONNECT x.x.x.x")
I tried to write a simple Programm which executes IPXNET STARTSERVER but it crashes at "IPX Tunneling utility for DosBox". (use "Z:\IPXNET.COM STARTSERVER" because it does not find the command IPXNET on C:\)

The implementation was VERY simple. I compiled SDL_net-1.2.8 source code with Emscripten, added libSDL_net.a to the Dependecies and put SDL_net.h into the include folder. :)
Also enabled the C_IPX variable in config.h. And i have SOCKET_WEBRTC=1 enabled (don't know if this is required).

Here is my dosbox.js build: (don't forget to add a dosbox.conf with IPX=true)
http://www.mediafire.com/download/439dn ... box.js.zip

Is there a way to IPX connect in current EM-Dosbox and does it REALLY work with my simple SDL_net implementation?

EDIT:
Descent 2 DEMO IPX
http://www.divinity.x10.bz/d2demo/d2demo.html ~14MB Download
You CAN go to Multiplayer IPX but noone is connected... - i assume IPX works
divinity
Newbie
 
Posts: 23
Joined: 2006-8-04 @ 14:41

Re: Emscripten port, for running in web browsers

Postby divinity » 2014-8-24 @ 12:30

EMFastDosbox

I recently played around with EMDosbox and i merged Fastdosbox 1.6 successfully into the source code.
The Audio of the Games is now very clean and it runs about 15% faster then the old code. For some reason only Firefox works, other Browsers i've tested are very slow. Maybe i can fix this in a future release.
some examples:
http://www.divinity.x10.bz/emscripten/descent1.html
http://www.divinity.x10.bz/emscripten/doom1.html
http://www.divinity.x10.bz/emscripten/duke3d.html
http://www.divinity.x10.bz/emscripten/raptor.html

On my Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz Descent1 is nearby playable and Duke3D is fully playable.

Old EMDosbox version as comparison:
http://www.divinity.x10.bz/emscripten/old/descent1.html
http://www.divinity.x10.bz/emscripten/old/duke3d.html

I use EMScripten 1.18.4 and LLVM 3.4 http://llvm.org/ I've tried newer versions but these are the latest working ones.
here is the code:
http://www.mediafire.com/download/bj5a4 ... dosbox.zip

For my last post i could not get IPX/UDP working.
Attachments
em-fastdosbox.zip
(1.24 MiB) Downloaded 146 times
divinity
Newbie
 
Posts: 23
Joined: 2006-8-04 @ 14:41

Re: Emscripten port, for running in web browsers

Postby mr_bigmouth_502 » 2014-8-24 @ 21:11

I just played a bit of Doom from the link in the OP, and it's pretty playable with my Core i5 540m @ 2.53GHz (turbo @ ~2.9GHz according to HWiNFO64), though I turned down the screen size a notch and enabled low graphical detail. It would still run into a few really choppy spots for about a half second when loading an area with a lot of graphical details. Overall, it reminds me of playing on a slow 486, maybe a fast 386 though I've never tried it on such.

One thing I wonder, is DropBox OK with people using it to host webpages? I kind of have this feeling that it isn't. XD
My NEW(ish) desktop:
Image
User avatar
mr_bigmouth_502
Oldbie
 
Posts: 1825
Joined: 2009-5-16 @ 19:43
Location: Canada

Re: Emscripten port, for running in web browsers

Postby koun » 2014-9-02 @ 23:10

Nice. It's really cool to see someone still working on this.

If I could make a small suggestion: The aspect ratio of the output should be corrected to 4:3.
You can use the 'forcedAspectRatio' member of the Emscript 'Module' object for that:
Code: Select all
Module['forcedAspectRatio'] = 4 / 3;
koun
Newbie
 
Posts: 29
Joined: 2004-2-11 @ 19:59

Re: Emscripten port, for running in web browsers

Postby BenMcLean » 2015-11-05 @ 22:47

For any noobs trying to copy this real quick without building yourself from source (like people on Windows) here's what you need to do:

  • Grab any one of the html files in the original post of this thread and rename it template.html.
  • Blatantly steal dosbox.js and dosbox-old.js from the original post.
  • Download EM-DOSBOX and use the repackager like it says here from that template.html
  • So in the end, you'll be uploading four files to your web page: yourgame.html, yourgame.data, dosbox.js and dosbox-old.js
Be aware that you will probably need to use some kind of server to test this (like the python SimpleHTTPServer) since, for security reasons, browsers don't like to let local files access other local files.

I got my old game running this way! ^_^

I would like to get it running in that faster version of EM-DOSBOX but it didn't come with a repackager. :(
BenMcLean
Newbie
 
Posts: 1
Joined: 2015-11-05 @ 22:06


Return to DOSBox Development

Who is online

Users browsing this forum: istellabot [Bot] and 3 guests