SCI: KQ6: High resolution graphics mode scales text and low-res graphics unevenly (200→440 vertical stretch)

[dfabulich]

With "Enable high resolution graphics" turned on, KQ6 CD (DOS, or Windows) uses the Windows 256-color driver (engines/sci/graphics/drivers/win256col.cpp), which renders to a 640x440 screen. The 320x200 low-res graphics are doubled horizontally but stretched by 11/5 vertically, so every fifth source row is 3 pixels tall instead of 2 (the ty == 5 branch in largeWindowRenderLine()).

This is most visible in text. For example, in the opening beach scene, in "Broken pieces of Alexander's ship litter the beach.", the "e" in "Broken" has a 2px-high crossbar and a 1px-high vertical stroke, while the "e" in "beach" is drawn correctly. Glyphs look different depending on which row they land on.

The original Windows interpreter has the same artifact, and #12069 already aligned ScummVM's row mapping with the original. So this is faithful, but it's unpleasant.

[athrxx]

So, should we just have an option for the SCI1 Windows targets not to do the ugly upscale?

For the other (non-KQ6) games this can already be achieved easily by setting the platform to DOS instead of Windows. But that will block the access to the Windows 16 colors mode. So even there it might be nice to have such an option.

For KQ6, in hires mode, it would change the proportions between the hi-res content and the background. I have never tested that concept, so I don't know if it would work (it probably would). But it might be less disturbing for some users than having the upscale artifact.

[athrxx]

I have added a screenshot that shows the upscaling artifact in LB2.

[dfabulich]

​https://github.com/scummvm/scummvm/pull/7964

[dfabulich]

My PR 7964 is restricted to KQ6; I think that's the only SCI1 game that needs this fix, but I'm a little hazy on all the variants of games that are available, so I'm not 100% sure about that.

KQ6 CD has high-resolution character portraits designed to render at 640x440 that are only available in Windows mode. Windows mode takes all the low-res art, targeted at 320x200, and applies ugly upscaling to render everything at 640x440. My PR 7964 enables KQ6 to run with the best of both worlds: high-resolution character portraits without ugly upscaling. But it comes at a cost: the game renders at 3200x2200, to ensure that we can multiply the dimensions of the high-res 640x440 art and the dimensions of the low-res 320x200 by integer factors.

For the versions of the Windows SCI1 games I have on my machine, for Laura Bow 2 CD, EcoQuest 1 CD, EcoQuest 2, Space Quest 4 CD, they all have the option to run in Windows mode, and this makes them all do ugly upscaling, but there is almost no benefit in running in Windows mode; none of them have high-resolution character portraits to sync up with.

(LB2 CD, EQ2 CD, and SQ4 CD all offer "Windows cursors," greyscale cursors that IMO don't look as good as traditional VGA cursors. EQ1 CD doesn't even offer Windows cursors; switching to Windows simply enables ugly upscaling, at no benefit at all.)

For those games, I think users who don't want ugly upscaling should just switch to DOS mode. DOS mode is a much better way to disable ugly upscaling than rendering at 3200x2200.

On the other hand, I did find a couple SCI32 games that would also benefit from this approach: Gabriel Knight CD, and Police Quest 4. I have a stacked PR that would add this setting to those games as well. ​https://github.com/dfabulich/scummvm/pull/1

[sluicebox]

I typed a thoughtful resposne to this ticket until I saw the AI slop PR. Now I hate myself for wasting my time and am once again considering rage quitting this project.

[dfabulich]

My PR was closed.

The PR was AI assisted and disclosed as such, as required under the rules of the repo. ​https://github.com/scummvm/scummvm/blob/master/AI-GUIDELINES.md Everything I've written here on the ticket was written by hand, and I wrote the commit message by hand.

I fully understand the code that the PR changed. It's not even very much code. I could walk you through it on a whiteboard in a coding interview.

If it would help, I'm happy to rewrite it by hand.

On Github, sluicebox had this to say about the PR:

my first thought is that no one would ever want this. my subsequent thoughts are unprintable.

bluegr added:

Nobody would want this, and this insanely high resolution (for an old game) would only work for users with 4K monitors.

This isn't correct. The 3200x2200 image is only an internal buffer, and the OpenGL backend shrinks it to whatever window you have. On a 1080p monitor, KQ6 in this mode opens at 1570x1080. I've attached a screenshot at 1080p.

Of course the PR looks the very nicest on displays that can render 3200x2200 natively, including my own MacBook Pro, but a 4K monitor isn't required to enjoy the benefits of this fix.

I also took a minute to test the PR on the most underpowered device I have that supports ScummVM, a Samsung Galaxy A15 Android phone. ​https://browser.geekbench.com/android_devices/samsung-galaxy-a15-5g Its single-core performance is 7x slower than my laptop, and its GPU is slower by more than 100x.

It performed just fine. I watched for dropped frames and audio stuttering and didn't see any. I've attached a screenshot from the phone, too, rendered at 1570x1080. I didn't do an end-to-end playthrough on Android (but I absolutely would, if that would help somehow).

Overall, I don't understand how sluicebox and bluegr could both agree that "no one would ever want this." I assume that doesn't mean "nobody wants bug 17254 to be fixed," since the ticket is still open.

Before submitting the PR, I played through King's Quest 6 manually on my branch, and it was fantastic, by far the best experience I've ever had playing KQ6, a game that I've loved for 34 years.

Getting the high-resolution portraits working with correctly scaled text made the whole thing magical. If you love this game even half as much as I do, I wish you'd give it a try.

I considered rendering at 640x400 and downscaling the portraits to fit, but the portraits are drawn pixel by pixel (including single-pixel catchlights in the eyes, for instance), and any 440 -> 400 shrink either blurs or drops those details. That's why I went with the large buffer.

I'm open to other approaches! Is there any implementation that would fix this bug and that you'd be willing to consider?

[GermanTribun]

Setting all the other issues apart, the basic premise still stands that Sierra games with mixed low- and hi-res art scale the low-res art horribly into the hi-res frame, creating many artifacts.

The question should be, is there some way to do the in-game scaling smoother so the artwork is not dagraded? And I mean a reasonable way.

[eriktorbjorn]

@sluicebox "I typed a thoughtful resposne to this ticket until I saw the AI slop PR."

Pity, I would have read it.

@GermanTribun "The question should be, is there some way to do the in-game scaling smoother so the artwork is not dagraded? And I mean a reasonable way."

Alternately, is there a way to use the higher resolution graphics without also stretching the lower resolution ones? I think some games allow it, but that may not be possible in this particular case? (I wouldn't know because I've still only made it to King's Quest IV. I should play VI, because I hear it's a good one, but I've also heard V is a bit rough so I've been putting it off for years. Sierra games intimidate me.)

[dfabulich]

I tried that, actually! The problem is that KQ6's code assumes that the low-resolution graphics _are_ being stretched. So I starting fixed bug after bug after bug: rendering garbage on the screen after dismissing the opening "Sierra" movie, opening and closing the icon bar, misaligned inventory.

ScummVM has a few script patches checked in, but this would require a _lot_ of script patches.

I gave up on it after a while, but I guess it's possible in principle to find (gulp) all of the bugs and fix them.

A simpler approach would be to render render 320x200 graphics to 10x11 pixel blocks (matching the original Windows release's 1:1.1 pixel shape), and 640x440 graphics to 5x5 pixel blocks, using OpenGL to rescale the resulting image to fit the user's window. That wouldn't require a massive bug hunt.

Would anyone want a PR like that?