The engine now measures whether it can perform one screen update within a 60Hz tick. Unfortunately the calls to OSystem::updateScreen() may take very long, depending on the backend and the filter setting. In this case the engine will start to catch up to the current frame. It should still look fine, unless the platform is way too slow for the selected filter setting (with the wrong settings it is not too difficult to achieve OSystem::updateScreen() durations of over 100ms).
These changes are currently pointless, since the affected function variants won't be called. The Japanese game versions for which they would be used are not supported in non-USE_RGBCOLOR builds. But the code should be correct nonetheless...
("drawing" in this case means the data conversion and transfer from the gfx layers to the screen buffer)
From my measuring experiments in the MSVC debugger this speeds up the drawing 2 - 3 times. Not sure about release builds, whether these profit even more.
(partly revert fb8f1084)
There is no simple solution that would still leave the "butter smooth" scrolling for faster platforms intact. I have measured times between several code points to find any bottlenecks. My finding is that even single script opcodes may well take over 200ms to execute. And exceeding a singe 60 Hz tick happens way more often (which makes the scrolling fall behind and have to catch up, thus becoming a bit sloppy). So, for the "butter smooth" scrolling I'll probably implement a timer for the screen updates (which will then really behave much more like the interrupt handler of the original). But that's for a separate commit. This one is mostly about the bug ticket..
I have made the scrolling more smooth and still hopefully managed not to break the sync with the engine (which really is a bit tricky).
I've tested playing the ZAK and LOOM intros and also walking around in ZAK and MI2, since there are some good test cases there. I've also compared all these side by side with the UNZ emulator.
Note names can be drawn in three different colors: Dark gray for notes
you don't know, light gray for notes you know, and white for notes
you're using.
Or at least, that's how the DOS version does it. But there, notes
automatically go back to light gray once the draft is done. In the Mac
version, that doesn't seem to happen. And judging by how it behaves when
running it in a Mac emulator, known notes are always white.
Here is what I think happens: When text is removed, the text surface is
cleared in its entirety. This means that the next time the screen is
updated, it may redraw the low-resolution background. Since this has no
information about the high-resolution text, any such text is lost.
The distaff notes and note names are drawn in with the high-resolution
font. When using the distaff, only the note name is redrawn, not the
note itself. The way screen updates are handled, a larger area than just
the note name gets redrawn, and then part of the note may be cleared
away.
To get around this, when a note name is drawn on the distaff the text
surface is also updated with the note itself. (There is no need to
redraw the note, since we can assume it's already on screen, and we
don't want to bother with getting the color right.)
The only time the printChar() function prints note names should be on
the distaff. The Practice Mode box is handled by drawChar() instead.
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.
