This prevents the game from getting stuck in the MIDI initialization
screen if a MIDI/MT-32 driver is selected and enhanced music tracks are
present. In this case, MusicPlayerIOS is used, which plays the digital
music tracks, and does not perform any MIDI initialization
- Use the fake constructor for message dialog less often
- solve errors regarding comparision between string and u32string in midi
- solve errors in testbed/speech related to ttsMan->say
- fix unsigned comparision warning in tab.cpp
- fix issue with static strings and translations in sdl-graphics
The check to see if background music should be started was implemented as part
of the input processing. As a result, background music would not start if the
game was not getting any input. F.e. on the main menu after starting the game,
if you let the music play until it finishes without doing anything, the game
will go silent. Only after moving the mouse will the background music track
start. The original interpreter starts the background music without needing
user input.
I've fixed this by moving the check to start background music to the timer
loop of the MusicPlayer. I've added a check to prevent background music from
starting while the game is not accepting input.
When loading a savegame, the current background music would play for a few
seconds before the game would set the music for the room that just loaded.
This change stops the music when loading a savegame to prevent this.
The 7th Guest has MIDI initialization files for GM and the MT-32 that need to
run for these devices to sound correctly. When loading a game from the ScummVM
main menu, MIDI initialization was not performed.
This change adds this. It runs a slightly changed copy of the game's MIDI init
script when loading a game using the ScummVM menus. It also tracks if MIDI init
has been performed, so it doesn't run a second time when loading a game.
I don't know if the script works properly for the Mac and iOS versions of the
game (or if it is even needed), so I've only enabled it for the DOS versions of
the game for now.
XMIDI data for the MT-32 can contain a timbre chunk which contains the custom
timbre numbers used for a track. Before starting playback of the track, the
timbres must be loaded into the MT-32 using SysEx messages. Each SysEx message
needs a delay before sending the next message to give the MT-32 enough time to
process it.
The delays between the messages were generated using the OSystem::delayMillis
function. This throws off the timing of the MidiParser, which causes MIDI
messages to "pile up", in this case at the start of the track. This change adds
a queue to the Miles MIDI driver, which can store the SysEx messages that must
be executed. The MidiParser suspends playback until the driver has sent all
messages in the queue.
This fixes the start of tracks in The 7th Guest, which had incorrect timing.
Because of the new SysEx queue, MT-32 initialization of The 7th Guest takes a
bit longer than it did before. The game plays an animation of a fixed length
and aborts the initialization if it is not done by the end of the animation.
This problem was already fixed for the GM initialization, so I've applied the
same fix for the MT-32.
The 7th Guest initializes GM devices during the "loading GM drivers"
screen, which is a normal video that plays "audio" that consists of
initialization messages (mostly Roland GS sysexes). The original
interpreter plays this video twice, which is enough time to play the
entire INI_SC.XMI initialization file. ScummVM apparently plays video
a bit faster, and there is not enough time to play the entire init
file. Because of this GM initialization is incomplete.
I've fixed this by making the init video loop until the audio has
finished playing.
Note: I have only tested this with the original DOS version of the
game. I don't know if the file reference I've used to identify the
GM init video is the same on other platforms. If not, this change
might not work and/or have unintended results.
Loading and returning from subscripts alters the _variables
used, thus are not guaranteed to create a valid save state.
Loading a save should be valid at any time, as long as the
active script being run is restored to the base game script.
If the user enters in an invalid description for the save then it will be
simplified by the saved name cache process in Script::savegame.
I checked this with t7g, but not with the 11th guest or any other Groovie game.
The original in-game loading/saving can still only access the first 10 save
slots (0-9).
Its possible to saving via the GMM when the game is interactive.
Loading a game saved via the gui using the original in-game load menu
works fine.
Saving via the GMM with timestamp works, but only only saves the characters
up to the first non-alpha non-letter characer.
This removes the debugScript() wrapper, which can now be implemented
directly using the relevant debug function. This avoids the variadic
debug functions being wrapped in a second layer of variadic function
which is probably causing a significant overhead.
This is now uneeded as the GUI debugger superclass implements the same
functionality and this removes a bunch of complexity from the Groovie
engine debug calls. Also, removed groovie prefix from the debug flag
naming as unecessary as these are within the Groovie namespace.
This prevents segfault crashes in "The 11th Hour" when you open the
Gamebook palmtop from the top of the screen. The opcode needs some
work on the changes from 7th Guest, but this will prevent crashes
while this is being worked on.
find -name '*.h' -or -name '*.cpp' | xargs sed -r -i 's@\(([A-Za-z0-9]+)\*\)@(\1 *)@g'
This seems to have caught some params as well which is not undesirable IMO.
It also caught some strings containing this which is undesirable so I
excluded them manually. (engines/sci/engine/kernel_tables.h)
Now SaveStateDescriptor no longer subclasses HashMap. Instead all possible
saved meta data is included directly into SaveStateDescriptor.
This is slightly less flexible, but we never needed that flexibility so far.
On the other hand it should reduce the memory usage. At least on my system
(Linux/amd64) the old SaveStateDescriptor had a size of 928 and the new
SaveStateDescriptor has a size of 200.
This also removes the dependency of engines on the event recorder header
and API, and will make it easier to RandomSources that are not properly
registered.
These two speed modes enable faster movement throughout the mansion.
iOS mode matches the behavior of the official iOS release while
tweaked mode additionally uses original framerate for 'teeth'
animations.
This is a first step towards getting rid of all uses of regular printf,
fprintf, vprintf, vfprintf, puts, fputs, etc. in our codebase.
The name format() reflects the purpose of the function, and parallels
String.format() in Java, boost::format, and others.
svn-id: r54004
- Rewritten T7G's font code to subclass Graphics::Font and make it cleaner.
- Use theme fonts for the Mac version of T7G (which used ugly system fonts
originally). With this the Mac version should be completable.
- Cleanup include interdependencies.
svn-id: r49487
Christian Lindemann
Filippos Karapetis
sluicebox
aryanrawlani28
NMIError
D G Turner
Scott Thomas
David Fioramonti
Eugene Sandulenko
Ori Avtalion
Johannes Schickel
Tarek Soliman
Scott Thomas
Thierry Crozat
Matthew Hoops
Max Horn
strangerke
spookypeanut
Florian Kagerer
Jordi Vilalta Prat