Support for additional resolutions rather than hardcoded 1280*720.

[vaguerant]

SDL/src/video/wiiu/SDL_wiiuvideo.c

Lines 60 to 61 in 81eba84

	#define SCREEN_WIDTH 1280
	#define SCREEN_HEIGHT 720

SDL on Wii U currently runs at 1280*720 internally, while the Wii U can officially be configured to run at native output resolutions of 854*480, 1280*720 or 1920*1080. All three are fairly valuable, but native 480p in particular is important due to the GamePad. If I've understood the current situation correctly, SDL games designed to run at e.g. 640*480 would currently be forced to run at 640*480 scaled 1.5x to 960*720 scaled back 0.666...x to to 640*480 again for GamePad output.

Instead, SDL should support either running at an internal resolution that is configurable by the developer (which is then scaled to the actual output resolution) or running at the native resolution set on the console. This way, if an app absolutely only works at one resolution, the developer can enforce running at that resolution, otherwise allowing for flexibility. (Internal resolution could also be made an end-user choice if the SDL app's developer wishes to make it configurable, but that's just the developer configuration with extra steps.)

It may be desirable to allow manually configured resolutions to be arbitrary, i.e. not one of the native Wii U resolutions. Taking the example again of a game originally designed to run at 640*480, a non-native resolution like 1708*960 (sub-native for 1080p displays, exactly 2x native 854*480) would allow a 2x nearest-neighbor prescale (1280*960), for a sharper result on the TV than scaling from SDL internal res of 854*480 to 1920*\1080. At the same time, sending the same framebuffer to the GamePad would result in a native 480-line image. This would give nicer results than using any of the native resolutions.

I think that last paragraph can safely be considered a lower priority than just supporting the actual native resolutions of the Wii U. e.g. Running that 640*480 game with a native 480-line display would most likely be adequate for most purposes.

[vaguerant]

I'm not sure if this is related or a separate issue, but there seems to be some problem with the left side of the image when displaying 480-line content with a nearest-neighbor filter on the Wii U GamePad. This could be some issue caused by going from 480->720->480, so it's possible a fix here would resolve it entirely, but here's everything I know about it regardless.

I first heard of this issue from Archerite in the 4TU Discord, who encountered it in their BatteryCheck Wii U port:

With the naked eye, the easiest thing to note is that the background wall tiles (like bathroom tiles, not computer graphics tiles) are distorted when displayed via Wii U SDL.

For comparison, a clean shot of the same tiles:

Next, I encountered the issue in IntriguingTiles's SpaceCadetPinball-WiiU. In its default configuration, this port displays with the linear filter and no issue is apparent. I was trying to get a better picture out of it, with consideration of the limitations of SDL2 currently, so I made a small patch that forced the game to display at exactly 1.5x native resolution, so that the GamePad would get a native res display. While this broadly worked, it also made the GamePad left side pixelation issue Archerite saw appear in Space Cadet.

diff --git a/SpaceCadetPinball/options.cpp b/SpaceCadetPinball/options.cpp
index a196eb9..699d8d9 100644
--- a/SpaceCadetPinball/options.cpp
+++ b/SpaceCadetPinball/options.cpp
@@ -90,7 +90,7 @@ void options::init()
        Options.UniformScaling = get_int("Uniform scaling", true);
        ImGui::GetIO().FontGlobalScale = get_float("UI Scale", 1.0f);
        Options.Resolution = get_int("Screen Resolution", -1);
-       Options.LinearFiltering = get_int("Linear Filtering", true);
+       Options.LinearFiltering = get_int("Linear Filtering", false);
        Options.FramesPerSecond = std::min(MaxFps, std::max(MinUps, get_int("Frames Per Second", DefFps)));
        Options.UpdatesPerSecond = std::min(MaxUps, std::max(MinUps, get_int("Updates Per Second", DefUps)));
        Options.UpdatesPerSecond = std::max(Options.UpdatesPerSecond, Options.FramesPerSecond);
diff --git a/SpaceCadetPinball/winmain.cpp b/SpaceCadetPinball/winmain.cpp
index 647b4e7..2fcff12 100644
--- a/SpaceCadetPinball/winmain.cpp
+++ b/SpaceCadetPinball/winmain.cpp
@@ -90,7 +90,7 @@ int winmain::WinMain(LPCSTR lpCmdLine)
        (
                pinball::get_rc_string(38, 0),
                SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
-               1280, 720,
+               900, 720,
                SDL_WINDOW_HIDDEN | SDL_WINDOW_RESIZABLE
        );
        MainWindow = window;

900-720.patch.txt

GitHub doesn't accept .patch, boo.

Goofy speculation time: besides the 480->720->480 process possibly being problematic, another consideration is that the TV and GamePad do not technically have the same aspect ratio. 854*480 is only an approximation of a 16:9 aspect ratio, 16/9*480 = 853.333..., which is rounded to 854 on the GamePad LCD. Perhaps this fractional difference is throwing off SDL's nearest-neighbor filter, because mapping a 1280*720 window onto an 854*480 display involves stretching it horizontally by roughly .01%, and who knows what mess that could create.