Hacking USB Loader GX

[strikerdark]

what I don't like is placing a setting which will have no effect for some users.
They will report "it's not working" etc.
I can hide the setting when not using vWii.
If I add the setting, it will be present in all game type, not only VC. (Wii, Devo, Nin, channels, etc.) so user can set a single option to affect all launching, I won't make it a setting per game-type, so global will also affect Wii games.
I suppose users won't want to enable it for Wii games so they will set it to OFF, but they will have to enable it for all VC one by one which will be annoying if they have a lot of channels...

I don't want to create multiple setting for the same purpose : Wii wide, GC wide, VC Wide, etc wide...
Too much option for a single effect
Switching the video before launching the game is still the easiest (annoying but easiest).

That's strange, the loader is able to autoboot games at launch so it should be fine to quickly select a game.
It happened only recently or did it always work like that? slow free size display?
The slow free size can be fixed if you are using FAT32 (hdd settings > resynch FAT32)

personally i rather have it as a loader option since that can save the setting per game (instead of having to go to the features menu every time i wanna play chrono trigger). But if you feel that it would create confusion i respect your decision.

 

[OriginalHamster]

That's strange, the loader is able to autoboot games at launch so it should be fine to quickly select a game.
It happened only recently or did it always work like that? slow free size display?
The slow free size can be fixed if you are using FAT32 (hdd settings > resynch FAT32) but it's usually only an issue if you are using very old homebrew. new LibFAT is now properly setting free space on all file operations.

My HDD has 2 partitions, NTFS (Wii games), FAT32 (GCN games), also I'm using d2x base 58. The free space feature shows everything correct.

I think everything went slower when I switched to base 58.

 

[Cyan]

I can make it an individual setting without global.
I can force VC to be 4:3 by default but the setting will not be set correctly as default will be different. it will create user's confusion too.
I will need to think of a proper way to implement this setting. it's not a simple thing to do.

 

[shoemaker]

So it would be a timing issue?
for me, the HDD free space info is displayed right away, I don't have to wait to see it.
I don't have a big drive so maybe it require some delay for retrieve free space on big partitions?

The USB and connected drives should already be initialized when you see the game list (or else, the loader wouldn't be able to list games on that drive).
The loader doesn't try to init other devices, only disk type (hdd, flashdrives). but if there's a timing issue, I can see if I can add a delay before launching a gamecube game.

Can users with autoboot+hid issue test this?
Wait some time before launching a game and if it works let me know how long it needs.

Though, your issue is even different to the other reports when it displays nand-1 (or things like that) in nintendont.
Or is it the same? maybe it just exit to menu after the error message.


Edit:
I made a version without argsboot.
It will always create nincfg.bin and launch nintendont without arguments.
Let me know if it fix the hid issue.

I also changed how the loader read console's time. If someone can test playlog and tell me if it's correctly counting play time, that will help me. (disable "return to" or it will not work when exiting a game)

http://www.mediafire.com/download/jau551jer8n95yb/USBLoaderGX_1244mod01.7z

Yep, that patch fixed the autoboot issue, at least on my end!

edit: Wait, it ran successfully once, but then the second time gives a Stack Dump
edit2: Changed the "Settings File" option in Loader Settings to "Create" and everything's working again!

 

[Howard]

USBLoaderGX autoboot code didn't change.
Nintendont changed the way HID is initialized and autoboot suddenly broke.
I think it's in nintendont autobooting with argsboot that we should look. But that doesn't exclude an USBLoaderGX issue.
I just didn't look at it properly yet. I only compared the setting format and they are both identical, so it's not a setting issue.
If the passed setting was wrong or a different size, nintendont would clear the setting and not use it at all, so the arguments are properly formed, sent and received.
It can be an USB shutdown/reinit issue. Maybe I don't properly shutdown USBs? but USBLoaderGX doesn't init HID controllers so I don't have anything to shut down.


About the config version checker, there's no new update but there are new settings.
Old loaders which doesn't have wiiU widescreen will not work with autoboot, because you added a config file size check.
For proper retro-compatibility I think it should add missing configs to default values instead of clearing all the settings and stopping autoboot. that's why users are building USBLoaderGX modded version when new settings are added to nintendont, autoboot just stops working.
But I know it's a lot of work to maintain a proper version check after every new setting.

The code you are looking at is only used when reading a nincfg.bin file not when using args. line 255 right above handles the case of a version 2 file of 540 bytes. When using an older configuration nintendont does use default values for newer options. (see line 270). wiiu wide screen did not change the file size.

 

[Troopage]

That means we're 3 having USBLGX working fine

I already said that both work for me too, so it's 4 then, right?

 

[Troopage]

Sorry for the double post. Might as well put stuff in here.

Apparently it isn't.
I can 100% confirm that the tearing is still present even if loading from the HBC.
1080p over HDMI, NTSC/USA console.
I tried changing resolutions but the issue seems to have resolved itself at this point (carrying from I told you yesterday) so far no issues no matter what I try.
If you say the tearing occurs as soon as the loader is launched then it doesn't matter the way it loads the games. Only reason I asked was because I thought maybe it had something to do with that.
Do you need me to try something else? I can't get the tearing to occur again. But before I tried everything I pointed out on my last post it was consistent. Meaning that it occurred EVERY time.
Do you have ANY idea whatsoever as to what could be causing this? Any at all...? And whats even worse, at RANDOM.

I have screen-tearing, too.

I'd like that option too.
As a matter of fact, I can't understand why would it need to be an "option". games designed to be played in a fixed aspect ratio should be FORCED to do that.
In this case most (all?) VC titles are supposed to be 4:3 AR, correct?
It affecting only vWii users should not trouble you. AFAIR Wii users never got that fixed. Am i right? Nintendo never updated (or probably couldn't) fix that issue.
Probably because of the analog connection.

I'd also like the addition.

 

[sonictopfan]

I looked at the NIN_CFG data structure and the flag enums last night in both the current GX and Nintendon't source. The struct and flags are the same so they should still be compatible. It doesn't look like those values have been changed since several revisions before people started reporting the issue.

I think Nintendon't is doing something funny when autoboot is turned on in relation to the HID features.

That being said, autoboot from GX works fine for me on a regular Wii with a GC controller. I don't have a HID controller to test with except an Xbox 360 one and I don't think they work with Nintendon't.

So you're saying it might be related to the HID? That may explain why I never had issues, I use a regular GC controller or a regular Wii.

what I don't like is placing a setting which will have no effect for some users.
They will report "it's not working" etc.
I can hide the setting when not using vWii.
...

You can write (Wii U only) next to it like with the Widescreen option, just a suggesstion.

 

[cobleman]

Problem ripping The biggest loser Challenge it is suppose to come out as 2.5 gb but only 350mb shows up when finished GX rev 1239

 

[shoemaker]

Another interesting point to make about a "4:3" option that would be useful would be for a game like WarioWare Smooth Moves, which does not support widescreen at all, so that would prevent it from being stretched. Very few Wii games don't support widescreen, but they do exist.

 

[tswntk]

USBLoaderGX autoboot code didn't change.
Nintendont changed the way HID is initialized and autoboot suddenly broke.
I think it's in nintendont autobooting with argsboot that we should look. But that doesn't exclude an USBLoaderGX issue.

Here is a solution https://gbatemp.net/threads/nintendont.349258/page-1293#post-5383331

Even IF it turns out to be not the perfect solution (just a hypothesis most likely/hopefully not true), I would say thats constructive thinking, action rather than blindly say its not Nintdont's or ULGX's problem.

 

[sideskroll]

what I don't like is placing a setting which will have no effect for some users.
They will report "it's not working" etc.
I can hide the setting when not using vWii.
If I add the setting, it will be present in all game type, not only VC. (Wii, Devo, Nin, channels, etc.) so user can set a single option to affect all launching, I won't make it a setting per game-type, so global will also affect Wii games.
I suppose users won't want to enable it for Wii games so they will set it to OFF, but they will have to enable it for all VC one by one which will be annoying if they have a lot of channels...

I don't want to create multiple setting for the same purpose : Wii wide, GC wide, VC Wide, etc wide...
Too much option for a single effect
Switching the video before launching the game is still the easiest (annoying but easiest).

Why not make it exactly like with Nintendon't? One GLOBAL option. and on a per-game basis.
Activating each channel/WW/VC/Wii game manually might be annoying, but it would be a one time deal.
And that way it would benefit VC games as well as the small handful of Wii games that have been poorly programmed (such as Resident Evil 0) that should display in 4:3 with black borders but doesn't.
And you could call it "Wiiu Widescreen" as well. that way people wouldn't say "it's not working" if they try it on a Wii.

On the screen tearing issue: For the life of me I haven't been able to replicate the issue again.
I'm 99% sure it's still present though as it would make no sense for it to fix itself.

 

[LumInvader]

nm

 

[OriginalHamster]

I think my issue is different, as it affects Wii games too, if I start a game right away

Tested your mod, and I still get the problem, if I don't wait enough.

Tested several times with the same game and the problem only arise when the "show free space" is enabled, when it's off, it can boot Gamecube/Wii games just fine

 

[GreyWolf]

Tested several times with the same game and the problem only arise when the "show free space" is enabled, when it's off, it can boot Gamecube/Wii games just fine

That's helpful and makes sense. I don't have the issue and I have "show free space" turned off.

 

[OriginalHamster]

It needs confirmation, but people who never had a problem with nintendont used mastermod build?

 

[GreyWolf]

It needs confirmation, but people who never had a problem with nintendont used mastermod build?

I've either used the SVN build or compiled it myself.

 

[VinsCool]

It needs confirmation, but people who never had a problem with nintendont used mastermod build?

Used master mod build.

 

[Troopage]

Used master mod build.

Same

 

[GreyWolf]

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).

The only warning I get when compiling the newest revision is about a missing virtual destructor in /source/banner/Material.c

It doesn't look like there is a destructor for that class at all so I'm looking through it to see if there's anything that needs to be explicitly freed. Adding a blank ~Material() gets rid of the warning but that wouldn't fix any memory leaks.