The default savepath on macOS used to be in the user Document folder.
However ScummVM requires special permission to access that folder,
and if the user denied it, this caused various issues.
This implement ticket #11428.
This commit also contains migration code that that old configs that
used the default path are set explicitly to use the old default path.
So the change of savepath will only be for new users.
The idea here is that we can package a game in a custom bundle using
the scummvm executable, and use the game name as bundle name. It will
then use its own config and log files rather than share the ones from
the standalone ScummVM app.
Instead we call the OSystem_SDL implementation of getScreenshotsPath(),
as done in the POSIX backend. This change means that if we change how
we handle a user-specified screenshot path in the SDL backend, the
Windows and macOS backends will still get the correct path.
Apple's desktop operating system was formerly called "Mac OS X" and "OS X", but since 2016 it has been called "macOS" (starting with version 10.12).
Changing across all comments and documentation to use this current terminology, except in cases where the historical versions are explicitly referenced. No code changes are made; we should consider changing those in future PRs.
The call to MIDIGetNumberOfDestinations() starts the MIDI server which takes
3-4l seconds even on the modern hardware. We are querying this in the GUI Options
which then lags on the first launch.
Thus, we are creating a separate thread and make this call at the start of
ScummVM, so by the time the user gets to the GUI, the server is already launched
and there is no lag.
Of course, that would mean that we will launch MIDI even for the games which are
not using it, so this is a tradeoff for the better UX.
The local documents are not currently internationalised simply
because the internationalised resources are not put into the right
places (NSBundle will handle this automatically when they are);
Trac#10464 is a tracking bug for this outstanding issue.
Fixes Trac#10437.
This mixer type was added in
943b4c2036 because "anything which
produces sampled data with high latency (like the MT-32 emulator)
will sound terribly", but as far as I can see (or reproduce), this
mixer doesn't do anything that would solve that problem, except
that it effectively doubles the size of the audio buffer so there's
less chance of an underflow due to slower-than-realtime synthesis
by the softsynth. But you don't need the overhead of a separate
thread to do that, you just need to increase the buffer size.
