[Scummvm-tracker] [ScummVM :: Bugs] #16329: SCI: PQ2 Japanese PC-98 F1 help text not displaying (2.9.0 regression)

[ScummVM :: Bugs]

#16329: SCI: PQ2 Japanese PC-98 F1 help text not displaying (2.9.0 regression)
----------------------+-----------------------------
Reporter:  sluicebox  |       Owner:  (none)
    Type:  defect     |      Status:  new
Priority:  high       |   Component:  Engine: SCI
 Version:             |  Resolution:
Keywords:             |        Game:  Police Quest 2
----------------------+-----------------------------
Comment (by athrxx):

 I think the old comments can be a bit misleading. Regarding the one that
 gives the impression that we have to possibly switch the font for each
 text line in PQ2: The original PQ2 interpreter doesn't do that. Our code
 seems to be derived from the later interpreter versions (QFG, KQ5, SQ4)
 which actually have the font switch. The original PQ2 interpreter just
 keeps the English font and "measures" the width of a Japanese character by
 passing the first byte of a two-byte character to the normal/ASCII
 getCharWidth method. This is probably the main reason why the text
 placement looks differently in the original PQ2 interpreter compared to
 ScummVM.

 For `GfxText16::Box()`, I also use the SJIS check to determine whether the
 text field needs to be updated or not. The later interpreter versions
 (QFG, KQ5, SQ4) do it in a similar way. The box may not be updated for
 SJIS texts, since the hi-res text would just be overdrawn by the
 background (which is what's happening in this bug here). The original PQ2
 interpreter does not have that problem. Unlike the later versions it
 prints the SJIS text in text mode. The characters go to a different video
 memory of a different graphics chip and are totally unaffected by whatever
 happens in the other (graphics mode) video memory. And the text mode goes
 on top (when using an emulator, you can see that even the mouse cursor
 moves under the SJIS text).

 The PQ2 interpreter does not have specific handling for space characters.
 It doesn't do per-line SJIS checks either. Just before each character gets
 drawn, it will check if it is SJIS or not, and based on that it will
 either do normal SCI font drawing or text mode printing.

 Regarding that comment `Police Quest 2 PC-9801 often draws English +
 Japanese text during the same call`, it really depends on what "during the
 same call" is supposed to mean here. The engine definitely draws English
 and Japanese texts in the same box. Which is no problem for us to handle
 (if we get around the leading space character). Does it ever draw mixed
 SJIS/ASCII lines? I don't think so.  And the first part of the comment `We
 need to check for Shift-JIS every line` also seems to imply that (it
 wouldn't make sense to make per-line checks for mixed SJIS/ASCII lines).
 So, "the same call" seems to mean calls to `GfxText16::Box()` and not the
 calls to `GetLongest`, `Draw` or `Show`.

 Now, I could either make a fix that just ignores the leading space here
 (determine ASCII or SJIS mode by the next character). It would be a simple
 fix that could be limited to PQ2. Or I could attempt to push the SJIS
 check somewhere lower in the call hierarchy, so that it hits every single
 character. That one might be more prone to regressions. And as long as we
 don't know of any mixed SJIS/ASCII lines, there wouldn't be any testing
 either. Which approach would you prefer? I would suggest the first one. Or
 do you even have something different in mind?
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/16329#comment:3>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM