2025-06-13T01:44:22.301Z
I need to start writing up a proper draft of a blog post about the Wii U's output resolutions.
2025-06-13T01:46:44.500Z
I'll jot down some assorted (non-)verbal notes here
2025-06-13T02:58:50.499Z
I must preface this by saying: My in-depth analysis isn't yet finished. But with what I've observed so far...

1. In all cases I've observed thus far,** this is true: It seems the Wii U renders TV frames at 1280x720.*

*: 2. To talk a little more in-depth on this... The way the Wii U works, in memory it has a framebuffer for the frame that is (going to be) displayed on the TV, and it has a framebuffer for the Gamepad (DRC). By far the most common case is that the DRC framebuffer is 854x480 and the TV framebuffer is 1280x720.
For each of the two screens, that framebuffer gets passed to whatever part of the OS or hardware is responsible*** and that automatically takes care of upscaling or downscaling the image if necessary before encoding it into whatever format and sending it down the wire. (for the gamepad it gets encoded as an h264 video stream, for the TV it's whatever protocol used for HDMI or Component or Composite or whatever, the details on that conversion aren't especially important to what I'm talking about here...)

3. Example cases:
- For example 1, let's say the user has configured the Wii U to output to the TV via HDMI at 1080p. In all cases,** the game is rendered to the TV framebuffer which is 1280x720, then the system basically makes its own copy of that framebuffer and upscales it to 1920x1080, then the 1920x1080 version is what's sent down the wire via HDMI.
- For example 2, let's say the user has configured the Wii U to output to the TV via Composite video at 480i. Same as above, the game is rendered to the TV framebuffer which is 1280x720. Then the system takes a copy of that and downscales it to 480p/480i (specifically 720x480, don't ask...) then the 480p/480i version is what's sent down the wire. (I'd imagine the 480p version is sent to a DAC chip which converts it to 480i by removing half the scanlines, this detail's not important.)

**: 4. The TV framebuffer is 1280x720 in all non-hacked cases I've observed thus far. I say "all cases" instead of "all non-hacked cases" because the only exception I know of is SwipSwapMe, a homebrew plugin for Aroma custom firmware.
There's an OS function used by the application currently running in the foreground to send each of the screen framebuffers to be output to the TV and Gamepad. The SwipSwapMe plugin hooks and intercepts that function every time it's called, and allows the user to redirect the TV framebuffer to be output on the Gamepad and/or redirect the Gamepad framebuffer to be output on the TV.
SwipSwapMe doesn't do any image upscaling or downscaling itself; when SwipSwapMe sends the Gamepad framebuffer to be output on the TV, SwipSwapMe is sending a framebuffer of resolution 854x480.

***: footnote: I don't know the exact details about this. To clarify:
- Possibility 1 is that the code running on the main CPU basically passes the framebuffer at whatever arbitrary resolution to the GPU/DSP/whatever, and the GPU/DSP/whatever automatically takes care of resizing the image.
- Possibility 2 is that the code of the OS (specifically one of the system background processes running on the PowerPC) that I've mainly been looking at, well, maybe it's actually not interfacing with the AV output as directly as I think it is according to Possibility 1. And when I'm passing a framebuffer that's some arbitrary given resolution, I'm not giving it directly to the GPU/DSP/whatever, I'm actually giving it to some other function within the OS running on the PowerPC (or perhaps a function running on the ARM coprocessor) and THAT is the thing that automatically takes care of resizing the image before sending it to the GPU/DSP/whatever (and by extension sending it down the wire).
- Regardless of whether the truth is Possibility 1, or Possibility 2, or something in-between, or something else entirely (if my working theory is entirely off the mark)... My working theory is basically operating under the assumption that this image resizing process (a.) happens automatically and (b.) isn't directly within the control of whatever application is currently running in the foreground.

additional footnote: i basically only have reverse-engineered/decompiled binaries and existing documentation of the OS APIs to look at for information. exactly 0 of my knowledge here is derived from leaked source code or confidential internal documents. and for that matter, no Wii U OS source code or internal documents have leaked that are relevant to this, so i couldn't get information from those even if i wanted to.
2025-06-13T03:08:34.173Z
After reading all that...

Follow-up question: Is it possible via hacking/homebrew software to instead render something at 1920x1080 and send *that* down the wire to the TV at 1080p (assuming the Wii U video settings are set to 1080p obviously)? Or if we try to do that, will it be forcibly downscaled to 1280x720 before being re-upscaled to 1920x1080, thus looking just as bad as before?

Answer: I don't know. I haven't been able to conclusively test that yet. But I'm in the process of working on it. Getting stuff working is easier said than done.
2025-06-13T03:19:03.217Z
Here's an interesting additional note: I know of some cases (er, at least one case) where a retail Wii U game actually only renders to one 1280x720 framebuffer, and sends that framebuffer for output on both the TV and the Gamepad. So the logic I talked about with the automatic image scaling to the resolution of the TV, that also applies to the Gamepad. Note that the Gamepad screen has a resolution of 854x480, and obviously the Gamepad screen output resolution is not user-configurable like the TV screen output resolution is.
2025-06-14T04:04:13.809Z



2025-06-14T04:08:42.230Z





twist ending!
my working theory has been disproven
some games do, in fact, render at native 1080p.

and if the system is set to output in 1080p, you'll get the full quality 1920x1080p image.
the list of games that do this is pretty short, i've heard, but i'd like to test a bunch of them myself to make sure
2025-06-14T04:13:13.371Z
additional note: for Wind Waker HD in particular, the game always renders to a 1920x1080 framebuffer. if the system is set to output 720p, that 1080p framebuffer is still used but it's just downscaled to 1280x720 at display time.
interesting. also very cool how there's like no way to know about this other than doing a very thorough analysis
2025-06-23T02:28:43.918Z
i heard about this website / webpage today. it's the official website for the "Puyopuyo!! 20th Anniversary" video game. it has a tiny bit of Flash player content, but it's just ingame cutscenes (or ingame-style cutscenes) shown off as prerelease material.
https://puyo.sega.jp/puyopuyo!!/enjoy/manzai/01/index.html
2025-06-23T02:30:24.665Z
some puyopuyo nerds said it was already archived, at least in the form of a youtube video upload showcasing it all, but i wanted to double-check myself just in case...

lo and behold: the swf is just a thin wrapper of a video player for a given .mp4 file
classic
2025-06-23T02:34:29.333Z
and the .mp4 files retrieved by the SWFs are all already archived on the wayback machine, nice
2025-06-23T02:35:34.973Z
i did notice, the "01" mp4 was archived in 2013, the "02" mp4 was archived in 2017, and all the rest were archived in 2019. it appears someone had the same thought that i just did
2025-08-01T00:35:00.342Z

love it when i'm the only person on the entire internet who's experienced this issue
2025-08-01T00:38:07.405Z
3ds error code 003-0299. encountered when trying to connect my 3DS to a wifi hotspot hosted by my laptop running Linux Mint (basically ubuntu). note that i don't encounter this issue when connecting my 3DS to a wifi hotspot hosted by my laptop when my laptop is booted into Windows 10. so it's not a hardware issue on any front, it's gotta be a pure software issue.

"Wireless communication is currently disabled. Please enable wireless communication." (lie)
2025-08-01T00:55:29.902Z
hm...
2025-08-01T00:57:50.682Z
it might be an issue of, like, what security the hotspot is trying to use.

with the Win10 hotspot, on the 3DS i could connect to it just fine as expected when--for the "Security" option--i selected "WPA2-PSK(AES)".
but doing that with the linux hotspot that results in the aforementioned error.
however! instead selecting "WPA-PSK(AES)" seems to work, apparently.
2025-08-01T00:58:53.765Z
note: in linux, the security config for the hotspot looks something like this:

2025-08-01T01:01:11.908Z
the alternative available options in that linux UI are:
- None
- WPA3 Personal
- Enhanced Open

i tested so i know "None" just means it's open, no password required to connect, as you'd expect. dunno about "Enhanced Open" though. and i don't think the 3DS supports connecting to WPA3 secured wifi networks
2026-02-13T01:58:02.269Z
re: the stibarc records live show 2024 vod edit...
workin' on it.
i know i've been "working on it" for like a literal year now, apologies for not getting around to finishing it still,
sometime tonight or in the next few days i'm gonna be posting a rough-cut version of the edit, just so there's finally *something* out there
because i'm a perfectionist, the final edit has to be perfect, and i still don't think the final edit is good enough to be presentable, but i've got to put *something*--ANYTHING--out there at SOME point, preferably sooner rather than later...
so that's what i'm doing
2026-02-13T02:03:52.633Z
the audio is unfortunately gonna be jank as fuck in some parts, sorry about that, it can't be helped.
(well, not *much* anyway. it can be cleaned up quite a bit, with some slightly more hands-on noise reduction techniques in like Audacity or whatever. that's been the #1 most time-consuming part of the process, and really the only reason it's taken me so long to get around to finish it.)

2026-02-13T02:09:40.487Z
also, i say "get around to finishing it", because i've been working on it a little bit here and there for about 12 months now. working on it like 0-2 times per month on average.

for example, the last time i touched the project before just now was December 30th, before then it was December 10th, then December 2nd, then November 13th, then November 6th, then October 18th, and before then i had last worked on it i think July 3rd... and so on, and so forth.

2026-02-13T02:13:22.624Z
i don't know for sure, but evidence suggests the day i began actual work on it was February 22nd, 2025.

come to think of it, it would be really funny if i could finish the final edit and then publish it on the 1-year anniversary. not the 1-year anniversary of the original broadcast, but the 1-year anniversary of when i started working on editing the stupid thing
lol
2026-02-13T11:22:12.411Z
rough cut
https://www.youtube.com/watch?v=Hhack_OOnj8
2026-02-13T21:52:42.045Z
honestly forgot how nice it feels to finish things lol