Homebrew Official Retroarch WiiU (wip.)

[jacobsson]

Thanks @jacobsson. Retroarch has been slow to load even very small roms. Ploggy showed an old video and the community had the idea to delete those folders and it worked.

Just wow, instant loading! Thanks re-posting this. Judging by the videos upload-date (Nov 6, 2016) I have some back-tracking to do. First things that comes to mind are

1. Try to build a core from that date and validate the performance
2. Looking at all WiiU related commits (this might not be directly related though since then) and get lucky to find something

Also, there are some things that I think should be addressed as well that I'd like to fix:

• Current core should not be reloaded if the new content is targeting the same core
• if the gamepad isn't connected it should not automatically populate player 1 or any other player input

Let's just say that I'm humble to fact that someone smarter than me would/will find the problem much faster, but I don't mind taking a look

 

[ChiefReginod]

I think the theory was that if the info files are present, RetroArch sees the core entries in them and takes that as a cue to reload that core from scratch for some reason (even if the same core is currently loaded). The same applies to playlists. So by removing them and not using playlists, RetroArch won't have that cue to reload the core.

EDIT: I posted this too late since you just said the same thing. lol

 

[depaul]

Also an interesting post by @QuarkTheAwesome

I have a sneaking suspicion that when it has a playlist with the core listed, or core info files that give it the path of the core, it goes "oh, I need to switch to a new core to play this!" even if the currently loaded core is perfectly capable.
Switching cores is a somewhat slow affair, since it unloads the current core+RetroArch and tells HBL to load the new core+RetroArch from scratch. The new RA has to load up the menu assets again, which is the truly sluggish wiiu thing.

I wrote a little hack for whatever the current git master is that logs out when files are opened and closed with timestamps - check it out! there's two logs in there - the first one where all the messages are prefixed with [fs-cafe] is using the native Cafe OS filesystem drivers, like on a console with no CFW. [fs-lfat] uses iosuhax (included in Mocha, stripped-down version in CBHC) and libfat. Keep in mind when looking at the timestamps that the logging itself likely sucks up several milliseconds each line, since it's networking, and yeah. Cafe native is pushing a 20s boot!

 

[Deleted User]

@TheChosen Thanks a lot for sharing those stories and information, it's interesting to say at least! I can't wait to see what this leads up to.

There is just one thing that I can't really understand right now that we should really be asking our selves when it comes to RetroArch (absolutely not neglecting anything of your prior reply):
How come an app like Dumplings can achieve speeds of 20MB/s (~160Mbit/s) when transferring data between HDD and SD card, while RA needs almost a minute to load a 30MB rom from SD or HDD? I know the roms are in zip archives mostly, is that a factor?

EDIT: I guess I need to find a core that accepts both zipped and unzipped roms and compare the load times.

EDIT2:
Street Fighter Alpha 2, Zipped, SNES 9X: 27s
Street Fighter Alpha 2, Unzipped, SNES 9X: 26s

Loading of the core seems to be a huge time factor here. I guess I'm running in circles

Good question. I assume, "RA" relies on WiiU`s OS (it runs inside WiiU´s OS as an own implemented driver/library).

While "Dumpling" is an own hand-written tool. Not relying on any of WiiU´s library.Which is needed if you want the unlocked USB.

So if you want the power you have two possibilities: a) modify the WiiU`S driver (method shown in loadiine latest compile) or b) you run an own hand-written tool. Dumping is a hand-written tool, so it won`t have any problems with speed since WiiU´s OS is circumvented if you want to call it like that.

 

[depaul]

Also good to remind what Dumpling author stated: that Dumpling is based on the tool FT2SD. So I think those R/W operations are imported from FT2SD.

 

[Zense]

Not to mention using genesis plus gx core, that I can't play 2 player sonic 2 because it also runs slow compared to single player.

If anyone knows what options that effect performance, that would be nice.

I don't know what affects the performance, but I would guess Sonic 2's issue is that the game runs in interlaced mode when you play 2 player. You probably already know this.

 

[Sonic Angel Knight]

I don't know what affect the performance, but I would guess Sonic 2's issue is that the game runs in interlaced mode when you play 2 player. You probably already know this.

I noticed a option in the genesis plus gx core settings to use a single field or double field. It says the double field is does what the real megadrive does. Using the other one makes things look bad, but it does make it run a bit better. Honestly I didn't think the wii u would have a problem with performance with such a thing.

Considering that the version for wii and gamecube homebrew does have the same feature and doesn't lose performance using it.

 

[QuarkTheAwesome]

So if you want the power you have two possibilities: a) modify the WiiU`S driver (method shown in loadiine latest compile) or b) you run an own hand-written tool. Dumping is a hand-written tool, so it won`t have any problems with speed since WiiU´s OS is circumvented if you want to call it like that.

I'm kinda curious to see how many times you can imply that Loadiine can read from USB drives before people pick up on it, tbh.

@jacobsson I'll take a look at that controller ordering thing today, sorry I said I would then sat on it for a bit.. uni's wild as ever!

 

[jacobsson]

I'm kinda curious to see how many times you can imply that Loadiine can read from USB drives before people pick up on it, tbh.

@jacobsson I'll take a look at that controller ordering thing today, sorry I said I would then sat on it for a bit.. uni's wild as ever!

Oh, no hurry buddy!
Take your time, I know I did since I haven't got a round looking on it yet.

 

[Deleted User]

I'm kinda curious to see how many times you can imply that Loadiine can read from USB drives before people pick up on it, tbh.

@jacobsson I'll take a look at that controller ordering thing today, sorry I said I would then sat on it for a bit.. uni's wild as ever!

I don´t know what you mean, Quarky. You can use USB with Loadiine`s latest build (which was known since many months ago)- what´s different now is that you can unlock your USB to full speed- if you have an SSD it will load much better than from an HDD- especially via USB. Or you can manually update the RPX-file. You just replace the old rpx-file with the new one. And it works. But like i said: Certain games won`t work because they seem to have another DRM-protection (triggers) in them, which lead to well "unwanted effects" (just call it like that, since nobody knows exatly what they trigger, until you try it). These effects can include (in RTS-games) "make units explode at start" or "wait 300 seconds" or "trigger bad enemy which cannot be defeated".Yeah, i remember those types of DRM used in the past in certain games. Nintendo also seems to still use this old DRM-stuff.

I have a few more games ready now to make a long test of it. I have: Mario 3D World, Mario Maker, Sonic Boom (yeah, pretty interesting, i am one of the only guys who bought this game for cheap 15€), I also have Windwaker HD & Zelda Breath of the Wild ready, finally dumped successfully.

I will do tests to see if loading improves (and how much) and what else is different. Or if nothing happens (that might be a problem of DRM-triggers then). I also have a few Indie-games to test.

Btw: It will be very interesting to test "Sonic Boom", since you can directly change the fps in the game`s settings/engine-settings. Which would be equal to modding then (or graphics-settings, but these settings also include AI, physics and other stuff, so yeah, more then just graphics-settings lol).

 

[CORE]

I don´t know what you mean, Quarky. You can use USB with Loadiine`s latest build (which was known since many months ago)- what´s different now is that you can unlock your USB to full speed- if you have an SSD it will load much better than from an HDD- especially via USB. Or you can manually update the RPX-file. You just replace the old rpx-file with the new one. And it works. But like i said: Certain games won`t work because they seem to have another DRM-protection (triggers) in them, which lead to well "unwanted effects" (just call it like that, since nobody knows exatly what they trigger, until you try it). These effects can include (in RTS-games) "make units explode at start" or "wait 300 seconds" or "trigger bad enemy which cannot be defeated".Yeah, i remember those types of DRM used in the past in certain games. Nintendo also seems to still use this old DRM-stuff.

I have a few more games ready now to make a long test of it. I have: Mario 3D World, Mario Maker, Sonic Boom (yeah, pretty interesting, i am one of the only guys who bought this game for cheap 15€), I also have Windwaker HD & Zelda Breath of the Wild ready, finally dumped successfully.

I will do tests to see if loading improves (and how much) and what else is different. Or if nothing happens (that might be a problem of DRM-triggers then). I also have a few Indie-games to test.

Btw: It will be very interesting to test "Sonic Boom", since you can directly change the fps in the game`s settings/engine-settings. Which would be equal to modding then (or graphics-settings, but these settings also include AI, physics and other stuff, so yeah, more then just graphics-settings lol).

What Build of Loadiine are you using?

It is not the Build that requires the use of MochaFat32?

 

[Whelt]

Hey everyone. I'm trying to get a HID controller working in Retroarch.

I have an SN30 Pro+, which I have created an ini file for, and verified that it works in HID to VPAD. Works just fine for Wii U games.

I'm trying to follow the steps on page 237 of this thread to set up this controller in Retroarch. I have the ini file in wiiu/controller. When I go to Input and try to map anything in user 5-16, it's not recognizing my button presses. Am I missing something? Any help would be appreciated.

 

[n00bsaib0t]

Is it possible to make it where, say, a Game Pad and a Pro controller can both be the Player 1 controller? It's a minor inconvenience, yeah, but still kinda annoying when I'm playing on TV and want to use a Pro controller then the next day I want to use the Game Pad off TV, I have to use the one I set as my Player 1 in the settings to switch it to the other. I know some official games are set up this way where the Game Pad and the first detected controller are both Player 1. Or maybe a Switch style menu where you press L+R (or some other combination) on the controller you want to use every time you launch it?

This question got glossed over with other discussions going on. Just figured I'd quote it to see if something like this is possible to implement.

 

[jacobsson]

This question got glossed over with other discussions going on. Just figured I'd quote it to see if something like this is possible to implement.

I have a post further up regarding not populate player 1 with the gamepad if it's not connected.
My thought is that when/if it gets connected it should only then take over player 1.

 

[n00bsaib0t]

I have a post further up regarding not populate player 1 with the gamepad if it's not connected.
My thought is that when/if it gets connected it should only then take over player 1.

Yeah but it turns on automatically when the WiiU is turned on. It's definitely a first world problems situation, but everything regarding consoles is to some extent. So for those of us who just keep our Game Pad on the charging dock so it's ready when we want to use it the Game Pad would then always be player 1. Maybe let us choose multiple controllers to map as player 1? Like say it detects the Game Pad, a Pro controller, and a Wii remote with Pro Controller we could set one or even both of the other controllers to be player 1? The PC version lets you bind keyboard and a controller both to player 1 controls, so in theory the code for something like that should already exist in Retroarch, right?

 

[QuarkTheAwesome]

My thought is that when/if it gets connected it should only then take over player 1.

I got support merged in for hotplugging Gamepads, so nightlies should be able to handle missing gamepads and whatever. When RetroArch starts, a connected Gamepad will still be player 1 (and theoretically 2 if you're a l33t hax0r) and Wiimotes/Pro controllers take the slots after that, but if there's no Gamepad then a Wiimote will take slot 1. If you connect a Gamepad after RetroArch starts it'll get the next free slot, just like a Wiimote would.

Maybe let us choose multiple controllers to map as player 1? Like say it detects the Game Pad, a Pro controller, and a Wii remote with Pro Controller we could set one or even both of the other controllers to be player 1? The PC version lets you bind keyboard and a controller both to player 1 controls, so in theory the code for something like that should already exist in Retroarch, right?

I believe you can go into Settings->Input->Port 1 Binds and mess with the Device Index to set which connected pad is Player 1. Be careful though, there is a "disabled" option and it's easy to lock yourself out! I'm not aware of any way to have several controllers map to one port, though.

I'm trying to follow the steps on page 237 of this thread to set up this controller in Retroarch. I have the ini file in wiiu/controller. When I go to Input and try to map anything in user 5-16, it's not recognizing my button presses. Am I missing something? Any help would be appreciated.

We don't have that system for HID controllers anymore, as it wasn't that well integrated with RetroArch and was kinda crashy. There was lots of new HID infrastructure added, but I don't really understand it and doesn't seem to be quite so configurable as the original was.

 

[jacobsson]

@QuarkTheAwesome amazing job! Gonna grab my morning coffee and browse through your commit. Again, thanks man!

EDIT: works great, made my day!

 

[jacobsson]

Yeah but it turns on automatically when the WiiU is turned on. It's definitely a first world problems situation, but everything regarding consoles is to some extent. So for those of us who just keep our Game Pad on the charging dock so it's ready when we want to use it the Game Pad would then always be player 1. Maybe let us choose multiple controllers to map as player 1? Like say it detects the Game Pad, a Pro controller, and a Wii remote with Pro Controller we could set one or even both of the other controllers to be player 1? The PC version lets you bind keyboard and a controller both to player 1 controls, so in theory the code for something like that should already exist in Retroarch, right?

I didn't know that the system turns on the controller, it just proofs more and more what a weird yet fun device we're working with here!

 

[jacobsson]

.

 

[V10lator]

@V10lator Omg, I'm sorry... I didn't realize that the gamepad (which I'm emulating via DRC-SIM) is a requirement to get pas the loading screen. When connecting it now starts. Let me update you further

Allright but we're not in a private conversation here.