DISTS: Updated Webassembly / Emscripten Port

[chkuendig]

I kept working on the Webassembly / Emscripten port in the past months and I feel it's ready now for another PR:

Changes include a few critical improvements:

• Dynamic Plugins: It's now possible to dynamically load plugins, making it possible to bundle all engines without the binary growing into unreasonable sizes. This depends on emscripten-core/emscripten#15893 which hasn't been merged, so it's manually patched in during the setup of the build environment.
• General Build Improvements: The build script is now fully self-contained and can be run with Github actions, this includes automatic download of games/demos as well as generating the default scummvm.ini for a demo page. See chkuendig/scummvm-demo on how a ScummVM demo app can be built (incl. playable demo).
• ScummvmFS: I added a custom filesystem layer which in the future can be extended to support range requests and persisting downloaded data for offline usage. (also, jvilk/BrowserFS is not maintained anymore)

Minor Improvements:

• CLI arguments: It's now possible to pass CLI arguments as a anchor link. (this is used to generate the initial scummvm.ini file by opening http://localhost:8080/scummvm.html#--add --path=/games --recursive in a headless browser)
• HiDPI fix: SDL_GetDisplayDPI has been added to SDL for emscripten with libsdl-org/SDL#5383 - but this hasn't been released yet so I switched to using an unreleased version of SDL during the setup of the build environment.
• Gamepad API: There was a minor bug when opening the app on a non-secure context (i.e. HTTP instead of HTTPS) due to SDL wanting to use the Gamepad Web API, there's now a redirect to avoid this.
• Parts of the closed PR #3686 are added to the SDL backend for fullscreen support, no exit buttons and proper URL opening.
• Director Engine: Yield back to the browser in the mail loop

I also added myself to the credits. Let me know if there's anything else required for me to officially take the maintainer role for this port.

As before, the latest version is running at http://scummvm.kuendig.io/ (now automatically built with Github Actions, see chkuendig/scummvm-demo/).

[ccawley2011]

This should ideally be done in a subclass of OSystem_POSIX (or OSystem_SDL if you don't need XDG paths or fork/exec) rather than via ifdefs.

[chkuendig]

I might have misunderstood something, but the consensus in #3686 seemed to have been to not add another backend class. So I'm not sure what is preferred - would it be better to add a separate emscripten backend?

[ccawley2011]

The issue with that PR is that it that it duplicates a lot of stuff from the POSIX backend that looks like it wouldn't be useful on Emscripten (namely the path handling, the Linux AudioCD code and the use of fork/exec for opening the log file). Since having multiple subclasses of OSystem_SDL is intended for this exact purpose, I'd recommend one of the following approaches:

• If the POSIX-specific code is useful for Emscripten, then the Emscripten backend can inherit from OSystem_POSIX and override specific functions where needed.
• If the POSIX-specific code doesn't work or is overridden by the JavaScript code, then the Emscripten backend can inherit directly from OSystem_SDL, with simplified versions of displayLogFile, addSysArchivesToSearchSet, getScreenshotsPath, getDefaultConfigFileName and getDefaultLogFileName where necessary.

[bluegr]

Totally agree with @ccawley2011's suggestions

[chkuendig]

Thank you, I'll subclass OSystem_POSIX as most POSIX stuff can be reused - Emscripten is generally considered to be POSIX (and says so on emscripten.org).

[chkuendig]

I pushed a change implementing a new backend. Let me know what you think.

[chkuendig]

I incorporated the first set of feedback. (i'll squash the individual changes into the right commits before merging)

FYI: I also noticed an issue with TLJ crashing when moving beyond the in game menu into the game - this came down to some weirdness with glTexParameterf which I couldn't figure out. I switched to glTexParameteri as that a) fixed the issue, b) was the only place in all of ScummVM where glTexParameterf was used and c) is anyway the appropriate function since the parameters are integer enums (based on https://stackoverflow.com/questions/29919386/what-is-the-difference-between-gltexparameterf-and-gltexparameteri)

[chkuendig]

I force-pushed a new set of (cleaned up) commits which should incorporate all feedback received so far and a few other improvements I made along the way.

[lephilousophe]

Some comments after skimming this PR

[chkuendig]

FYI: I pushed a new revision of this PR. There's a few more things I might look into, but these things can wait.

Once I've tested the demo a bit more to discover any issue, I'd suggest this can be merged (I'll remove the draft flag accordingly)

[aquadran]

scummvm repo is not good place to keep distro patches

[chkuendig]

I agree this is a hack. Is it general not a good idea to include patches (and instead rely on only stable versions), or is this particular one a blocker since it isn't even in the PR of the upstream project?

If it's the second, I would try to get this added to PR emscripten-core/emscripten#15893 (or start a second PR), so all patches have a corresponding PR. If we in general don't want to rely on unreleased code, this will mean:

• Either keep this PR open until all changes are merged and released in upstream
• Accept that certain things wont work with the merged code without manually applying these patches (this can be documented and a second PR could be put in draft until the changes all have landed)

The reason that these patches are checked into this repo, is because PRs aren't 100% stable (they are often rebased against master, which means they might not work against the stable release this script is depending on)

[aquadran]

you can create upstream forks with patches applied and point to them. or put patches somewhere on GitHub and point to them

[chkuendig]

I cleaned up the patches in 037536e. All patches are now downloaded from Github (I still checked them in as well as PRs aren't 100% stable which could break the build).

[aquadran]

I still see patches in PR

[chkuendig]

I wasn't aware that patches in general aren't allowed. I removed them and uploaded them to another repo (to ensure they stay stable and don't change should the PRs change)

[aquadran]

scummvm repository is not good place to keep patches

[aquadran]

there are still patches in PR

[sev-]

Looks great and I am backporting it to 2.6.0. Will you be able to build it at the time of release?

[chkuendig]

Yes, this is easily built. I have Github Actions actually. I wonder through what artifacts we would provide? Im currently hosting on Github Pages and cant get more demos onto that (already hitting some limits), OTOH providing a zip file to download doesnt make much sense either.

[neuromancer]

I made some quick PR to have this deployed: #3985. It will require some adjustments, but hopefully we have it merged to allow users to test 2.6.0 release candidate. Happy to include any improvements or suggestions from you!