Aspect ratio and resolution issues on 2.2.1 pre

[notimp]

This is a rather complex problem to approach - but as I like the Wii version of ScummVM very much, I would be thrilled if it could be tested and fixed in future versions.

The issue lays with analogue video modes and how they are handled on the Wii build.
The Wii supports 4:3 and 16:9 video output modes both of which output an SD signal, that in the 16:9 case has to be stretched by the TV itself.

For the issue description, lets stick to Wii screen settings of 4:3 and 480p as 'the desired' output format - where ideally scaling would fall in line with the best possible result.

This is how the Wii port is conceptualized currently, because if I chose 16:9 and 480p in the Wii display menu - the current sliders in ScummVM (custom Wii menu) for stretching and shrinking x and y axis of the image dont allow to even get close to a 4:3 aspect ratio, regardless of slider settings, because the x axis remains too wide (stretched to 16:9 by the tv) - lets ignore that for now (even call it desired behavior), as most ScummVM games are 4:3 anyhow - so starting up ScummVM in 4:3 480p would be desired anyhow (less stretching).

The issue now becomes, that its currently impossible to get a correctly scaled 640x480 (so 480p) image out of the console.

Tested with Broken Sword 1 and other games, but Broken Sword is a good testcase, as it is 640x480 natively.

Bug description.

When booting up Broken Sword 1, with both (Wii specific) ScummVM Menu sliders for image adjustment (wii_video_default_underscan_x and y) zeroed, you'll notice, that the output is weirdly stretched on the x axis. Even when aspect ratio correction is on, which is probably superseeded by the "wii_video_default_underscan_x and y" implementation.

This wouldn be such an issue, if you could expand the x axis, but you cant (already maxed out), you so have to start to reduce image height in the y dimension (usually by 8 or more in the wii_video_default_underscan_y option), which results in not the entire 640x480 resolution being able to be used for the game to be displayed.

This not only causes image degradation, but entire lines of the signal being discarded, which in Broken sword (native 640x480) shows up in distortion on dialogue text (you have to enable speech and text in ScummVM settings), on some dialogue lines, where the text renders missing the last line of pixels and looks cut off. You can also see it as line blacking (and cut off lines), on the looking glass symbol in the same game, when moved across the screen vertically.

Its reproducible in the intro sequence of the game (first 15 minutes or so), so it shouldnt be hard to replicate.

Now, here comes the proposal. While I understand the need for ovescan compensation (underscan) on consoles that only support analog signal out - the current solution, very easily - and actually by default breaks aspect ratio correction (at least on games where pixels are supposed to be square (so Broken Sword 1). The workaround that was suggested by people for three years now ( ​https://forums.scummvm.org/viewtopic.php?f=16&t=14342 ), namely setting wii_video_default_underscan_y to 8 or higher, cuts into the available vertical resolution, which in itself causes large issues with native 640x480 games.

Please provide, at least one mode, where with the Wii set to 4:3 and 480p aspect ratio correction (ScummVM feature) gets applied correctly and the entire 640x480 resolution is used for image content (with no overscan compensation (underscan) in place).

Most of the TVs available today are able to be set to 'just scan', where no overscan in image content is expected, and thereby display 640x480 games correctly (At least in 480p output mode on the Wii). This would be expected behavior, and results in the highest quality output possible (integer scaled or native 640x480 resolution images) - currently, the default output is broken aspect ratio wise, and the workaround cause even more substantial issues (lines of pixels missing)). Leave the other mode in there as well, for people that actually have to apply overscan compensation.

I hope that I've laid out the issue in as much detail as needed to understand it, and would love to see this addressed in the future.

I also understand, that seeing the behavior isnt as easy on a 4:3 CRT (and all of the Wiis outputs are analog.. ;) ) but with even a decent sub 100 USD scaler like the OSSC the described behavior (and the issues it causes currently) very much become obvious.