Age | Commit message (Collapse) | Author |
|
|
|
|
|
If this is not present, it will use the default as previously.
|
|
|
|
|
|
Bug-ScummVM: https://sourceforge.net/tracker/?func=detail&atid=418820&aid=3614268&group_id=37116
See more in similar http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387665
|
|
|
|
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.
|
|
Fixes bug #3602452
|
|
|
|
Powered by:
git ls-files "*.cpp" "*.h" "*.m" "*.mm" | xargs sed -i -e 's/[ \t]*$//'
|
|
If we don't bail out, CoreAudio will explode.
|
|
|
|
New sndio MIDI backend for OpenBSD written by Alexandre Ratchov.
Tested with an external MT-32 and fluidsynth.
|
|
This does not change the use of defined for some NDS source files, since they
seem to be (based on?) third party code.
|
|
This should fix the issue mentioned here: http://forums.scummvm.org/viewtopic.php?t=11255
Apparently Windows doesn't generate unique names for MIDI devices of the exact same type.
I do not know whether this could be a problem on other backends, too.
|
|
before they are actually used.
|
|
older SDKs
|
|
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.
|
|
Various cleanup
|
|
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.
|
|
|
|
|
|
|
|
|
|
At Raziel^'s request. This is the same as the ALSA checks I added
earlier today.
|
|
This should make it easier to spot errors like the one spotted in
the Queen engine yesterday. The Windows MIDI driver already seems
to do something like this; I don't know about the others.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some backends may break as I only compiled SDL
|
|
Found by GCC 4.6's -Wunused-but-set-variable
|
|
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.
|
|
|
|
Thanks to waltervn (and wjp) for their investigation on this and Walter's SCI
specific workaround which I more or less just copied here so it will apply for
all engines.
|
|
This might fix odd problems when storing the device name in the config file,
when the name ends with a space by chance.
|
|
svn-id: r55857
|
|
svn-id: r55851
|
|
svn-id: r55850
|
|
svn-id: r55248
|
|
svn-id: r54584
|
|
svn-id: r54575
|
|
svn-id: r54573
|
|
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
|
|
svn-id: r53395
|
|
Our warning() and error() functions always add an exclamation mark
to the end of the message anyway.
svn-id: r52791
|
|
Often, a client has more than one available port. Pick the first one
that isn't already in use. For instance, on my computer client 17 is
the "Emu10k1 WaveTable", and it has four available ports. If, say,
aplaymidi is already playing on port 17:0, ScummVM will use port 17:1
instead. Otherwise the two programs will mess up each others
instruments and controller settings.
Of course, in reality I doubt that anyone will run two different MIDI
playing applications at once.
svn-id: r51380
|