(bug no. 15030)
I have verified that neither the FM-Towns versions nor
INDY3 VGA have that mode. I don't know about Indy 3 EGA
(I presume not, but it would be worth checking).
I have verified (as can be seen in the ticket) that the original
seems to glitch on that new shadow mode in varying ways.
I haven't found the cause of it yet (current state of guessing:
glitchy text mask). And I am not sure if we need to replicate
the glitch, anyway...
My goal right now is to move all font drawing that isn't explicitly
handled by scripts into the Mac GUI. The Indy 3 speech boxes will
probably be moved into the Mac GUI as well, since they're a bit special.
This means the charset class will only have to keep track of the game
font, which will remove some odd special cases.
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.
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.
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.
- 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
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.
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.
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.
