This would happen when either clicking on an empty slot or when using
the Delete key. It was caused by using the screen coordinates, rather
than the surface coordinates, when specifying the rightmost edge of the
area to clear.
The corners are drawn correct, we just want to ensure that the same
screen area is cleared or tindted before drawing the dialog, whether the
dialog is transparent or not. Otherwise, the corners will be tinted too,
instead of fully transparent.
When talking to another character, his animation would usually freeze.
Most of the time this is just a cosmetic problem, but it does make
solving the puzzle with the billiard players more annoying than it
should be, since you had to leave and re-enter the room. See bug #10931.
On a Chromebook, the keyboard may be present but hidden (not available for
use) because the device is flipped around in Tablet mode. In this case we want
the soft keyboard to be available. This change also hides the soft keyboard
button if the hardware keyboard is available, since it doesn't do anything.
Fixes#13138.
Each character in a font can have an X and Y offset. This was not
considered when calculating the width and height of the font. One way
this could be noticed was in Serrated Scalpel, when talking to a
character with a lot of conversation options. Scrolling down would
highlight the "Up" button. Selecting a conversation option would then
dim the button, but the bottommost pixel of the "p" was still
highlighted.
Hopefully this does not negatively affect anything else.
Fixes QFG1 Japanese message display when messages are set to
Japanese and subtitles are enabled
Huge thanks to DarkSoul for verifying original PC-98 behavior
Many PQ2 Japanese strings contain escaped newlines ("\n") which we have
not been handling. We have been handling these in getSciLanguageString()
when returning Japanese text but that's not where SSCI does this work.
PQ2's Print procedure in script 255 parses Japanese text itself and our
getSciLanguageString() is never involved.
Now Japanese newline handling is done in the core text measuring and
drawing functions, which is closer to where SSCI did it, but without the
hack of having GetLongest() patch out Japanese newlines like in SSCI.
Fixes bug #13154
I think this one would happen if an NPC initiated conversaion with you,
while you had a window (e.g. the inventory) open. The game would be put
in talk mode, then close the inventory (putting the game in standard
mode), then print the conversation options.
That's because a loop was terminated prematurely (with a break), thus
bypassing the bit that would set it back into talk mode again.
I encountered this when finally meeting up with Lord Brumwell.
The event loop when entering save game description in Rose Tattoo runs
at the speed of the background animations, which is much slower than
ScummVM's keyboard repeat.
It was very easy to saturate the _pendingKeys queue, particularly when
erasing an old savegame description. Then you might have to wait for a
few seconds while it processed dozens of pending backspaces.
Now all pending keys are processed as quickly as possible.
For instance, if you entered a letter like "g" and then erased it, there
would still be traces of it on screen. I've made the assumption that
subtracting 1 from the font height is wrong everywhere.
We want first-in-first-out, not first-in-last-out. I thought I saw
Serrated Scalpel occasionally swap the order of two keypresses for me
while entering the name of a save game, but didn't think much about it.
Where it got really noticeable was when saving in Rose Tattoo. When
erasing an old save name, once I started entering the new name it would
process the new keystrokes first, then immediately process the next
pending backspace.
In some cases (e.g. when Lestrade greets you at the scene of the murder)
the talk window wasn't erased properly. This was a regression from a
recent fix for the inventory not being updated when certain objects were
added, e.g. when examining the pendant. See bug #10841.
Turns out that the fog horn sound at Lord Brumwell's mansion has the
same problem as the doorbell one. The file says 1100 Hz, but the
original clearly didn't play it at that. 11000 Hz seems to match the 3DO
version, so let's go with that.
When moving from one location to another, the Holmes icon should be
removed from the old location when travel begins. I've added a missing
restoreIcon() call, which seems to fix that.
