Prevent "stuttering" from starting the music multiple times (which may now happen due to the improved savegame loading for v1-3).
Also add some more tweaks to minimize stuttering, like setting volume to 0 during loading.
The result now seems to match what I get when using an emulator.
Similar to what has been added for Loom, this tries to emulate the original (script driven) loading behavior for the rest of the v1-3 games.
This fixes bugs like the music not being restarted properly when loading a game (happens in MM and ZAK).
https://bugs.scummvm.org/ticket/4494 will not be fixed, though, since I don't support Mac with this fix.
The Mac games work differently, they don't have a save/load room but these Mac style menus instead. Someone would have to do examine the save scripts for these...
Unless a slow host machine was used, the previous calculation always yielded 0.
Also, by disasms, those two timers should be assigned exactly in the same way as VAR_TMR_1, 2 and 3.
The replacement music timer operates on real time, and is adjusted for
the expected length of the Loom overture in order to accommodate for
different recordings of it. It's completely independent of the SCUMM
engine's timer frequency.
The original commit message says "Skip sound caching in Sam & Max
(Talkie)", with no mention of copy protection being involved. I guess
the _copyProtection flag was re-used as a convenient but rather
unintuitive way of preserving the original behavior.
This fixes a couple of regressions (mostly camera related). For DIG it seems that the older version of the interpreter uses CharsetRenderClassic type text display while the newer version uses COMI style. I stick with the COMI style, but with the necessary tweeks to make it pixel perfect for all versions.
COMI (I've tested English and Chinese) seemed to be pixel perfect without having to do much, same for DIG Chinese (new interpreter version). Even the verbs seem to be fine, although I haven't changed anything there yet (applies to COMI only afaik, I think DIG doesn't have text verbs).
DIG English (old interpreter version) is another matter. That one wraps text quite differently. Our version looked quite different from the original. But now it also seems to be fine. I even fixed a weirdo problem with the character width (It seems that the fonts have some kerning data; if we use that like we did the 'a' character gets displayed too narrow by 1 pixel. So all lines containing 'a' characters were slightly off). I have examined several strings in several camera settings for pixel perfect drawing in DIG and all seems good now...
FT: I'll do that separately. I haven't even checked if it needs any fixing. Maybe it is fine already. But it sure would be nice to get rid of any redundancies...
- Attach actor talk texts to the appropriate text renderer and get rid of redundant code.
- Cleanup subtitle text handling.
- Fix handling of ^codes.
- Fix more regressions from last commit.
- Correct some x/y positioning.
(inspired by PR 3276 - this here has the desired effect, but actually allows the removal of hacks, workarounds and redundancy code instead of adding more of that sort)
The purpose is to have the same accurate font rendering that we already have in the Smush code also for the ingame texts. The original interpreters draw the text like that, so this is not a weirdo invention of mine.
This is still broken. The main purpose was to get as much code done as necessary to have it at least compile again and correctly run the Smush texts.
The rest still needs quite some work...
It doesn't make much sense to keep this as a separate option, when
fixing the font spacing is an enhancement specifically for the Mac
version of Indiana Jones and the Last Crusade.
If for any reason waitForTimer() lags behind by "a lot", return the real
time instead of the expected time. One such case if is the game was
paused (which we could detect and set a flag for), but there are other
possible cases (e.g. the process being suspended) which I don't think we
have any good way of detecting.
This keeps the game from rushing to catch up after pausing.
This was a regression from the recent timing fixes. In fast mode, the
main loop would still assume waitForTimer() took the normal amount of
time to finish. Now waitForTimer() returns the expected end time,
adjusted for fast mode.
The demo scrolling is not yet as refined as in the final products. An adjustment to the timing that was made for the final products is not present in the demo. This adjustment will actually make the scrolling more sloppy in the demo (due to different scumm timer parameters set by the scripts) , so I disable it here.
Please note that the scrolling still won't be as smooth as it is in the final products. This is the same when viewing the demo in an emulator, though (I actually think it is slightly better in ScummVM). It is probably the reason why they made the change for the final products.
It doesn't matter for the main loop, since any overshoot is still
accounted for and they're just fewer and smaller now. But the function
is called from some other places as well.
The waitForTimer() function is almost guaranteed to overshoot its
target. Keep assuming that it's exact, but factor in the difference when
timing how long scummLoop() takes.
Before, the music timer was based on the number of SCUMM ticks that had
passed since the track started. But this meant that the timing could
differ by several seconds depending on your hardware.
Now it's instead based on the amount of time that has passed since the
replacement track started playing. Time that passes while the game is
paused does not count. Of course, if the player suspends the process that
time still counts. But the player was clearly asking for it then!
Would it be better to tie it to the current position in the audio track?
Possibly, but the CD audio manager doesn't provide that information.
Even if it did, the timer has to run even if the track ends prematurely,
because we can't just assume that every available recording has the
expected length.
But at least, we now have a well defined unit of measurement: We
hard-code the point in time where the Overture transition should happen
with the Ozawa recording. Ten ticks on the settings slider moves this
point by one second, allowing the user to adjust it by 20 seconds in
each direction. Surely that should be enough?
We now store the difference compared to the default value, rather than
the actual SCUMM ticks. Therefore, the default value for the setting is
0, not DEFAULT_LOOM_OVERTURE_TICKS.
It's hard to make this appear only on EGA Loom, so the tooltip has to
document the fact that it's only useful there. The setting is made
relative to the default tempo, which I feel is a much more sensible way
of presenting it to the user than the raw ticks value.
Thanks to eientei and GandalfTheWhite for confirming that the Atari ST
and Amiga versions use the same track numbering as the EGA (AdLib) and
Macintosh versions. That should mean that only the versions that already
use CD audio track need to be excluded.
For the Loom Overture to end, the music timer has to reach at least 278.
Keep the music timer updated for as long as there is a current CD sound,
even if the track itself has ended. If the track ends very early during
the Overture, skip ahead to the scene change. There will be several
seconds of silence, but this seems unlikely to ever happen to begin
with.
This is currently hard-coded for the Loom Overture, and counts the
number of SCUMM ticks that have passed since the song started. Perhaps
it would make more sence to query the CD position, but our CD audio
manager doesn't support that at the time of writing.
This allows EGA Loom and Mac Loom to use replacement audio tracks, e.g.
from the FM Towns or TurboGrafx-16 versions or, with a bit work, any
recording of the original ballet.
Currently the Ouverture doesn't work, since it relies on the music
timer being updated.
If the game is a talkie version, on which the verbs reference sounds, but
it is missing the sound file, and the user chose Voice Only, a warning
appears for every playback attempt.
Force subtitles on this case, to avoid these warnings.
Fixes trac 13151
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 FM Towns demos use audio tracks, but neither have a track 1. This
caused ScummVM to warn that the audio tracks had not been properly
ripped from the CD.
