This closes and fixes#11971:
"SCUMM: MANIAC/ZAK C64: GUI & dialog text are incorrectly
positioned on screen, and cursor is improperly layered"
The ticket also mentions improperly layered cursor:
"the pointer cursors pass *behind* the various character sprites
on screen", but there's really nothing we can do about it,
our cursor handling is way too different to function like the original
(and anyway, it looks like a severe C64 hardware limitation quirk...)
Poor Apple II version, it has been broken for at least a couple
of years :-)
All regressions were a byproduct of basically forgetting this
version existed when making changes which should have
(or should not have) targeted C64 games, which use the
same rendering routines and palettes as this one.
Fixes and closes#14765:
"SCUMM V0: MANIAC: APPLE II: Palette is incorrect."
(INDY3 (FMTowns): Map lines are drawn incorrectly)
This fix addresses the part concerning the line width of the travel
marker. Turns out that SCUMM3 FM-Towns draws all boxes one
pixel wider and higher on virtual screens other than 1. This also
allows removal of a hack in ScummEngine_v5::o5_drawBox().
I also fixed the old style pause/restart banners, since they incorrectly
used drawBox() for line drawing (which would be glitchy with the now
verdrawing drawBox(). The positive outcome is that we no have original
looking FM-Towns banners (only in Japanese, though, since - unlike the
original - we don't run the English version in 640x480).
The changed method of drawing and removing the banner also fixes
the removal of the black country borders on the map. But it will still
be removed below the pause banner and in the spots where the travel
marker passes the border. So that has to be addressed separately.
These include:
- Stray "-" characters (actually, "_") in dialogues
- Graphical glitches when scrolling dialog choices horizontally
With this commit we finally close issue #10447
Widgets are now proper objects. I'm back to the point where verbs work
again, but not the inventory. Still, this is too scary not to commit now
that it's beginning to work again.
This is still just a mock-up, and a bad one at that. It will all be for
nought unless I can figure out how to wire up these buttons to the SCUMM
verbs.
This does not improve anything about these modes for v2 and v3, except:
- brighter CGA colors
- v2 will also get the more accurate Hercules mouse cursor
I will do improve v2/v3 as separate tasks. v3 seems to be mostly fine, anyway, except for the actors (we dither them just like the backgrounds, but that looks different in DOSBox).
The original has it, although it isn't used. It is not meant for right to left languages, it just right-aligns left-to-right texts. Since I'll only use it for Hebrew I have to upgrade it a bit...
When using Straw To Gold (either on Loom island or in the Blacksmiths's
cell), the "gold" / "straw" texts overlap each other. This does not
happen in the original. Normally, script 8 would be responsible for
erasing that part of the screen, I think, but the Mac version does
things differently than the DOS version and I can't figure out how to
get it to work properly.
Maybe it's all down to differences in how we implement the
high-resolution text rendering in ScummVM? I'm adding a hack to fix it
for now, but if anyone has a better solution I'd be happy to see it go.
Fortunately, only two games use this, and the hack only affects one of
them. I've played through the game - again - without seeing any
regressions.
It turns out that checking the room height causes verbs not to be
redrawn after reading books. Let's just limit it to room 80, and hope
there aren't any other cases.
There is at least one scene in the game where inactive verbs are drawn,
and then the scene background is drawn over them. This should mean the
verbs are no longer visible, but the way we implement high-resolution
text on a scaled low-resolution background all text is assumed to have a
text mask on the text surface.
We work around this by only drawin verbs in standard rooms, where
"standard" is defined as being 128 pixels tall.
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.
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.
