ryujinx/SDL
1
0
Fork 0
mirror of https://github.com/Ryujinx/SDL.git synced 2025-06-22 07:27:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Corrected/improved some Emscripten docs.

Browse source
This commit is contained in:
Ryan C. Gordon 2023-09-09 10:11:59 -04:00
parent 5e6a851d6c
commit 818a26f21b
1 changed files with 20 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
docs/README-emscripten.md
View file

@ -164,28 +164,24 @@ silence at a regular interval. Once the user approves the request, real
audio data will flow. If the user denies it, the app is not informed and audio data will flow. If the user denies it, the app is not informed and
will just continue to receive silence. will just continue to receive silence.
SDL3 allows you to open the audio device at any time; it'll just throw away
audio data until the user interacts with the page, and then start feeding
the browser seamlessly, but for SDL2, you need to manage this yourself.
Modern web browsers will not permit web pages to produce sound before the Modern web browsers will not permit web pages to produce sound before the
user has interacted with them; this is for several reasons, not the least user has interacted with them (clicked or tapped on them, usually); this is
of which being that no one likes when a random browser tab suddenly starts for several reasons, not the least of which being that no one likes when a
making noise and the user has to scramble to figure out which and silence random browser tab suddenly starts making noise and the user has to scramble
it. to figure out which and silence it.
To solve this, most browsers will refuse to let a web app use the audio SDL will allow you to open the audio device for playback in this
subsystem at all before the user has interacted with (clicked on) the page circumstance, and your audio callback will fire, but SDL will throw the audio
in a meaningful way. SDL-based apps also have to deal with this problem; if data away until the user interacts with the page. This helps apps that depend
the user hasn't interacted with the page, SDL_OpenAudioDevice will fail. on the audio callback to make progress, and also keeps audio playback in sync
once the app is finally allowed to make noise.
There are two reasonable ways to deal with this: if you are writing some There are two reasonable ways to deal with the silence at the app level:
sort of media player thing, where the user expects there to be a volume if you are writing some sort of media player thing, where the user expects
control when you mouseover the canvas, just default that control to a muted there to be a volume control when you mouseover the canvas, just default
state; if the user clicks on the control to unmute it, on this first click, that control to a muted state; if the user clicks on the control to unmute
open the audio device. This allows the media to play at start, the user can it, on this first click, open the audio device. This allows the media to
reasonably opt-in to listening, and you never get access denied to the audio play at start, and the user can reasonably opt-in to listening.
device.
Many games do not have this sort of UI, and are more rigid about starting Many games do not have this sort of UI, and are more rigid about starting
audio along with everything else at the start of the process. For these, your audio along with everything else at the start of the process. For these, your
@ -199,10 +195,6 @@ all to make it happen.
Please see the discussion at https://github.com/libsdl-org/SDL/issues/6385 Please see the discussion at https://github.com/libsdl-org/SDL/issues/6385
for some Javascript code to steal for this approach. for some Javascript code to steal for this approach.
SDL3 allows you to open the audio device at any time; it'll just throw away
audio data until the user interacts with the page, and then start feeding
the browser seamlessly, but for SDL2, you need to manage this yourself.
## Rendering ## Rendering
@ -323,11 +315,12 @@ When you debug from the browser's tools and hit a breakpoint, you can step
through the actual C/C++ source code, though, which can be nice. through the actual C/C++ source code, though, which can be nice.
If you try debugging in Firefox and it doesn't work well for no apparent If you try debugging in Firefox and it doesn't work well for no apparent
reason, try Chrome, and vice-versa. Sometimes it's just like that. reason, try Chrome, and vice-versa. These tools are still relatively new,
and improving all the time.
SDL_Log() will write to the Javascript console, and honestly I find SDL_Log() (or even plain old printf) will write to the Javascript console,
printf-style debugging to be easier than setting up a build for proper and honestly I find printf-style debugging to be easier than setting up a build
debugging, so use whatever tools work best for you. for proper debugging, so use whatever tools work best for you.
## Questions? ## Questions?