[Scummvm-tracker] [ScummVM :: Bugs] #17254: SCI: KQ6: High resolution graphics mode scales text and low-res graphics unevenly (200→440 vertical stretch)

[ScummVM :: Bugs]

#17254: SCI: KQ6: High resolution graphics mode scales text and low-res graphics
unevenly (200→440 vertical stretch)
----------------------+-----------------------------
Reporter:  dfabulich  |       Owner:  (none)
    Type:  defect     |      Status:  new
Priority:  normal     |   Component:  Engine: SCI
 Version:             |  Resolution:
Keywords:             |        Game:  King's Quest 6
----------------------+-----------------------------
Comment (by dfabulich):

 > Which games are affected anyway?

 King's Quest 6 CD and Gabriel Knight 1 CD are the most affected. They have
 high-resolution portraits on the same screen as low-resolution text. (The
 ugly upscaling is most noticeable on text.)

 Police Quest 4 is also affected, but it's not as bad, because PQ4 renders
 text separately at high resolution.

 Laura Bow 2, EcoQuest 1, EcoQuest 2, and Space Quest 4 all do ugly
 upscaling in Windows mode, but they have no high-resolution content, so
 there's no benefit in using Windows mode. Players should just switch into
 DOS mode to turn off ugly upscaling.

 > I'm not sold on the idea to have the backend scale down the image, but
 maybe I'm old-fashioned. I don't even use the OpenGL backend.

 PR 7964 works fine in the SDL backend, but it does trigger longstanding
 bug #10286. (ScummVM's menus render too small when the game is larger than
 the window; any 640x480 game at 5x does this too.)

 That's why my PR documentation recommended OpenGL; switching to OpenGL
 works around that bug. (I'd be delighted to fix #10286 if that will help
 get PR 7964 merged.)

 > Would it be possible for the engine to scale it to a sensible resolution
 (smaller or equal to the final resolution), or would that be too slow?

 I believe PR 7964 is the optimal fix for this bug, in performance and in
 code complexity, but, yes, it is possible to fix this in other ways.

 First, note that in the scaling factors I'm using (10x11 and 5x5), 5 and
 11 are prime numbers. There are no smaller "sensible" scaling factors that
 we can apply to the low-resolution art and the high-resolution art that
 will render perfectly.

 Rendering at a smaller resolution than 3200x2200 will inherently have to
 blend neighboring pixels. (That's what OpenGL/SDL does on the GPU on my PR
 branch in the 1080p screenshots I posted above.)

 It's certainly possible to blend neighboring pixels on the CPU, but the
 major obstacle is that, as ScummVM is currently architected, the engine
 doesn't know what the actual window size is. We'd need to provide that
 data to the engine, and react to resizes by reinitializing graphics mid-
 game.

 I'd be willing to implement something like that, but it's hard to imagine
 merging a PR with such a substantial change just to fix this bug.

 FWIW, I did take a crack at implementing scaling in software, hardcoded to
 1080p (1571x1080), and measured average CPU load.
 https://github.com/dfabulich/scummvm/commit/091e2395d1344784b502ce9c2680eff6b6b77cfc

 Average CPU load was about the same: 16% of one CPU core when software
 scaling, compared to 15% of one CPU core with OpenGL scaling. Software
 scaling also sent a much smaller screen to the backend, which consumed
 less memory.

 The performance of software scaling was substantially worse for palette
 fades. In my PR 7964, a palette change is just a new palette sent to the
 backend, and OpenGL applies it on the GPU. When using software scaling,
 every fade step has to rescale the entire screen. Fade steps took 6ms per
 frame on my MacBook Pro. I didn't test on Android, but I'd expect ~40ms
 per frame on my low-end A15 Android phone.

 Fundamentally, I think the question is: what technical problems does the
 team see with the PR I filed? bluegr and sluicebox agreed that "nobody
 would want this," but I still don't understand what that means.

 Is the problem that this bug is unimportant, and so it's not worth ~100
 lines of new code? If the problem is too much code, software scaling would
 be going in entirely the wrong direction. My software scaling commit adds
 another ~100 lines of code. Adding support for resizing the window would
 surely be substantially more code than that, and would include changes to
 the engine interface.

 Is the problem that rescaling 3200x2200 to 1080p on the GPU doesn't
 perform well enough? (Too much CPU? Too much RAM? Too much GPU?) If so,
 software scaling seems like it's going in the wrong direction from optimal
 performance.

 I'll be the first to admit that "3200x2200" sounds ridiculous. But it
 performs great, even on low-end small-screen devices, and the patch is
 small and targeted.
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/17254#comment:12>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM