Unlike the PC version, the practice mode box appears to be hard-coded in
the Mac version. The script that draws the box in the PC version just
sets variables in the Mac version. This implementation is based on
screenshots.
To keep things a bit saner, I've split out the Mac-specific drawing to
its own file.
I misunderstood the purpose of _textSurface. Now text is drawn to the
Mac screen, and a text mask is drawn to the _textSurface. I hope that's
better.
Still no luck with the non-disappearing text at the start of the game
though.
The font renderer now remembers if the previous character ended on an
odd X coordinate, and compensates for that when calculating the next
character's position.
Maybe there's a more elegant way to do it, but it will do for now. The
rendering appears identical to the original, at least for the test case
I'm using.
Instead of trying to keep track of the real Mac screen coordinates in
the _charset data type, use the original 320x200 coordinates and only
scale up at the time of rendering.
Either way, the output is not pixel perfect, and this is much less error
prone.
Now if only text removal worked correctly...
The main purpose of this set of changes is to refactor the code to make
it easier to pass the name of the Macintosh resource file to other parts
of the engine (it used to be hard-coded in the music players), and to
scale-up the graphics by 2.
The actual font rendering is almost completely broken.
For detection purposes, the Mac variant is the same as the CD variant
except without audio tracks. Otherwise, ScummVM will warn about the
"missing" audio files when the game starts.
Also added missing file size for one of the Mac verions. I have that
version, so this should be correct.
The size in snprintf includes the final null character, so here
3 bytes are not enough to store a space, 2 digits and the null
character.
The compiler complained and the output used to display 1 digit
instead of 2, for each byte.
Extend this size from 3 to 4 in the snprintf call.
The original commit containing the Pete Wheeler hotfix for the Baseball gmaes has caused a regression where batting with any other bat as Pete Wheeler would slow down his swinging animation after hitting the ball. Whoops. This fixes the regression by adding another check to determine whether he is bunting or not.
curRect.left is assigned in the script, and it is not modified. right is
assigned with the screen width - original left.
This results in bad highlighting of the verbs all over the line width,
instead of being limited to the actual string.
Due to that, sometimes the selection range of the up/down arrows overlaps
with some of the verbs, and then these verbs cannot be selected.
Solve by storing the original left value, and using it as initial x
position for the string (the actual right-to-left manipulation is done in
drawString()), and modify the value of curRect.left to match the string
that was actually drawn.
This bug is similar to the one that was fixed in 58e921eb87, but the
solution that was done there for v7 and v8 cannot work here, because the
string logic is much more complicated.
This workaround fixes a script bug in Backyard Baseball 2001 and 2003 where bunting a foul ball as Pete Wheeler may softlock the game if the ball goes far left or right field.
The original Backyard Baseball 1997 release does not seem to have this bug in my testing.
The value of left is applied from the script all the time, and was
replaced in drawVerb.
The problem with this approach is that redrawVerbs maps the mouse
location to verb index *before* calling drawVerb, so the rectangles it
compares against are invalid in X-axis (right is always _screenWidth -
1, and left is always 5).
This caused several bugs:
* Each verb was clickable all over the screen's width, although it was
not highlighted.
* If the mouse was between 2 verbs, long above short, the Y-axis has 6
overlapping pixels (e.g. 1: 330-360, 2: 354-384). Scanning is done
bottom-up, so 1 was highlighted, but 2 was selected because of the
previous bullet.
* The text on Hebrew was aligned to the right without any padding. Other
languages have left = 5.
Fixed by setting right instead of left when applying the script, and
adjusting left in drawVerb. Other languages are not affected.
Another issue, unrelated to language selection: A verb that was split to
2 lines was clickable all over the screen's width. That's because
curRect.right was set beyond the _screenWidth, and it was not trimmed to
the first (longer) line's length. On Hebrew, curRect.left became
negative. This is also fixed in this commit.
(Loom (VGA) - Graphical glitches where some text appears over previous line and the wood musical note disappear)
The glitch is caused by a workaround in ScummEngine::actorTalk(). Removing it will make the original bug (speech animations for empty text strings) reappear. I have located the code which prevents that in LOOM DOS EGA disasm and added that. The FM-Towns versions don't have such code, but I do not get that weird speech animations either. So it seems to be fixed in a different manner there...
The iterator l was used inside the loop, which caused it to bail out
after 12 iterations instead of 16.
Amends 434d1f37f9398b6a7a1b08cd5464a1d5ecccdc41.
This is mostly based on ZAK and MI2 disasm (and a bit LOOM). For MI1 and INDY4 I have at least checked with the FM-Towns UNZ emulator to ensure that they actually have the smooth scrolling.
The smooth scrolling is a bit tricky with regard to the timing. The scrolling tends to be a bit too slow for the engine, since it happens at a speed of 1 pixel per 60Hz tick, while the engine sometimes writes one or more new 8 pixel strips at the same time. So the scrolling often has to catch up to the engine. The original has a compensation mechanism which I tried to adapt. We'll see if it needs more fine tuning...
The Loom intro even glitches in the UNZ FM-Towns emulator due overflowing the scrolling surface (and causing a wraparound). But I made a fix for that.
Since we do have a bug report about the speed of the ZAK intro (and the new scrolling code does affect the timing) I have run the ZAK intro in ScummVM and in the FM-Towns UNZ emulator (with i80386DX, 16 MHz setting) side by side and they seem totally in sync. If I reduce the MHz setting in the emulator to 10 MHz on the emulator the intro will play slower, but still not play through the whole song. With 8 MHz I get close to finishing the song, but this seems to be almost to slow to run the game properly. So I'll leave that bug ticket open...
