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!

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

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

Well, the end idea is to have sandboxed native speed applications, immediately available without any installation.

The issue of "loading" needs to be tackled on. In that very specific case, it is just that the program was not designed for streaming of asset data. This is a technological demonstration of possibilities of running native apps in a browser. But lot of work are remaining to do.

Installation is the point, you don't want to run a game only once.

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

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.