The current code checked for the CPU type to determine if we were
building for the older macOS releases requiring this older API, but
we can just check MAC_OS_X_VERSION_MAX_ALLOWED which is clearer and
more accurate.
Apart from simplification, this also lets one build ScummVM for x86
again on Tiger. I haven't checked this case, though :)
Note that the ComponentDescription -> AudioComponentDescription change
was done in macOS 10.6 and not macOS 10.5, so this also fixes this
case.
Tested on macOS 10.4, 10.5, 10.5 with the 10.4 SDK, and on 12.6.
There's still code for macOS 10.4 in the codebase, but everything before
that has probably been KO for years. And no C++11 toolchain exists for
macOS < 10.4 either.
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.
Also remove a couple of TODOs. I think we can limit the CoreAudio
plugin to the Apple DLS softsynth since with have the CoreMidi
plugin to access other MIDI devices.
This is a pretty bad hack of not using the kMusicDeviceProperty_SoundBankFSRef symbol and using its value instead. It felt wrong breaking 10.2.8 support just because of Soundfonts.
The new API has been present since Mac OS X 10.5 (released four years ago,
in October 2007), and also since iOS 2.0 (thus, the iOS port may be able to
use it, too). Moreover, 10.5 was the last system to support PowerPC.
This silences a bunch of deprecation warnings when compiling on any current
system. Moreover, the new API is available on the iPhone, so perhaps this
is interesting for the iPhone port, too.
On the long run, ScummVM will have to switch to the new API, as Apple
will eventually drop the old one.
This in turn enables modifying MidiDriver_MPU401::close() to allow
it to be called on a midi driver that has not yet been opened.
The specific issue that triggered me to make these changes was a
crash-upon-quit in HUGO, caused by it instantiating a midi driver,
then encountering an error (missing hugo.dat) *before* having
opened the new midi driver; the general cleanup code then tries
to close the (not yet opened) midi driver -> kaboom
Also fixed some engines which were leaking MidiDriver instances.
A new header file common/forbidden.h is included by scummsys.h and it
re-#defines numerous symbols like fopen(), fread(), system(), etc. with
garbage, in order to provoke compile errors in any code using them.
If a .cpp file really *must* use any of these (e.g. because it is a
backend file), then these redefinitions can be disabled by #defining
FORBIDDEN_SYMBOL_ALLOW_ALL as the first thing in the .cpp file. Whenever
this is done, an explanatory comment should be added.
Note that this system cannot catch all "bad" usages (notably the Lua
code in the sword25 engine), as it can only work if scummsys.h is
included.
svn-id: r53961
- Updated all drivers to allow 264+2 byte sysEx messages
- Implemented sysEx processing for MT-32 for Kyra1 and HoF. MT-32 should now be working properly.
svn-id: r35180
- Added the MidiPlugin interface to the remaining MIDI drivers
- Added an initial MidiManager to handle the MIDI plugins (just static plugins by now)
svn-id: r32117
