News for hackers. Stuff that matters.

A comment on Doom 3 in WebAssembly. Parent comment

Re:Doom 3 in WebAssembly by Klathmon on Thursday January 03, 2019 @07:53PM (#18821020)
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.

[ Parent | on HN ]
Re:Doom 3 in WebAssembly by Gab_CV on Friday January 04, 2019 @08:20AM (#18823759)
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

[ Parent | on HN ]
Re:Doom 3 in WebAssembly by Klathmon on Friday January 04, 2019 @08:44AM (#18823950)
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?

[ Parent | on HN ]
Re:Doom 3 in WebAssembly by Gab_CV on Friday January 04, 2019 @03:17PM (#18827255)
It is because IndexedDB maximum row size is not that big, and depends on the browsers
[ Parent | on HN ]
Re:Doom 3 in WebAssembly by Klathmon on Friday January 04, 2019 @03:38PM (#18827390)
Wow I had no idea! I'll have to look into that, thanks!
[ Parent | on HN ]