This is the third part of the Part 4 mini-series. Part 4a covered maintenance work (testbed, timers, shaders, SDL3), Part 4b dove into audio (FluidLite, Web MIDI, RetroWave, TTS), and this chapter focuses on moving ScummVM’s web build closer to seamless file access: cloud storage, a cleaner network stack, and a filesystem rewrite that sets up the next round of improvements.

Cloud Storage Integration

- CLOUD: Add Support for Emscripten

One of the most exciting features I’ve added is support for cloud storage providers. This allows you to store your game files in Dropbox, Google Drive, OneDrive, or Box, and access them directly from the browser version of ScummVM. No more manual file uploads for each gaming session - just connect your cloud storage once and all your games are available!

This PR adds support for cloud storage providers (Dropbox, Google Drive, OneDrive, Box) for the Emscripten backend. It includes improvements to the cloud setup wizard, JSON parsing fixes, and OAuth flow handling.

Key improvements:

  • - CLOUD: Skip Mode Select in setup wizard if only manual mode is available (May 8)
  • - CLOUD: Cleanup unused kOpenUrlStorageCmd (May 8)
  • - CLOUD: Remember selected storage and pass it on to kCloudConnectionWizardOpenUrlStorageCmd in setup wizard (May 8)
  • - CLOUD: Avoid overloading runModal (May 18)
  • - COMMON: Fix JSON parsing of unicode strings (May 7)

Custom Network Stack

Beyond cloud storage, I’m tightening how the browser build fetches data. Games and assets can now be loaded directly from web servers via HTTP/HTTPS, which makes hosting demos or providing pre-configured libraries much simpler. This network stack work lays the groundwork for a cleaner separation between local data (IDBFS) and remote sources (HTTP/HTTPS), which I’ll hook up more fully in the next iteration.

Filesystem Rewrite

Since the first commit, I used BrowserFS for filesystem abstraction. However, it has been deprecated:

BrowserFS seems abandoned and never did a stable 2.0.0 release. Maybe there’s a better way to handle Storage?

At some point I vendored it in (2022: - DISTS: Updated Webassembly / Emscripten Port), but it never was fully the right tool (although development has resumed). I thought it might eventually help making cloud storage available more easily, but it turned out that the existing ScummVM code works very well for that already, and my goal is to keep as much as possible within the existing C++ infrastructure of the project - if only to ensure other people can maintain my code (or god willing, another Emscripten maintainer materializes.)

So I have finally removed it. For the local storage, I now use IDBFS directly in C++. For fetching assets over HTTPS, I built a small abstraction in C++ to use the browser’s Fetch API.

Benefits of this change:

  • Smaller bundle size: Removing the BrowserFS dependency reduces the initial download size
  • Better maintainability: Using native Emscripten APIs means the code is easier for other contributors to understand and maintain
  • More control: Direct access to IDBFS and Fetch API gives us more flexibility for future optimizations
  • Keeps code in C++: Maintaining consistency with the rest of ScummVM’s codebase

I don’t think this is necessarily the end-all best state. Ideally we would move to WASMFS, so we could use OPFS (Origin Private File System) for better performance and use FETCH_FS for the assets, but that will require enabling threads, which we currently don’t support yet due to complications with dynamic module loading.

- EMSCRIPTEN: FS: Implement filesystems in C++ and remove BrowserFS dependency (August 1)