2025-01-20T19:19:47.355Z
test
2025-01-20T19:40:21.357Z
https://forums.tomshardware.com/threads/android-not-connecting-via-usb-3-0-but-usb-2-working-fine.3155237/

"Iv got 2 LG devices the G5 and G6 both will not connect to my PC via USB 3.0 I plug them in and they just charge no option for USB on the phone and not showing up on my PC at all not even in device manager[.]
But if I plug the phones in to a USB 2 port it will work fine every time"

classic. niche issue thread that got closed as "solved" due to inactivity. this is an issue for me btw.
2025-01-22T23:50:40.726Z
gaming
2025-01-24T02:44:31.387Z
i think i have a good intuition for taking a close look at things, poking around and dissecting, then spotting things and saying "this looks important" or "this looks interesting"

my weakness is that i never have enough knowledge of the subject (like any specific assembly language, win32 APIs, C# in general, etc.) but my strength is in being able to loosely connect the dots despite that lack of knowledge
2025-01-28T20:50:00.024Z
random potential project idea of the day:
i wonder what sort of hacks it takes to get Steam fully (or almost fully) working on Windows 7 and Windows 8 these days.

i'm almost certain that you could get any installed game to run, without needing the main Steam program fully 100% working. maybe via certain trickery using an older version of Steam (or the Steam DLL in the game files). or maybe by using one of those Steam DLL emulators / replacements that people use to bypass Steam's regular DRM that a lot of games use.

(note: plenty of games don't use Steam's DRM at all. for example, the Steam releases of main-series touhou games, allegedly, last i heard. literally just run the EXE on any computer, no need to be logged-in to Steam.)

as much as i respect it, doing so for the purpose of bypassing DRM is a different question that i personally don't care about. i'd be more interested in getting the main Steam client application (and Steam DLL, if necessary) working as well as possible on Win 7 / 8 / 8.1. and reverse engineering the client, perhaps patching it to bring it up to date with the still-supported Windows 10/11 version, maybe patching it to use Supermium (https://github.com/win32ss/supermium) instead of Chromium, etc.

as always, a lot easier said than done. i might never decide to work on that, which is common. just a random spitball idea i could theoretically do.
2025-02-08T05:52:42.422Z
I plan on doing a little bit of datamining of Pokemon TCG Pocket
2025-02-08T05:58:33.200Z
(both the android and the iOS version)
2025-02-08T06:03:36.289Z
I'm not gonna do an exhaustive analysis, I'm mainly just interested in trying to dump some textures
2025-02-08T18:45:45.864Z

y'know, there's something to be said about the way Windows does so much baseless fearmongering that it actually backfires and trains its users to ignore *real* security concerns.
2025-02-08T18:53:46.486Z
*security concerns as well as other concerns. obviously that image isn't related to cybersecurity, it's a matter of potential data corruption, but it's the same principle. Every time I remove a USB drive without going into the badly designed UI to click "Eject", the "dirty" flag of the drive's filesystem is set, and Windows will display this notification when the drive is next plugged in. But 99.98% of the time, the data on the drive is literally completely fine (except perhaps if you were using ExFat, because that filesystem sucks balls and is super prone to mass data corruption...). So I completely ignore that notification every time it pops up, and sometimes I even make fun of it. 10 years of false flags of "WARNING!! WARNING!! DRIVE CORRUPTION!! CLICK HERE TO SCAN NOW!!" have trained me to completely ignore such warnings. This is an example of a broader issue with software (and UI) design.
2025-02-08T20:53:36.941Z
in the next hour i'll hopefully fuckin *finally* get around to dumping my friend's CD-ROM/DVD-ROM(?) copy of Microsoft Office FrontPage 2003 Academic Edition
2025-02-08T20:56:11.129Z
*it is in fact a CD-ROM
2025-04-15T00:50:01.849Z
had an issue with the Discord app on Linux, here's a text dump of my bug report:
2025-04-15T00:51:15.015Z
# Description

For the record, I've already figured out a workaround and the Discord app is now working again on my laptop. So I don't need help, I'm just reporting this bug.

(Read the Steps to Reproduce and Result sections...)

But that's just the way the issue *manifests*... That's probably because of a weird version number mismatch, where my version 0.0.90 Discord app wants me to update to a version that calls itself 0.0.89 but the .deb package installer GUI doesn't want to let the user downgrade a package.

The workaround I used is as follows:
1. The most recent update, I downloaded and renamed the file "discord-0.0.89 (2).deb" (because I still have the past few Discord app update .deb files on disk.)
2. In a terminal window, I ran ```sudo dpkg -i 'discord-0.0.89 (2).deb'``` and the package downgraded successfully. (See image attachment 3.)
3. I launch the Discord app, and it does the usual post-update process ("Downloading update 1 of 6" and "Installing update 1 of 6" etc.) and then seems to work perfectly without a hitch.

Additionally, refer to image attachment 4 to see the approximate release dates of the previous few Discord app versions (I use Discord on my laptop almost every day).

I don't regularly check my email, so I've uploaded a .tar.gz file containing the self-contained .deb packages of 0.0.88, 0.0.89. 0.0.90, and 0.0.89(2) on Google Drive. I've done this in advance in case anyone on the dev or support teams might find it useful. The files are available here: https://drive.google.com/file/d/1HDyjhXn8TEVx0XCP7UEg1OHXhMX0-K7V/view?usp=sharing

Pre-workaround Discord app 0.0.90 version info:
[unknown] (can't get into the Discord app proper to see it...)
Post-workaround Discord app 0.0.89 version info:
stable 389335 (8ebfee0) Host 0.0.89 x64 Build Override: N/A Linux 64-bit (6.8.0-57-generic)


# Steps to Reproduce

Using Linux Mint Xfce version 22(?) (based on Ubuntu)

Had previously installed the following updates as they released:
- discord-0.0.88.deb
- discord-0.0.89.deb
- discord-0.0.90.deb

Had version 0.0.90 installed at the time of the issue occuring.

Launch the Discord app, see the common "new update is available" message. (See image attachment 1.)

Click the button which sends me to https://discord.com/api/download/stable?platform=linux&format=deb as usual.

Using Firefox (or other web browser) save the file, then double-click it to open a .deb package installer GUI...


# Expected Result

Usually, the .deb package installer GUI shows a green button that says "Install Package", and I click that to install the update, input my laptop's root password, and everything goes smoothly as one would expect.


# Actual Result

Instead, in the .deb package installer GUI... That button which would usually be green is instead greyed-out and unclickable, and there's a red banner that reads "Error: A later version is already installed". (See image attachment 2.)


# Discord Client Info

[refer to the Description section]


# Attachments
...




2025-04-27T09:59:14.876Z
https://www.gamebrew.org/wiki/R4_Cheat_Code_Editor
i should consider reimplementing this software
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