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...
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.
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.
This is more guesswork, but seems to match the original for where I've
tried it. Next step is to implement an option to use the correct spacing
instead since it arguably looks better.
Measure the whole string before dividing the length by 2 to get the
low-res width of the string. Before, each character width was divided
which led to rounding errors. The result is better, but not pixel
perfect. I'm not sure what I'm still getting wrong.
The text positioning seemed to be correct in all cases I checked (which
admittedly weren't all of them). The original spaces characters
differently, but I would say that the original does it wrong. I typed
the same text in ResEdit, and it came out the way ScummVM draws it.
I see no reason for being that bug compatible with the original.
I didn't think anyone would notice that the lines of the Indy 3 text
boxes were spaced slightly differently in ScummVM than in the original.
I realized it wouldn't be as tricky as first thought to fix that, though
I may clean it up a bit later.
This fixes a tiny part of bug #12983.
- removed obsolete (and incorrectly implemented) COMI Chinese handling
- some preparations to make it easier if we would want to get rid of SmushFont::getStringWidth() in favour of this
It should only return the actual font height for Indy 3's font 1, and
even there it's not actually needed at the moment. I'm guessing this
error is why I saw some text rendering errors in Mac Loom, where lines
of text were spaced too far apart. Though strangely, I never managed to
reproduce it.
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.
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.
Eugene Sandulenko
Orgad Shaneh
Andrea Boscarino
athrxx
Torbjörn Andersson
trembyle
Alexandre Detiste