Excerpts from WEB-build and Itch.io deploy of CGE Project journey

[michalis]

Audio playback on the web is also close to being done:)

Right now on branch webaudio (not master).

Initial notes:

• Underneath we use WebAudio API but you don’t really need to know anything about it – just use Castle Game Engine sound API and components and everything will work on the web.

• Note that the audio playback will be in a suspended state when loading the page in modern web browsers. This is a feature, the idea is that user should manually enable audio because it would be annoying if newly opened page could automatically play some sound. So we can only start audio in response to user interaction with a page, which in practice means: after a press (touch, mouse press, key press on focused canvas). Our engine handles the activation automatically, but you need to design your UX to encourage player to click on anything to start the playback. A button like “Start the game” will do the trick.

• Note the OggVorbis suppport depends on the browser (we rely that the browser can decompress OggVorbis on the web), but it’s commonly supported. See about supported media (including audio) formats: Media types and formats for image, audio, and video content - Media | MDN , Web audio codec guide - Media | MDN .

Tested on examples:

• platformer game
  • though note TODOs: initial menu music doesn’t play
• audio/doppler_demo
  • though note TODOs: Doppler effect is not done by WebAudio

Some TODOs before I merge this:

• Playing non-WAV formats (like OggVorbis) right when the buffer was loaded (e.g. playing iniital game music) will fail with Cannot play sound "%s" because it is still decoding. . We must handle this better, start playback once the OggVorbis finished decoding, instead of aborting.

  This causes the “initial menu music doesn’t play” problem for platformer now.

• We use JS promises in naive way but that’s not good: We need to make sure that we cancel the promise (building a mechanism on top of JS to cancel any promise, maybe just ignoring result), as we must cancel a promise if the Pascal instance interested in the promise no longer exists (which may happen e.g. if you switch views before a promise was realized).

  From what I see, various example JS code snippets using promises or async/await have this TODO too It will not crash in garbage-collected languages, but still may do all sorts of weird things.

  One needs to remember that application keeps working, possibly changing state, while we wait for promise to be delivered. Our WebAudio backend should account for it, to not crash in edge-cases when promises succeed/fail with large delay.

  This affects now decodeAudioData done asynchronously. In theory, you can crash it, changing views fast after staring to load OggVorbis. We should secure from it.

• (DONE) platformer weird shot.wav playback must be investigated and fixed.

• game_3d_sound crashes (for reasons unrelated to audio, it seems?).

• play_sounds crashes.

• Support other audio formats, like MP3. Also FMOD supports them. IOW, we are not limited to WAV / OggVorbis formats on some audio backends, and we should expose more audio formats, just with warning (that they are not cross-platform supported by CGE).