Run tests with -Wno-self-assign-overloaded
Some tests explicitely assign the value of the variable type to itself.
Fixes warnings such as these:
./test/common/str.h:201:9: warning: explicitly assigning value of variable of type 'Common::String' to itself [-Wself-assign-overloaded]
foo10 = foo10;
~~~~~ ^ ~~~~~
./test/common/md5.h:17:3: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation]
"345678901234567890"
As a safety check...
Also throw out some warnings when loading savegames
with instrument data for a different device (the savegame
incompatibility would be very nice to be fixed, but it is not
trivial.
(fixes bug no. 1248 - "SAM: some MIDI channels missing on MT-32")
This is a very obvious bug if the speech is turned off (otherwise the speech will
kind of cover it up). In the SAMNMAX intro it is hardly playing anything.
The reason is that the newer sound system has an extra driver layer between the
imuse parts and the actual hardware which mananges the channels (similar to
what we already do for AdLib, Amiga, FM-Towns...). Whenever the songs are
attempting to use a Midi part > 9 our current system will fail.
I have written the MT-32 player to also handle the older games music and sound
effects. This will allow cleaning up various more hacks in the common sound code.
I have done only little cleanup here, since it is not the main purpose of the commit.
I will also write a GM driver. This is going to be easier. Currently, there is a only
some init and skeleton code for it, the rest is just pass-through...
Currently, Roland MT-32 sound is broken for
SAMNMAX. Just try the intro song with shut off
speech. It is very obvious that it plays with a quite
reduced number of channels compared to the
original interpreter.
Now, due to the not-so-helpful code design (much
of the iMuse code has been drawn into the common
code) it has become increasingly difficult to fix Midi
related thing in iMuse. I have added more and more
crude hacks over time.
SAMNMAX requires more elaborate channel
allocation. To make it happen I have added driver
wrappers for Midi to the iMuse code.
Other than that, I have done only minor cleanup here.
Actually, I would have liked to withdraw much more
of the iMuse code from the common code and move
it to SCUMM (basically all the MidiChannel
stuff which is exclusively used by iMuse. But it turns
out that it is so thoroughly intertwined (the major
blocker here being the AdLib driver) that it requires
more thought and effort and would just distract me
from fixing the SAMNMAX sound.
In Director, FPS entries in the tempo channel apply to all subsequent
frames. If we seek to an arbitrary frame, the correct tempo settings
should be applied.
Fixes the animation speeds of the cauldron and the walking teapot in
Chop Suey.
Previously this would be updated in
DigitalVideoCastMember::createWidget, which meant it was possible for a
movie to complete without updating _movieTime to the final end position.
Fixes the cupcakes from not stopping animating once the song is finished
in Chop Suey.
VideoDecoder::needsUpdate() only returns true if there are frames
remaining to be rendered. This won't work for video files that are
audio-only, so in the event of a such a file, fall back to checking
endOfVideo() which includes audio tracks.
Fixes audio-only DigitalVideoCastMembers in the Director engine.
Fixes playback of the cupcake song in Chop Suey.
Unlike the 8-disk version, this one has proper MT-32 resources (see
commit 655afcdf55 for more context).
Reported by a French player owning this (rare?) release.
Use `clear` instead of `release` where possible.
Both clean up the span object. They differ in that `release` returns a pointer to
the internal data and `clear` destroys the internal data.
This code is present in all the original interpreters using Digital iMUSE, and it was implemented
in order to allow slower CD drives to fetch new data without having music skipping during load times.
This works by basically flooding the music buffer with data whenever a big resource, a voice file, or
a SMUSH movie is loaded.
Arguably this is not needed for devices using SSD drives, but since this change had its benefits on a
quite old laptop of mine, and since the memory overhead is very minimal, I have decided to implement it.