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.
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.
