Hi! I am the guy who did this port. I am very sorry for long download times, but the HN/Twitter buzz was unexpected and the host server - a cheap shared hosting I barely use just for testing purposes - is currently crying very hard. Oops...

Also, download code is dumb for now, it is downloading one big full .pk4 file (400MB) for each visitor loading the app. I know, it should be better to only preload necessary assets for sure! Smart streaming of game data is one necessary step for apps on the web.

Have you considered webtorrent or IPFS for distributing the file? Webtorrent in particular looks very easy to setup, and then the most your server would ever have to handle is the equivalent of a single downloader.

I think it would be better to stream only needed data, using some lazy load mechanism. Still need to figure out what is the best approach

That's definitely the more permanent solution for games like this. I was thinking more along the lines of quickly solving the immediate problem so you don't have to spend more money on a different server. I wouldn't be surprised if you could replace the download with a webtorrent in less than an hour of work and be done with it.

I wonder if you could utilize IPFS as a distributed CDN for p2p file downloading to take some load off the server (assuming the .pk4 is static and stateless)

Excellent job! I wanted to run the native copy for comparison, but it turns out you added support for the demo files yourself! Gah!

What would you guess you could get the bundle size down to if you were to preload only the required assets? I think a lot of us are curious as to how load-time performant webassembly games like this could eventually become.

Once this stuff stabilizes a bit, games wrapped up as progressive web apps might become a thing. Could be an interesting way to get distribution outside of the app stores via regular search engines for a lot of indie developers using e.g. unity. Also a nice way for mainstream game developers to show of demos without requiring cumbersome installations, lengthy detours via some app store, etc.

I hope you're right. We've had this capability for quite some time but for some reason it never takes off. Bastion released a version for Chrome's native client 7 years ago, the game ran amazingly well, but that version of the game doesn't seem to exist anymore. NaCl was shut down in favor of webassembly so here's hoping.

[1] https://kotaku.com/5866594/you-can-now-play-bastion-in-googl...

[2] https://www.youtube.com/watch?v=MvKEomoiKBA

On the other hand i hope he's wrong because that means games can die at the whim of whoever hosts the servers (they already have tons of issues with DRM and such). Personally i prefer to have control over when and where the games (and other software) i have are installed and i prefer to buy games from GOG and other DRM-free places (that give me an offline installer i can place on my external hard drive) whenever possible, but comparing the popularity between GOG and Steam with developers and publishers tells me that if the option for them to take even more control away from the consumers is there, the vast majority of them will go full on it.

This loss of control over the software i use is my main annoyance by far as a user when it comes to the trend of pushing everything as a web app.

Oh, I completely agree with your sentiment but I don't think that means it has to be hosted remotely. No reason you shouldn't be able to download a packaged web binary to run locally. I wonder if webassembly supports that notion or not?

>I wonder if webassembly supports that notion or not?

It does[0]. It's just a spec for a bytecode, and it's designed with the intent of being run in the browser and natively.

[0]https://webassembly.org/docs/non-web/

There isn't really a reason to offer a game as a web application if the goal isn't to have it run inside the web browser though. As i wrote in the other reply, i'm not worried about the best thing to do that is technically possible with the method, but what is the most likely to happen (assuming publishing games as web applications take off in the first place, of course).

Assuming the game had no server component beyond the distribution itself (i.e. no online multiplayer or similar) there's no reason you couldn't just save the distributed files and open them in an appropriate client (namely wasm-friendly browsers as of right now).

Web applications can be packaged for offline use.

It’d be cool if browsers let you back up local copies of sites though.

How many web applications do you know that do that, especially compared to those that do not? I'm not worried about what is the best one can do, but what is the most likely.

NaCl was not cross platform and not standardized the same way that Web Assembly is.

Web Assembly blew up very fast because it's minimalistic design makes it easy to agree on and implement on top of browsers.

Web Assembly also does not expose browser vendors to Intel’s patent portfolio.

Isn't the problem with browser gaming the size of game assets? Any sizable game with sound and high-res textures could easily span multiple gigabytes (AAA games now approach 100 GB in size). The browser would have to enable persistent store at that scale to make that kind of gaming feasible. The alternative is server-rendering+streaming, but this doesn't need WebAssembly.

One problem is the paradigm of the browser and the expectations behind it. Websites are intended to load in a second, or at worse, a few seconds, so waiting any longer for an entire application would be excruciating.

But no one minds downloading a multi-megabyte or gigabyte game over Steam or console, because users are trained to expect that to take a while.

So what's needed, in my mind, is something with a user experience between the two - for games and applications to run in something more akin to a "package manager" mode than a basic browser window. Or maybe, on the web, have some alternative content to distract the user while the content downloads.

The size of the entire download could possibly be reduced by having browsers ship with some standard plugins and modules, maybe runtimes (imagine having most of the Unity framework already in the browser.)

> So what's needed, in my mind, is something with a user experience between the two - for games and applications to run in something more akin to a "package manager" mode than a basic browser window.

Maybe, just maybe, they could not run in a browser window.

I could easily imagine a dedicated tab for "applications" that served as a download manager (something like the old Downthemall plugin) that would launch a game from the browser, but not in the browser.

You could keep all the benefits of URLs and the web, but not have to actually tie the browser down with executing in a webpage.

This is the 90s all over again! Something very like this once existed for Java games. It was called Castanet. IIRC, the website ClassicGames.com (later acquired by Yahoo) used this before broadband really took off.

http://mindprod.com/jgloss/castanet.html

The application could be split into pieces. Most game content is not going to be needed for many hours from you starting the game, so why wait for it to be downloaded? You likely can download >100mb while you show the credit screens in an AAA game.

Steam actually offers the option to start playing before the download is complete on a few titles (not everything supports it)

There are AAA games that somehow allow you to play before downloading is finished. Notably battlefield i was allowed to play single missions and tutorial why the game was being downloaded in the background.

The history of the web is one of centralization not decentralization.

Steam is already a very good solution for distributing PC games and it has the added benefit of implementing a payment model, DLC features, social capabilities, updates, cloud-synchronized saved games, and, perhaps most importantly, a discovery service for finding new games. It even supports automatic WINE mode for windows-only games in linux (a feature that surprised me).

I welcome the day when more games run automatically in OSX or Linux, but I think the need for an app platform isn't going to go away. And as someone who plays games often offline (on a plane or sometimes the train) it's really nice to not require an internet connection to play something.

Sure, but.. it does require downloading steam, which is a huge barrier to entry. As someone who's not a gamer, I've never downloaded Steam, which bars me from being exposed to all of it's content. That barrier also probably prohibits non-gamers such as myself from becoming ultra casual gamers. I'm sure the content is incredible, and I'd probably find it addicting. But heck, I can't be bothered into downloading steam.

I'd be interested to see how landing on a webpage with a game ready-to-go turns non-gamers such as myself into infrequent or even frequent gamers.

I would also argue that the ubiquity of the web is what makes games like agar.io and slither.io so popular, especially for kids. I remember being at techshop in SF and seeing kids rushing straight to their computers after school and opening slither.io and playing instantly. No friction. I'm sure that lends to their success.

The web is great!

You land on the webpage. Now enter all your payment info, validate purchase, make account. Cool

Or is it f2p? So you land on page, still need to make an account for persistence. Also will need to do credit card eventually for game developer to make money. Also now game developer is looking at cdn costs of over 500 a month at a minimum for any kind of real game that is even 0.5 gb in size.

I actually own a web assembly f2p game like this. It is really not a bright future for games that compete with real client games on steam that are not tiny and have the barest performance requirements.

With unity basically the entire game needs to fit in like ~512 mb of ram, and runs poorly.

Or, you can create an account after investing a few hours or so into the game, at which point a bit of friction is irrelevant. And sure, the credit card details will have to be entered eventually, but again, you'll be very invested at that point, so a bit of friction doesn't matter.

Regarding the CDN costs, with some very aggressive caching (Service Workers and stuff), is it really that much worse than a downloaded game? You're the one who actually has a game, though, so I guess there really is a problem here.

You don’t pay for the bandwidth to download a game on steam.

That's a good point, although I'd guess that Steam's 30% cut should more than cover it.

Depends how successful your game is, the price per copy, and how big it is.

you're advocating for captive audience pre-installed appstores not the web

The history of the web is circular. The history of Google is that they replaced a walled garden (Yahoo was a glorified yellow pages type catalogue for webpages) with search that worked for the whole web. Yahoo is no more. Their catalogue got replaced by a search box.

Steam is kind of a nice walled garden. The problem is that it's not the only one and that there is loads of stuff outside their walls. There's the Apple store, the Google store, the Amazon store. And that's just mobile.

A few things these stores have in common: - pay to play: they all heavily promote games that pay to be promoted. This favors games with big budgets and is a monetization problem for smaller players; like indie games. - censorship and conflicts of interest between application/game developers are a problem regularly result in applications being blocked/removed for all sorts of reasons that boil down to arbitrary restrictions imposed by the store owner. - extortion rates on monetization, in app purchases, subscriptions, etc. make being there costly. - search is a problem. Even Google's search in the appstore is comparatively shit. I regularly resort to using their web search to find apps I know definitely exist in their app store. Apples store is a maze of misdirection. Their search is shit. - Getting into the store requires a non trivial amount of work and in some cases entrance fees.

PWAs fix the distribution problem and remove app stores as a necessity for that. Google, Duck Duck go, already take care of the discovery problem better than most app stores and in any case people discover things via social media, friend referrals, etc. Being featured in the top 20 of the IOS app store is not a feasible thing for most developers. Also, browsers already keep us safe so we don't need to rely on app store screening any more.

So, time to tear down those walls once more.

The history of walled gardens is that eventually somebody climbs over the wall and figures out there is a world beyond. Biblical stuff even, if you are into that ;-).

I think the problem is that nobody wants to go manually find games across the web, then maintain a bookmark list of their games, share purchasing info with 100 different sites, throw away a central liaison for customer support/community/developer interaction. Centralized repositories are way more useful and convenient and manageable. Now you could still do a central repo of webasm games but if anything I could see Steam offering a WebAssembly portal or something.

I remember the glory days of flash games. Miniclip.com had some fun ones, and there were a bunch of sites.

Newgrounds.com, addictinggames.com, and kongregate.com are the three I remember. RIP Flash and Shockwave

This makes me wonder what all the video streaming sites are thinking. I've got Amazon Prime and NetFlix and I stauchly refuse to add anything to that because it's too inconvenient.

Then again, they're consolidating faster than the T-1000 in the foundry.

I had the same gripes, I use justwatch.com to search for a movie and see what streaming platforms offer it. Roku global search also does the same thing.

Ideally you wouldn’t have to go looking. You’d see a gameplay GIF on Twitter, click a link and 100ms later you’d be playing the game.

So we've come full circle - take a native game, run it in a browser, package it with Electron, and pretend it's a native game?

I'm not claiming it makes much sense, but it's better than having to download all the files every time you want to play a game built for browsers.

I tried to check it out, but it was taking forever to load. Downloading the assets at only ~500 KBps on a 150 Mbps link. Also only got maybe 10% through the download before I gave up, and the Chrome tab was already using 500 MB of RAM.

This might be an interesting POC, but seems very impractical in reality.

This website might just be getting the HN hug of death if it can’t even serve you the game at full speed. It doesn’t seem like it’s related to how practical it is.

Yeah, seems likely. I'll have to come back and check this out later.

I recently found my Doom 3 CDs and tried installing it on Win10, but apparently doesn't work out of the box on 64-bit (crashes at start) without manually patching for using > 2 GB of RAM from the cursory googling I did.

If this does work later, will have to show it to my 11 year old step son. Was hoping to freak him out with Doom 3 when I found my disks (he loves shooters & scary movies, so thought he might get a kick out of it).

You can also get a Doom 3 Steam key right now from several places for less than $2.

That's the BFG Edition, though, which, in my opinion, isn't nearly as good as the original. I liked the dynamic of needing to use the flashlight and some of the other tweaks made to the BFG edition ruin the feel of the game a little. That being said, it did also make some improvements but to each their own.

I believe Steam has both editions. There are certainly different store entries for "Doom 3" and "Doom 3: BFG Edition".

You are correct! I didn't realize you could get the original edition on Steam. It wasn't on there for a while.

Sidenote: The Doom 3 BFG edition also gives you the original Doom games although they've been nerfed a little from the original. (e.g., the stimpacks no longer have the little crosses on them because of a lawsuit from the Red Cross)

Even though its a mere $2, on the principle of the matter, I dont want to pay it as I still have my original CDs, plus the expansion.

Yeah, it loaded in about a minute when I found it.

Local HN submitter ruins everything :(

For those waiting and wondering, it's a ~370mb download

Which makes absolutely no sense for distributing games, unless they can be saved to a reliable location that can be managed by the user.

Why doesn't it make sense? You don't redownload it every time.

Yes you do, if your browser cache gets removed then so does the game.

You don't redownload it every time. If your browser cache gets removed then so does the game. Is your browser cache getting removed every time? This just strikes me as a really strange thing to say.

Yes it does get cleared frequently because it is not part of my standard file system.

It might help to put the assets on one of those mirroring CDNs, or to implement some lazy loading scheme (assuming they are loading all assets for all levels at once currently).

This demo doesn't include shaders, it's mostly just polygons and textures and lightmaps. It was the shaders which made the game impressive back then. However, for a port to WebAssembly it's really a big deal.

To think, those were the old fixed pipeline ARB-style shaders, too. I still have trouble with games using those on modern cards.

As I recall it was the dynamic lighting that made it impressive.

https://en.wikipedia.org/wiki/Shadow_volume

Only thing we need now is presentation/distribution. Download this stuff one time for the machine as a standalone progressive hybrid native/web app, and run as an exe from there on. With auto updates. No browser involved. HTML5 games don't take off because of the presentation/distribution. The browser is the problem. Now that we have WebAssembly, performance is much less of a problem.

I absolutely disagree.

The browser is the solution to the presentation/distribution problem. I don't need to worry about installing the game, or worry about what OS I'm on or where it was installed to or anything else.

I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves.

no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular.

> I don't need to worry about installing the game, or worry about what OS I'm on or where it was installed to or anything else.

Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper.

>I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves.

This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that.

>no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular.

Except the browser is the "launcher" and the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.

>Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper.

I agree, except for the magnitude difference in time required in most cases.

A web-app that takes more than 10 seconds to load is consitered broken to many. A desktop app that can go from "discovery" to "using" in less than a minute is consitered fantastic. Plus then there are update headaches.

I genuinely believe one of the major reasons why the web is taking over is because every other platform makes the process of "installing" code such a difficult slow process.

Not to mention the security issues with giving code access to desktop systems which traditionally are difficult for the average user to secure. And the fact that I don't ever think i've had a piece of installed software ever completely "uninstall" itself correctly. They always leave stuff behind. In a browser, a single "clear browsing data for this domain" gets rid of all of it, entirely.

>This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that.

But you do. Some platforms (like iOS) don't allow distribution over any methods other than their app store, or a browser. Still more heavily discourage distribution over HTTP (most linux distros). And most users will download the "installer" for a game via a browser in the extreme vast majority of cases, so why not cut out the middleman and just allow the game to be playable in a browser?

There are also other benefits of a web-platform game, like the ability to "deeplink" inside the app. I can not only share a link to the game, but can easily share a link to a specific screen in the game, or can share a link to allow you to connect to my game. And that whole process is crawl-able for search engines, and easy to implement. Sure, it's possible to do with desktop software, but it's much harder in most cases, especially when you throw cross-platform into the mix.

>...the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.

While of course a specific site can act as a gatekeeper, that's not what I was talking about. Time and time again we see stories about how Apple removed some app from the app store, or some company pulls their subscriptions from being allowed to sign-up on iOS devices, or how some game makes their own app-store to get around the limitations on android, or even how most "app stores" don't allow adult content.

That is the kind of stuff that the web-as-a-platform gets you away from. You aren't going to have Google removing your app because it's too adult, or Apple charging you a 30% fee for all subscriptions made on their platform.

I'm all for streamlining this process to allow users like yourself that want a "local install" to get it, but I don't think we should throw the baby out with the bathwater here. Browsers give us a shitload of benefits, and the discovery and "install" process (or the lack of) is second to none. I think we can work with those benefits, and give users and developers the options needed for other formats if they want.

For example, The microsoft store has started allowing PWAs to be listed, browsers could work with the OS and define some APIs that allow you to choose where to "install" a PWA or web game, possibly even allowing you to simply move it or uninstall it after the automatic "install" happens.

We are finally getting away from the days where it would take tens of minutes to download and install software on a computer, where it would require you to give a considerable amount of trust to that software once you run it, and making it really hard to share content within apps with others. I don't see why you would want to go back.

But now that I said all of that, I realized that I don't really know why someone would want to not have it. So I guess my question is why do you want a traditionally "installable" code? Is there something I'm missing here, or some assumption that one of us is making that is getting rolled in with this conversation?

I believe webassembly offers the opportunity to democratize and decentralize software, but I don't believe that can happen as long as "web applications" remain in the browser, or as long as runtimes are tied to specific languages or platforms (as with java and flash.) I want the line between "native" and "web" to be eliminated as much as possible, so that every application has a URL and can be run from there in a browser and installed natively from it.

>I think we can work with those benefits, and give users and developers the options needed for other formats if they want.

That's literally what I'm advocating. Not getting rid of webassembly applications in the browser, but also having native runtimes that are optimized for running the same webassembly applications.

Every benefit that the browser as application model provides could improve the way native applications work as well - there could literally just be a button or an option in the browser to "install as native" and the Webassembly binary in the browser could just be copied somewhere, maybe with some metadata, and an icon generated for the desktop. Native runtimes could sandbox them just as a browser might, and the uninstallation process need be not much more complex than dumping a cache or deleting a folder.

Ah, so it sounds like we are on the same page, but just call it different things. (what you call a native runtime I call a browser with some UI differences)

Your last paragraph basically describes a browser with a special "install" flow. Mobile Chrome already has a flow like that for PWAs where it will ask you "do you want to add this to the home screen?" and it will add the icon to your app drawer on android just like any other app, allow you to "uninstall" it just like any other app, and when you launch it it launches fullscreen just like any other app.

I'd love to see this expanded to cover desktop as well. And with some additional work (like giving the option to move storage data to different drives or manage apps based on their hostname more easily), it could become a very powerful system.

If you want to learn more, take a look at the google developers page for PWAs. It seems to be what you are looking for in some ways!

https://developers.google.com/web/progressive-web-apps/

Couldn't have said it better myself.

I disagree. But I understand your view. The thing is I don't want the game running IN the browser. I want it running standalone, but being web enabled and having the facilites it provides.

What? If it isn't in the browser, what's the difference between that and something you download on Steam?

For the user almost none. The difference is for the devs. If I want to make a cross platform game now, I have to worry about which Graphics api I will use, OpenGL, Direct3D, Vulkan etc. What sound api I will use. What Display, Input, abstraction I will use. Etc. If I could have a unified api and runtime abstracting all that already for me, making full cross platform games would be easier, assuming I don't want to use Unity. But that is of a much bigger scope that just WebAssembly. We already have that power, but we are chained to the browser. The discussion is to free that runtime from the scope of the browser. Decouple it.

The final dream is having a unified, Desktop, Consoles (Ps4 and Switch) and Browser runtime with a unified API (where sensible). One can dream.

One does not simply develop cross-browser. Different browsers have different issues with different graphics cards. As soon as you're not drawing a textured triangle anymore, things get hairy. Same for the audio API. And don't get me started on the sad state of WebRTC and websockets.

Yes, it's just not viable to develop for browsers unless you have the maintenance budget for a moving target. I decided on that after living through the Flash era and trying HTML5 for a little while. The browser is backwards compatible only for certain kinds of applications.

Well, yeah. I agree. You escape from several problems in native environments and find another several in the web.

That's the thing. You don't escape from those problems in native environments. You still have to deal with different GFX drivers doing different crap on different platforms, cards that they that support a GL extension but don't, etc. And that's just OpenGL.

With the browser, you're just adding another abstraction layer that has even more complexity. WebGL is far for a decent spec. And we're talking just graphics, as I mentioned before, audio and networking have tons of unstable and untested code.

Multimedia programming is already hard on native environments. I don't see the web being a friendly environment anytime soon. There's no silver bullet, "code once, run anywhere" for games and multimedia.

The WASM folks have plans to deepen the browser ties with direct DOM access, tying threads to webworkers, GC that's tied to the browser js, etc. I can see why you want what you do, but it will get harder over time.

That's not quite true. They intend to create a way of interfacing with ANY GC which would then allow them to make APIs that call in to the DOM. None of this would tie it directly to browsers. The whole intent is to keep it platform-agnostic, last I heard.

> An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment.

https://github.com/WebAssembly/proposals/issues/16

That's encouraging. As far as I can tell, threading is currently webworker centric.

Unfortunate.

Why would it download the 400mb every time you run the game? There are caching and storage APIs in the browser. It's possible that there are some more controls needed for both the user and the site author over this storage space, but that's definitely not a fundamental impediment.

I'm unsure if browsers will cache 400mb from a single site in a single file. Also, where are you going to cache it... all of said APIs would have to request to expand local storage interface... which may not be bad.

indexedDB can easily store gigabytes of data without issue. I've personally used it to do so before, and it will happily "cache" it for weeks at a time. There are several web apps which work entirely offline and cache all of their data using that API.

devdocs.io is one of them.

Like the parent commenter said, i'd welcome more control over the storage of that data, but it absolutely can and will cache large blobs like that.

Actually, indexedDB is used to cache/store the whole .pk4, but using small chunks of data (50MB or so). This works well in practice.

The best would be that all browsers support the Chrome Filesystem API, but that's not for now

Thats cool! Any reason you do it in multiple distinct chunks vs mutating a single chunk?

I'm assuming the time required to store and request a massive blob gets excessive at some point, but were there any other reasons?

It is because IndexedDB maximum row size is not that big, and depends on the browsers

Wow I had no idea! I'll have to look into that, thanks!

If there's no browser then there's no need for WebAssembly. You can already download binaries and run them, that's what a game install is.

What webassembly provides is a bytecode format that multiple languages can target, that isn't owned by a corporation, and that's intended (as per their own docs[0]) to run both natively and on the web (with browser vendors already opting in.) This offers benefits over native code tied to an operating system, existing bytecodes and VMs tied to a specific language or company, and allows the possibility for applications to seamlessly operate on the web and offline.

The only thing a browser offers is an HTML and Javascript context... which are necessary to run it in a webpage, but not really the entire purpose of webassembly as a concept.

[0]https://webassembly.org/docs/non-web/

Sorta, I think go means “browser chrome” like the part isn’t the url bar and menus. Webassembly, assuming you use the browser engines, gets you some nice things sand boxing and true cross platform execution.

Eh? I don't really understand; a progressive web app is standalone, but of course the browser has to be involved, it's a web app.

>Now that we have WebAssembly, performance is much less of a problem.

It will be, as long as we can stay away from the paradigm of Electron as the de facto runtime for Webassembly. Despite its name, Webassembly doesn't need to run in a browser, we can have executable WASM run in thinner native clients.

Although I can agree in some respects... however, a browser gets you a LOT more than just a WASM platform... canvas + webgl can go a long way, but then why not get the reset of the rendering platform which gives you stylistic support of a hypertext/dom model that is well understood with cross platform engines for pretty much every platform out there.

Creating compiled applications that look halfway decent is REALLY hard with compiled UI toolkits, for the most part. And really easy for browser based toolkits. While I don't appreciate the additional bloat of Electron itself, it is a nice option. I would like to see something similar be available as a cross-platform baseline, auto-updated like chrome. Node + Carlo could be an option, which would at least use the platform installed Chrome.

In the end, something like Adobe's Air platform could be incredible, but run by a company that supported more modern JS, and rendering. My hope is that with MS changing Edge to use Blink's engine that something like this could evolve and be adopted by other platforms.

Agree completely. The true power of WebAssembly will be realized when it gets completely free from the Browser.

I get some weird lighting bugs -- one side of everyone's face has massive shadowing from the centreline...

... but yes, surprised how well it ran on my old laptop!

Some more details here, including an explanation for that visual glitch:

https://groups.google.com/d/msg/emscripten-discuss/pKcWvKppj...

It made everyone look like the racist aliens from that old Star Trek episode.

I was having a lot of audio cutouts too, and the framerate tanked when the actions started heating up. Imps jumping around could drop it to the low single digits. Still, pretty impressive for playing in a browser.

For a game that released 15 years ago?

If you knew what was going on under the hood, yeah it's very impressive. Taking a fixed-pipeline shader based game and porting it to modern WebGL isn't easy.

I don't know how this port is doing it, but with emscripten it might be as easy as adding the `-s LEGACY_GL_EMULATION=1` compile flag.

The author used Regal rather than the LEGACY_GL_EMULATION feature in Emscripten, which I doubt was complete enough as Doom 3's fixed-function pipeline was easily one of the most demanding OpenGL 1.x games. Anyway, I don't think it's particularly valuable criticizing how hard or not-hard the effort was when the end result is novel and impressive.

One of the difficult thing was not knowing during the whole porting process if in the end it would really work, or not... I almost gave up several time :)

I used to develop an emulator. Different scope, but I guess there are a lot of similarities, so I feel your pain.

Getting things working on platforms other than originally intended is really hard. Nice work!

How long did it take to port?

First commits on the repos (D3 and Regal) are from 17/12. I started to work on this a week or so before the first commits, so it took roughly 4 weeks, with daily progress and commits. In the end the amount of changes in the code is relatively small. Time was mostly spent investigating and figuring out WHAT changes needed to be done for things to work

Impressive man!

Can you talk a bit about the biggest problems you faced?

Also, I'm a bit familiar with the doom 3 code, and the loading a 400mb pk4 file issue can easily be fixed by extracting it and loading/streaming the necessary stuff for each level and such.

I am preparing a Readme file with more explanations. Yes I think I think I'll extract everything on the server, and implement some form of lazy loading thanks to some emscripten mechanism

from pasts experiences a porting a moderate codebase(300k) is not quite fire and forget with emscriptem, but had no idea of that flag(last attempt a couple of years ago, didn't follow on changes)

Getting something like this running in a web browser at acceptable performance is a significant technical achievement.

Is it? Web browsers aren't that much slower than native (around 2x with web assembly and WebGL I think).

It's much harder for apps that are trying to render to the DOM (which is very slow). But WebGL apps should be perfectly fast in browsers...

All WebGL implementations have significant overhead compared to native GL. For example, just clearing the screen at 60 fps taxes my CPU at 10% on Windows (30% on Linux) while a C program that does the same uses 0% CPU.

The reason for the performance penalty with Firefox on Linux is that the framebuffer content is copied from GPU to host memory, compositing is done and then it's copied back to GPU.

For other platforms I'm not sure.

Further, SIMD support has been removed from Javascript and not been added back to WebAssembly yet, so that's another factor 4-8 for computation-heavy code. Experimental pthread support is only available in Chrome experimental for now due to the Spectre and Meltdown exploits. And general GPU compute apparently is really tricky to implement in a secure way, although DOOM does not use it.

> copied from GPU to host memory, compositing is done and then it's copied back to GPU

Shouldn't happen with GPU compositing in Firefox (layers.acceleration.force-enabled), right?

It has been years that we have WebGL running in the browser, not to mention Linux kernel ect ...

Hardware acceleration in Linux? someone pinch me, I'm dreaming.

I'm talking about running Linux in the browser:

https://bellard.org/jslinux/

I’m wondering for kicks if this would run on my iPhone 7S, but I think it being at the top of HN is terrorizing the download speeds.

> iPhone 7S

Not trying to be rude, but this phone doesn't exist,

could be an apple employee testing a new device who briefly forgot himself

I tried it on iPhone 8, iOS 12.latest and it crashes Safari once it downloaded the data.

Redistributing game assets like this is legal how? https://github.com/id-Software/DOOM-3/blob/master/neo/sys/li...

It's the demo.

It's the demo.

Do the demo assets have a less restrictive license?

If you wanted to be pedantic, probably not, but given how easy it is to just download the shareware version yourself and open the WAD files or whatever, what's the point? Would be a silly restriction.

Sure but it wouldn't be the first time a rights holder sued over a "silly restriction". If someone wants to take that risk then more power to them but they should be aware it is a risk unless they have a specific assurance.

I double checked on the License specific to the demo (License.txt in the install), and it is indeed less restrictive. However this might be gray area

Is your browser ready for Doom 3?

More like is Doom 3 ready for my browser? This is taking forever to load.

But are you keeping up with the Commodore?

The real question is: can your browser run Crysis?

Hi Gab_CV, this is really cool! Congrats! Are you planning on writing any notes about what the port took? You commits are quite clean, but still some narrative would be really interesting.

I haven't played through the demo. But this is very impressive.

Took about 10 minutes to download and start, I also had half face rendering issue + lost some audio play randomly. FPS was low and cpu was hottie but it worked.

"Site not installed". I think we killed it.

Yes, it is dead just now. I guess I have to take another hosting option :)

Loading data...

Took a long time to download but it does work, really amazed here

It's not a <video> element.

Yeah, but if it can be done for a game, it can be done for obnoxious advertising.