Hacking USB Loader GX

[Cyan]

Maybe nintendont really screw the config since r304. I didn't like howard's change to check setting size, as it would break compatibility if nintendont expect a different/smaller size, while all the settings are still passed correctly. I'll see if it's what is causing the issue.

The wiiU Widescreen passed setting should work, whatever the method you use to boot USBLoaderGX.
It's only a setting sent to nintendont "I want the game NOT in widescreen", it should read that setting and don't set it to widescreen.

I don't see why launching from forwarder would affect the sent argument settings.
But I'll do more test (probably today)

 

[sideskroll]

Maybe nintendont really screw the config since r304. I didn't like howard's change to check setting size, as it would break compatibility if nintendont expect a different/smaller size, while all the settings are still passed correctly. I'll see if it's what is causing the issue.

The wiiU Widescreen passed setting should work, whatever the method you use to boot USBLoaderGX.
It's only a setting sent to nintendont "I want the game NOT in widescreen", it should read that setting and don't set it to widescreen.

I don't see why launching from forwarder would affect the sent argument settings.
But I'll do more test (probably today)

Just to be clear:
The setting itself doesn't revert (What I mean is that in the loader's settings the option is still "OFF") what reverts is the way the game is displayed.
I need to go to Wii U menu and back to vWii for it to work again.

 

[Cyan]

Try with nintendont r303 to see if it's correctly reading the settings sent from the loader after game exit/launch from forwarder/launch from hbc/etc.

 

[sideskroll]

Try with nintendont r303 to see if it's correctly reading the settings sent from the loader after game exit/launch from forwarder/launch from hbc/etc.

Will do.
Question: Would editing the "usbloader_gx" folders name to "USBLoader_cfg" for it's forwarder to be able to launch it be a viable "temp fix" for the screen tearing issues or it has other possible causes as well?
(I was thinking of editing ModMiis forwarder for compatibility with vWii as well... if that could solve the problem)

 

[Cyan]

if you rename the folder, the forwarder will not work anymore.
It's looking at specific path.

apps/usbloader_gx/boot.dol and apps/usbloadergx/boot.dol on SD then up to 8 partitions on USB.

Edit : ahh I understood.
you want to use CFG or wiiflow forwarder to launch GX.
yes, that will work
don't forget to point to the correct forwarder in the "return to".
You might need to edit the path in user settings too (all path pointing to default folders, like update path, etc.)

The other forwarder will not read meta.xml and use arguments.

Let me know if using their forwarder is fixing the screen tearing issue.

 

[tswntk]

tswntk : yes, maybe I should drop old settings and allow only newer version of nintendont.
Though, I like to allow users keep their working version without forcing them to update. Some games might work better in specific revision (that's why users asked for a per-setting nintendont path).
I don't know up to which version I can remove. I guess anything below 2.0 can be removed? anything without arguments compatible maybe. If I don't find the "argsboot" string, it's too old.

Actually I haven't really start using Nintendont yet. I just follow the threads and make comments/suggestions whenever I feel I maybe helpful.
I don't really have a say on which versions to remove.
From what I have read, Nintendont is becoming quite perfect and stable, but really, only Nintendont fans can tell.

 

[DemitriArcane]

Some reason mario sunshine isnt working through usb loader via nintendont, yet when i load it from the homebrew channel in nintendont it works.

 

[Cyan]

Some reason mario sunshine isnt working through usb loader via nintendont, yet when i load it from the homebrew channel in nintendont it works.

Actually, it's doing the contrary for me.

I just tried nintendont v3.318 to check if the settings were different, here my result with Mario sunshine (NTSC):

- USBLoaderGX 1242 + Nintendont v3.318 + create config file setting + Video mode auto : 544b nincfg.bin file created. The config file is properly containing video mode Auto (value 0x0000). Mario sunshine (NTSC) works.
- HBC + Nintendont 3.318 + Video mode auto : 544b nincfg.bin file created. The config file containing video mode force prog while I didn't ask for that setting (value 0x0010, 1<<4). Mario sunshine stops on blackscreen at boot.

both USBGX and Nintendont are using the proper configs setting format (same size, same config version, etc.)
Nintendont from HBC seems to force Progressive when not asked.
I'm still investigating what's wrong when using autoboot+HID connected. (I have a PS3 controller, I hope it will trigger the issue)

 

[tswntk]

on the topic of Nintendont version detection:
wouldn't it be possible to add a custom string structure inside
/trunk/common/include/NintendontVersion.h
so that you can search for it?
Of course that will have to be agreed with other developers as if they never cared to update that string, its useless.

I always puzzled why a program that was designed to be used with external loaders would never care about how to work with external loaders.
In Windows environment, version detection is almost always built-in.

- USBLoaderGX 1242 + Nintendont v3.318 + create config file setting + Video mode auto : 544b nincfg.bin file created. The config file is properly containing video mode Auto (value 0x0000). Mario sunshine (NTSC) works.
- HBC + Nintendont 3.318 + Video mode auto : 544b nincfg.bin file created. The config file containing video mode force prog while I didn't ask for that setting (value 0x0010, 1<<4). Mario sunshine stops on blackscreen at boot.

both USBGX and Nintendont are using the proper configs setting format (same size, same config version, etc.)
Nintendont from HBC seems to force Progressive when not asked.
I'm still investigating what's wrong when using autoboot+HID connected. (I have a PS3 controller, I hope it will trigger the issue)

I still think its actually a bug in Nintendont (on argument passing or config file handling) but they just shed the responsibility to external loaders.
I don't mind that's is not high in their priority list but simply ignore it is not the way to go.
Edit: I don't mean it is actually the attitude of the devs but members on that thread.

 

[Cyan]

I asked multiple times to add a proper version detection for external loaders, but never got an answer.
Like you said, it would require an update for each revision, but that's already how it's working with NintendontVersion.h (it's always manually updated, it's not even automated. Sometime they even forget to update the version and users don't understand why it still display an old number -> update doesn't work, please fix it, etc.).

in the same subject, Howard (I think that's him) added a way to allow external loaders to use old nintendont config version instead of breaking compatibility on the event of future config changes.
Crediar said it's not nintendont job to care about loader's compatibility, but in my opinion it is nintendont job to care that all existing configs version are working, it's the developer's job to take full attention not to break compatibility.
It's just different developer's view. that's what happen on a project with multiple devs. hopefully it's only a hobby, not a professional release. no need to care too much and have a coordinator.

That's why I try to keep compatibility with all released versions, even very old ones are still working and using proper versions and settings. I'm doing the "retro compatibility" support in the loader as nintendont is not doing it.
it's a little unclean code as I can only base detection on compile date instead of using a proper version detection.

 

[bobmcjr]

Where is the download for R1242 at the moment?

 

[Cyan]

not public yet.
It has no differences compared to 1241.
It's only a fix version to compile with devkitPPC r27
There's still a warning, but I don't know how to fix it. It may even be a GCC compiler bug.
devkitPPC R27 is maybe not stable, it's breaking on a code which worked fine in other version (it's asking to report it to wintermute, but I didn't do it yet).

 

[tswntk]

I asked multiple times to add a proper version detection for external loaders, but never got an answer.

Crediar said it's not nintendont job to care about loader's compatibility, but in my opinion it is nintendont job to care that all existing configs version are working, it's the developer's job to take full attention not to break compatibility.

That's why I try to keep compatibility with all released versions, even very old ones are still working and using proper versions and settings. I'm doing the "retro compatibility" support in the loader as nintendont is not doing it.
it's a little unclean code as I can only base detection on compile date instead of using a proper version detection.

Might be a little drastic.
How about stop updating Nintendont support. Why working with something so unfriendly.
Everyone is pointing at you to "fix" the latest revisions issues while they enjoy playing with Nintendont's own gui.

That said, I don't play with Nintendont (yet), may be a bit unfair for other ULGX fans who also enjoy Nintendont.

 

[Cyan]

if it's really nintendont issue (and it's probably the case), there's nothing I can do on my side.
I'll focus on adding neek2o instead, more users will benefit from it.
Users with nintendont issue can either launch from HBC or use v2.303 (do they really need 3.x+? compatibility is already very good on 2.x)
Like I often say, latest is not always better. don't fix if not broken

 

[sideskroll]

if you rename the folder, the forwarder will not work anymore.
It's looking at specific path.

apps/usbloader_gx/boot.dol and apps/usbloadergx/boot.dol on SD then up to 8 partitions on USB.

Edit : ahh I understood.
you want to use CFG or wiiflow forwarder to launch GX.
yes, that will work
don't forget to point to the correct forwarder in the "return to".
You might need to edit the path in user settings too (all path pointing to default folders, like update path, etc.)

The other forwarder will not read meta.xml and use arguments.

Let me know if using their forwarder is fixing the screen tearing issue.

OK, this what I've find so far:

Launching from HBC doesn't give the loader permission to read from nand.


Tried everything. I even deleted the whole meta file and made one myself by copying it's contents from your google page.
Nothing. It just won't read. I mean, it WORKS, yeah. But the loader is unable to read the name of the forwarders or anything like that.

Screen tearing issue

Launching GX from either HBC or forwarder (both CFGs and GXs own) made no difference at all. The tearing still occurred consistently.
I tried launching the game from Nintendon't itself and sure enough the issue wasn't present.
Now for my findings, when in Nintendon't. I launched a KNOWN problematic game (Batman Begins, NTSC in this case) without moving ANYTHING. All settings were left at default (Wiiu Widescreen, Memory card emulation etc) the game launched and like I said, there was no tearing whatsoever.
I exited the game and went to GX to try and load the same game, this time being SURE that there was no tearing and... there it was. The tearing again.
Ok, so I switched wiiu/vwii again and started over. Only this time While in Nintendon't I changed some settings (mainly Widescreen and MCE)saved, exited and launched GX again.
This time the tearing issue wasn't consistent. Meaning that out of 5 times I tried launching the game, 3 were tear free while 2 weren't.
Ok, random result but at least it wasn't consistent anymore.
Rebooted the console again, went into Nintendont, UPDATED it to the latest rev, changed the settings back to default and exited.
Now, I've launched the same game (Batman Begins) 4 times in a row and the tearing issue never appeared. Perhaps it's a random occurrence and the next time I try it the issue will be there. Probably.
What I THINK might be possible is that somehow Nintendon't likes to keep it's own cfg file in the drive. Even if the settings are at default and GXs Nintendon't settings are at default as well (which I think is "do nothing" or something like that?)
Here are My GXs video settings for you to try and replicate the issue:
Every video mode EVERYWHERE to "System Default" if possible, if not "console default".
Wiiu Widescreen turned off for Nintendon't GLOBALLY, but ON for Batman Begins.
Try deleting Nintendonts config file and launch the game. And then create a config file and try again (Nintendont settings at default)
I have no idea what could be causing either of this issues, maybe you do.
Let me know if you need me to test something else.

PS: After writing this I realized I didn't try to see if the issue was present with Wii games as well, So I did and there's no tearing.
But it could very well due to the random nature of the issue. Or perhaps some of those things I tried somehow "fixed" the issue.
I'm at loss there. Let me know if something occurs to you.
Cheers.

 

[LumInvader]

if it's really nintendont issue (and it's probably the case), there's nothing I can do on my side.
I'll focus on adding neek2o instead, more users will benefit from it.
Users with nintendont issue can either launch from HBC or use v2.303 (do they really need 3.x+? compatibility is already very good on 2.x)
Like I often say, latest is not always better. don't fix if not broken

Compatibility is superb, Cyan.

I realize there aren't a lot of Mr. Driller players, but the few of us who do play it are likely frustrated to finally see it get fixed in r318, only to learn that GX will not support that build in the near future, if ever.

Not a complaint (I appreciate all you do around here), but just pointing out that 3.x+ cutoff point will certainly effect some of us.

 

[OriginalHamster]

Screen tearing issue

Well, at least we know this is not a forwarder problem. Reading your test seems to be in the line with my own experience, it has the same behavior when launching Wii games.
Now, it would be interesting test if the video corruption happens after or before launching a game, since the problem seems completely random, and "infest" Wii menu it's kind of hard stablish when it happens.

I tested with all the d2x variations, and the problem still there, so we can narrow the problem even more.

 

[sideskroll]

Well, at least we know this is not a forwarder problem. Reading your test seems to be in the line with my own experience, it has the same behavior when launching Wii games.
Now, it would be interesting test if the video corruption happens after or before launching a game, since the problem seems completely random, and "infest" Wii menu it's kind of hard stablish when it happens.

I tested with all the d2x variations, and the problem still there, so we can narrow the problem even more.

To me at least, the issue seems to appear AFTER launching a title.
Even if the game itself is not displaying any corruption on screen, the system menu might be teared when exiting. Now, if on the other hand you never even attempt to launch a game (I'm thinking it's an issue with GX not the loader or Nintendon't by themselves) the issue never appears (for me at least it doesn't)
CFG doesn't appear to have any issues in that regard. (never gotten any tearing either with GC or Wii games) so it probably is an issue with GX itself. Not with loading games.
Cyan, could you explain the main differences between GX and CFG? Besides GUI and features. I mean the actual LOADING process of it. Is there any substantial difference in the way these 2 loaders work?
I'm thinking maybe it has something to do with GXs resolution. which is not the same exact resolution as say the System Menu (I think?)

 

[sonictopfan]

I don't understand, USBLGX works fine for me and loads Nintendont no problem, latest version of each, what's the problem? Is it related to Wii U or maybe certain games?

 

[VinsCool]

I don't understand, USBLGX works fine for me and loads Nintendont no problem, latest version of each, what's the problem? Is it related to Wii U or maybe certain games?

That means we're 3 having USBLGX working fine