I'm committing this as is, while leaving final integration to someone
else. Note that this doesn't really replicate the original Mac GUI (e.g.
the quit dialog is nothing like the original), but at least the pause
dialog looks right. And that's what matters to me.
MacFontManager didn't have a mechanism to report which fonts it loaded
from an external resource. It also requires that any fonts that aren't
built-in be explicitly registered by name by the client before they can
be used. This combination meant that a client couldn't load fonts from
an external file and use them by their properties (id / size / style).
SCI contains Mac fonts in its executable along with a table that maps
each SCI font id to a Mac font id and size. The font name isn't a part
of this since the Classic Mac Toolbox API took id / size / style as
input when drawing text.
Now MacFontManager exposes the font families it has loaded along with
their names. This allows a client to see which fonts were loaded,
register them by name, and proceed to use them with the existing API.
I am going to clean this up a bit after confirming the behavior of the other v1-3 games. I bet that it it is the same thing (only that it probably doesn't matter, due to the text display being restricted to the top of the screen and the verb screen).
("Inaccurate verb rendering in Monkey 1 FM-TOWNS)"
Actually, this is rather an emulation of an original bug than a fix...
I have also included a fix in the charset renderer that I noticed, but I don't think that one actually matters anywhere.
I haven't added a fix for exisiting saves. It would require another version bump and it is really not important enough.
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...
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.