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.
For all the purists out there (I know there is at least one), the
default behavior is to try and emulate the original's slightly broken
font spacing. Even though I prefer correct spacing myself.
During smush movie playback the engine simply wouldn't react to a restart attempt (except causing a palette glitch). Now it apparently works...
I'd still strongly discourage anyone from using this, since it might make the engine unstable (see the old comments in ScummEngine::restart()).
This is guesswork, but it seems like the first channel always contains a
complete rendition of the music. I think that's intended for low-end
Macs, while the other voices (four, but the last one never seems to be
used) is the standard version of the music.
It doesn't sound particularly good, and also not quite as with Mini vMac
(I'm not fully prepared to rule out emulation problems), but it seems
reasonably close.
Before, ScummVM would only play ROL music if a MIDI-capable driver had
been selected. I have AdLib as default, which made it pick ADL music
instead and the Mac music player doesn't support that. So this is not a
new feature, it's just an old feature that's now applied consistently.
This fixes some missing music that might otherwise be missing in MI2,
most noticeably near the very end of the game. The ROL music is an
acceptable substitute, because the Mac instruments are close enough to
a subset of MT-32. I haven't seen any resources with both MAC and ROL
versions, so MAC should still be used when available.
Note that this doesn't seem to have been a ScummVM bug. The music was
missing when I tried the game in a Mac emulator too!
If another Mac version of MI2 is ever discovered, and its boot script
doesn't match any of the known ones, we can't know what the "skip copy
protection" boot param will do. Safer, then, to use the default boot
param. ScummVM may still skip the copy protection, but if so it will do
it the old-fashioned way.
There's still the matter of exactly when the text box should be created
(sometimes text is drawn to it in several steps, and we don't want to
erase the old text), and when/how to remove the box.
This is one of the players that has had problems with deadlocks
recently. I'm not very well versed in threaded programming, but arthxx
has promised to fix up some more players later. This one was used as
proof of concept because it deadlocks a lot.
athrxx
Torbjörn Andersson
Andrea Boscarino
Orgad Shaneh
Thunderforge
Eugene Sandulenko
Alexandre Detiste
djsrv
Le Philousophe
antoniou79
sluicebox