Hacking USB Loader GX

[NoobletCheese]

About the video width, if the game is set to 640, I guess it's a matter to try and change it to 512, which should be the closest thing to a 256x240 of the usual nes game.

512 appears to be the correct value for square pixels, but seems to need +10% to correct for NTSC pixels being 10% skinnier, i.e 564, at which point objects like squares and circles measure symmetrical.

Unfortunately, touching viWidth causes garbled video output on Wii (but not on Dolphin) so it's a dead end unfortunately.

I did also play around with fbWidth for hours in tandem with viWidth on Dolphin to see if there was some magical combination, but no.

There is something broken at a deeper level with this port, maybe the tile size is wrong or they prescaled the assets wrongly. Whatever it is, you can't compensate by modifying width. I tried nudging window width in Dolphin 1px at a time too, without effect.

The only thing that worked was setting Dolphin to a higher internal rendering resolution like 2x/3x/4x, then the alignment discrepancy diminishes by the x multiplier to the point of being unnoticeable.

Theoretically if we could increase fbWidth to a high enough value it should work on the console too, since that also improves it on Dolphin, but causes garbled video output on the console.

It's a pretty bad port imo, plagued by incorrect aspect and scaling artefacts. I don't think I could enjoy it.

 

[Maeson]

Actually, Wii fixed version with 480p support is by far the best of the original releases if you ask me. The ps3 and 360 versions were extra blurry, probably to hide the pixel thing too as they were badly scaled too. And looking to the newer collection, it seems the scale issue is still a thing? There's people complaining at it on steam at least... I guess Capcom devs had no idea of what they were doing with it...

Nonetheless, making rut in progressive is a huge upgrade for me, as I said it's much more bareable all around. The pixel width is far less noticeable than on interlaced, and now that can be progressive we can remove the filter to make it look sharper without suffering interlaced flicker.

I think we should go to the other thread, this is kinda out of place on this.

 

[ukigh4ie]

@blackb0x I am using your latest mod. I cannot download the ocarina codes for Tales of Symphonia Dawn of the New World [RT4EAF], although they are available on https://codes.rc24.xyz/index.php?c=RT4EAF. The proxy is configured in the WiFi profile of the console and its usage is enabled in the USB Loader settings.

What could be the cause? What diagnostic data do you need for an analysis?

 

[blackb0x]

What could be the cause? What diagnostic data do you need for an analysis?

Can you go into your WiFi settings and have it perform a connection test? If that passes then the loader should be able to use it as long as it's a HTTP/HTTPS proxy.

I guess it's also possible for the proxy server to reject the user agent, but that shouldn't really happen.

 

[ukigh4ie]

@blackb0x

I guess it's also possible for the proxy server to reject the user agent, but that shouldn't really happen.

I see the request in the proxy's logs. Since it is HTTPS, the requested path is not logged.

1621868991.144    668 192.168.55.83 TCP_TUNNEL/200 15357 CONNECT codes.rc24.xyz:443 - HIER_DIRECT/104.26.0.213 -

Can I somehow activate the logs in the USB loader?

 

[blackb0x]

Can I somehow activate the logs in the USB loader?

No, it's compiled without debug info. I can send you a version with it activated.

 

[SuperrSonic]

However I don't think I could accept this version of the game even if I got it running at 480p as I notice it seems to have some kind scaling error with the pixel alignment being slightly off, noticeable when graphics are scrolling horizontally they seem to get wider and skinnier and wider again.

The game uses the value set in viWidth for additional scaling (on top of the scale done by the VI) so to achieve a pixel-perfect image VI scaling has to remain disabled.

The scrolling artifacts happen in 4:3 mode because of the 512->640 scale, while in 16:9 mode it happens because 512->492.

I made these codes for NTSC-U Mega Man 9, for anyone interested.

Mega Man 9 - NTSC-U WiiWare

Game width1 640 to 512
203016b0 028001e0
043016b0 020001e0
e0000000 80008000

Game width2 640 to 512
2039b264 028001e0
0439b264 020001e0
e0000000 80008000
//Both must be enabled to work correctly. Wii must be set to 4:3 mode.

Game width1 492 to 512 (Wii set to 16:9)
203016b0 028001e0
043016b0 029a01e0
e0000000 80008000

Game width2 492 to 512 (Wii set to 16:9)
2039b264 028001e0
0439b264 029a01e0
e0000000 80008000
//Both must be enabled to work correctly. Wii must be set to 16:9 mode.

480p NTSC
28295b94 00000280
00295b93 00000002
00295ba7 00000000
e0000000 80008000

No Deflicker
28295bc2 00000808
06295bc2 00000007
00001516 15000000
e0000000 80008000

Looking at it closer there is a faint dither pattern on the stage backgrounds. Just a pointless observation.

Spoiler: MM9 512x480

These codes have only been tested up to the level intros. I do not have the patience to play it through.

 

[Maeson]

With that code (well the first two), it looks perfect now!

Looking at your code, when I tried to alter the video Width, I edited both instances of "02 80 01 E0" for each video mode inside the 00000001.app file, while your code seemingly only alters the second one. I will mess around and see if changing only the second one gives me the desired results. If it does, we could also edit Mega Man 10 to get it to the same state.

I can't believe that after such long time I'm finally getting to fix MM9 and MM10. It's exciting!

Edit: Okay, that did not work. At all, I get a messy green screen. Oh well, it'd be nice to have a code for 10 then...

Edit: Code for 10 was made, look here.

 

[bikerspade]

On the Wii the only 1 usb chord works fine, on wii u i dont know.

Initially I had issues with homebrew seeing this drive. I discovered this 1TB drive defaulted to using a GPT partition table instead of MBR. Deleting the default partitions and converting to MBR resolved that issue.

 

[NoobletCheese]

That might work, but it'd probably be better to look at Swiss and copy how it's done there.

It appears Swiss's patcher wouldn't work for Wii titles as none of its patching signatures appear to match:

https://github.com/emukidid/swiss-gc/blob/master/cube/swiss/source/patcher.c

FuncPattern GXSetCopyFilterSigs[5] = {
       { 567, 183, 44, 32, 36, 38, GXSetCopyFilterPatch, GXSetCopyFilterPatch_length, "GXSetCopyFilterD" },
       { 138,  15,  7,  0,  4,  5, GXSetCopyFilterPatch, GXSetCopyFilterPatch_length, "GXSetCopyFilter" },
       { 163,  19, 23,  0,  3, 14, GXSetCopyFilterPatch, GXSetCopyFilterPatch_length, "GXSetCopyFilter" },   // SN Systems ProDG
       { 163,  19, 23,  0,  3, 14, GXSetCopyFilterPatch, GXSetCopyFilterPatch_length, "GXSetCopyFilter" },   // SN Systems ProDG
       { 130,  25,  7,  0,  4,  0, GXSetCopyFilterPatch, GXSetCopyFilterPatch_length, "GXSetCopyFilter" }
   };

typedef struct FuncPattern
{
   u32 Length;
   u32 Loads;
   u32 Stores;
   u32 FCalls;
   u32 Branch;
   u32 Moves;
   u8 *Patch;
   u32 PatchLength;
   char *Name;
   u32 offsetFoundAt;
} FuncPattern;

From the disassembly of Wii's version of GXSetCopyFilter here we can see its signature is {484, 55, 13, 0, 4, 0} which isn't in any of Swiss's. [edit: it appears Swiss's length value is number of instructions not bytes, however it's a moot point]

I've also done extensive searching of substrings of Wii's version in GameCube titles and not found any matches -- it appears GameCube's version is totally different.

It is still possible that some Wii games are using a different version to the one in the assembly linked above, however none have been discovered so far. It seems we got lucky and the func just happens to have an extremely consistent signature between Wii games, with only 2 bytes varying from game to game.

edit: I suppose we could just add the new signature {484 121, 55, 13, 0, 4, 0} to Swiss's sigs and then it should work? Although I'm still unsure if Swiss's replacement version of the func (GXSetCopyFilter.s) is compatible with Wii... it seems to be using the same registers as Wii for it's boolean args (3 and 5) so perhaps it would. However it uses some hardcoded memory addresses in reserved.h which I'm not necessarily sure are the same for Wii.

 

[blackb0x]

edit: I suppose we could just add the new signature {484, 55, 13, 0, 4, 0} to Swiss's sigs and then it should work? Although I'm still unsure if Swiss's replacement version of the func (GXSetCopyFilter.s) is compatible with Wii... it seems to be using the same registers as Wii for it's boolean args (3 and 5) so perhaps it would. However it uses some hardcoded memory addresses in reserved.h which I'm not necessarily sure are the same for Wii.

As I'm sure you're aware, the loader already contains code to search for and replace video modes. So it's possible to create a custom video mode, but it doesn't work consistently because it depends on libogc knowing about every video mode that a game uses. And that right there is why I'd like to remove all of the old code and replace it with something that's much more reliable.

You can't debug video related changes made by the loader without a USB Gecko, which is something that I don't own. So that means that I'd need to eyeball any changes, which is less than ideal and I'm really not looking forward to it. But if I get it done and it works then I'd be happy.

edit: got it working by changing loader IOS from 58 to 249. Stock ULGX is still using 58 without issue.

I guess you mean Cyan's r1272 release? That uses IOS58, but it causes old forwarders to stop working.

The original version of the loader is built with a version of devkitPro that's 5 years out of date. So to debug the issue I'd need to compile a few test versions, if you're willing to try them? It'd likely benefit others who might also have issues with the loader freezing during boot.

Just yesterday I fixed a long standing issue where the pointer would either feel slow or would go in the opposite direction when using a classic controller or a WiiU gamepad.

 

[NoobletCheese]

The original version of the loader is built with a version of devkitPro that's 5 years out of date. So to debug the issue I'd need to compile a few test versions, if you're willing to try them? It'd likely benefit others who might also have issues with the loader freezing during boot.

Happy to help. It sounds like an issue with IOS58 -- should I even be using this IOS version?

I notice both Cyan's version and your version seem to be reading from the same config file, so maybe a config value being used from Cyan's version which shouldn't be?

So it's possible to create a custom video mode, but it doesn't work consistently because it depends on libogc knowing about every video mode that a game uses.

Unfortunately, knowing all of the game's GXRenderModeObjs wouldn't solve the issue either, as some games are setting the video mode by calling VIConfigure and GXSetCopyFilter with arguments that don't reference any member of a GXRenderModeObj.

Therefore, patching VIConfigure and GXSetCopyFilter is the only way to do it reliably.

VIConfigure is considerably more difficult to patch as its binary can change quite a bit from game to game. So you would need to test a lot of games and come up with some reliable signatures (Swiss's wont work).

Also in case you're not aware, VIConfigure doesn't set the vfilter or aa, only GXSetCopyFilter does.

I think most people just want the vfilter gone and would be happy with that.

If you want to make a lot of people happy for a minimal effort, you can perform a simple find and replace on that binary string.

But its your project and not for me to say.

I think there's enough interest that someone else will do it in the near future. Heck, I'd work on it myself but I'm putting all my time into a PC tool for patching Wii/Wiiware/GameCube iso/wbfs/wad/dol/app, which is turning out to be a lot more work than I imagined. Currently deciding if I want to bother patching VIConfigure to adjust viWidth and viTVmode as it's a lot of work to generate reliable signatures for both Wii and GameCube, but at the same time I really want the ability to adjust viWidth for GameCube games as there are so many of them which display with incorrect width and Nintendont's patching fails (I'm guessing because it only patches GXRenderModeObjs, but don't hold me to that).

 

[JacobM]

Just yesterday I fixed a long standing issue where the pointer would either feel slow or would go in the opposite direction when using a classic controller or a WiiU gamepad.

Awesome! I think I reported that back when Cyan first introduced WiiU gamepad support. Thanks for cleaning things up!

Am I blind or do your mods not show a subversion number? I thought they use to?

 

[SuperrSonic]

Okay, that did not work. At all, I get a messy green screen. Oh well, it'd be nice to have a code for 10 then...

These codes don't change the dol file. If you want to make this permanent it's a bit more complicated.

For Mega Man 10, in 4:3 mode it's the same as MM9 but in widescreen mode it now enables bilinear filtering. I have a few ideas to overcome this, the simple way being to force 4:3 mode but that makes the splash screens look stretched, so I'm gonna try something different and hope it works out.

 

[blackb0x]

Happy to help. It sounds like an issue with IOS58 -- should I even be using this IOS version?

I notice both Cyan's version and your version seem to be reading from the same config file, so maybe a config value being used from Cyan's version which shouldn't be?

If Cyans r1272 build doesn't freeze for you then mine shouldn't either, since they're both using IOS58. And an outdated config file should be fine.

I'll send you a private message with some test versions soon.

Therefore, patching VIConfigure and GXSetCopyFilter is the only way to do it reliably.

Yea, I'm aware. Swiss shows how to do it, although there's going to need to be some changes here and there. But that goes back to what I was saying about it being a difficult to do without a USB Gecko.

If I get frustrated then I might just patch dithering and do everything else at a later date.

Am I blind or do your mods not show a subversion number? I thought they use to?

When you boot my version it'll display the git version that it was built against. I haven't pushed the new changes to GitHub yet though.

 

[GDX]

@blackb0x
Fixed an issue that would cause a few games to freeze

I Try The Adventures of Tintin: The Game. PAL version With your mod It always freezes in the same place
the md5 match to the redump database

 

[blackb0x]

@GDX Tintin still requires NEEK since it fails an anti-piracy check.

 

[XFlak]

@blackb0x
Fixed an issue that would cause a few games to freeze

I Try The Adventures of Tintin: The Game. PAL version With your mod It always freezes in the same place
the md5 match to the redump database

When you say "fixed" was that a typo? Did you mean to say you "found" an issue? This issue is already known as blackb0x already shared, a "fix" other than the current workaround would be great, but I don't think this is what you meant...

 

[blackb0x]

@XFlak He's quoted that from my changelog, without using the quote BB codes.

My fix disabled one of the settings that would cause some games that use MetaFortress to freeze. This didn't fix the issue with Tintin though, since that has an additional check and I'm not sure how to fix it.

 

[GDX]

@XFlak He's quoted that from my changelog, without using the quote BB codes.

My fix disabled one of the settings that would cause some games that use MetaFortress to freeze. This didn't fix the issue with Tintin though, since that has an additional check and I'm not sure how to fix it.

Yes I forgot to quote your message sorry. I thought I understood with your mod that you succeeded in countering the anti-piracy for tintin.

However I noticed in USBLoaderGX when you activate sneek video patch tintin gives you a black screen at launch if that can lead you on a track.

Or why not try to search with a hexdecimal on dolphin to counter the anti piracy to import it on usb loader GX? I don't know if this is possible it remains a suggestion.