It now says: "This topic has been auto-archived and can no longer be posted in because there haven't been any posts in a while. If you have a something related to post consider creating a topic in Questions & Support."
Recent community posts
Hmm, good thing I checked the page because I missed your post notification.
I never saw the push/pop notifications you mention.
I suspect there is some Python "print" calls somewhere in your game.
I'm considering blocking those, but they are usually debug left-over that are best removed, for performance reasons.
(if that's not it, send a screenshot and details about your OS/browser brand&version)
For itch.io, you don't add files to game.zip.
You make a new .zip (e.g. myvisualnovel-web.zip) that contains all the build directory files (e.g. all the files within myvisualnovel-1.0.0-dists/myvisualnovel-1.0.0-web/), including game.zip (in the end, there is a zip in a zip, e.g. game.zip in myvisualnovel-web.zip).
It is true to playing directly at the CDN bypasses all the fullscreen & orientation-locking wrapper.
Maybe this wrapper would need to be hosted at the CDN as well.
Or maybe the CDN could be exposed as a itch.io subdomain to solve the root issue.
I'm developing Ren'Py's official web port ( https://renpy.beuc.net/ ).
With iOS working better with WebAssembly, I get bug reports about the way itch.io embeds web games, using a web host with a different domain.
This triggers IDBFS (storage) errors when writing savegames:
IDBFactory.open() called an invalid security context
because AFAICT the browser considers this is akin to storing a 3rd-party cookie (itch.io -> *.hwcdn.net). This was already the case with Debian's Chromium (see Emscripten thread), which blocks 3rd-party cookies (and cross-domain IDBFS) by default, but now this happens on a major mainstream browser/platform.
Playing the game directly at *.hwcdn.net solves the issue.
What do you think about opening web games directly at the CDN for mobile users?
I don't understand: when a privacy-enhanced user checks a game's page (e.g. because they found it via itch.io search), they just get the sitelock warning indefinitely and confusingly. Are you saying gamedevs need to ensure users play the game from outside itch.io via an embed?
Just let us decide whether to enable it.
As part of the RenPyWeb engine, I need to transmit a large-ish .wasm with browser-level gzip compression (75% gain).
Embedding a JS gzip decompressor is proving increasingly hard to maintain, is less efficient, and incompatible with .wasm streaming compilation.
I can't find documentation on how compression is meant to work at itch.io and my tests so far are not conclusive (I can't find a way to both get content-type=application/wasm and content-encoding=gzip).
What do you guys recommend?