Homebrew Official Retroarch WiiU (wip.)

[ploggy]

PS3 Controllers DO WORK! (wired of course) I must have had a bad PS3 cable it gets mapped to the Player 2 port

 

[QuarkTheAwesome]

I had @gblues' problem too - it's been a while, I wasn't really sure I wanted to re-introduce myself to RA with something as significant as a wut port, so I thought I'd fix some bugs - only to sit down and go "wait, what actually needs fixing?"
The All Users Control Menu thing is a shame but it's not really wiiu-specific, and I'm fairly sure the input driver supports having no Gamepad connected/powered and correctly shuffles the users around, so...

 

[ploggy]

@QuarkTheAwesome if you want to dip your toe back in the RA pond can always checkout the list ........

I mentioned that on the discord, I think its related to the removal of the "All Users Control Menu" option awhile back


!!TO EVERYONE..!! WHAT OTHER ISSUES/BROKEN FEATURES ARE YOU EXPERIENCING WITH RETROARCH WIIU.. WRITE THEM IN THIS THREAD AND I'LL COMPILE A LIST AND SEND IT TO THE DEVS ON THE RETROARCH DISCORD

THE LIST...
---------------------------------------------------------------------------------------------------------------------
1. (MikaDubbz) Not so much an issue as it is a request: for the sameboy core, when we emulate and link 2 Game Boys on the Wii U at the same time, can we get an added display option where one Gameboy gets a full display on the TV and the other gets their full display on the Game Pad?

2. (willianholtz)
I believe that for everyone it is the issue of pro control, there are few problems encountered, at least by me. I would like to be able to use my roms from inside my SSD instead of SD, if I'm not mistaken 1.9 already does this, but I'm not sure right now.

3. (MarioSilva)
Getting error 160-4205 when trying to run retroarch via homebrew launcher? (the home menu version works fine)
This has been happening since version 1.9.0

(I did a bit of commit digging and I think one of these commits broke the Retroarch Launcher
https://github.com/libretro/RetroArch/commit/74e5d366c8e6848a5c281cff682a5ab0d16bc22b
https://github.com/libretro/RetroArch/commit/8777a6eb6a5803444e2878aee2ebaec34da34aa1
https://github.com/libretro/RetroArch/commit/a01380f847a469e8c77b7197b83e98bc209dafa8
https://github.com/libretro/RetroArch/commit/d2c3a6d71e3853ca12702ef66ee8c6b46d525a86
https://github.com/libretro/RetroArch/commit/2364fdd900ba1d69672d444e28219f9f2e1dfebc
https://github.com/libretro/RetroArch/commit/1b24c37919d58dc37e059362630f8e2dd302438f
https://github.com/libretro/RetroArch/commit/9d76412715d73f8a73a949afc5bbae6f96eb423c
These are all the WiiU specific commits between the release of 1.8.9 and 1.9.0
No clue which commit did the actual breaking though)

Aside from the issue I mentioned, there are 3 features that would be very good additions:

1. Rumble
2. Wii remote pointer (Wii emulators and Virtual Console games have this)
3. HID support (it was removed at some point for some reason)

4. (AmandaRose)
Not sure how they can fix this issue but when using the content downloader some content is downloaded as a zip. On the PC version of Retroarch the zip is then unzipped. But this does not happen on the WiiU version. So if you do download something on the WiiU say for instance Cave Story you then have to put the sd card into your PC to unzip what you have downloaded. Making the whole point of downloading content directly using the WiiU rather pointless.

Also in regards Cave Story well NX Engine is fucked the game loads fine but none of the enemies move and the collision detection is buggered. You can keep shooting at enemies and the bullets don't kill them at all and you can't get past the first few screens as you need to shoot some blocks but again the collision detection fails to register the bullets hitting the blocks.
(Similar issue was on Wii version of Cave Story More Info Here https://forums.libretro.com/t/retroarch-wii-release-v1-0-0-2/1072/84)

5. (AmandaRose)
OK @ploggy another issue for you. Any ZX Spectrum game I try to load in fuse causes it to DSI error.
https://gbatemp.net/attachments/20210416_005748-jpg.258561/
Logfile:

Spoiler

[INFO] RetroArch 1.9.1 (Git 5658ea7)
[INFO] === Build =======================================
[INFO] Capabilities:
[INFO] Built: Apr 13 2021
[INFO] Version: 1.9.1
[INFO] Git: 5658ea7
[INFO] =================================================
[INFO] [Input]: Found input driver: "wiiu".
[INFO] [Overrides]: No core-specific overrides found at "sd:/retroarch/config/fuse/fuse.cfg".
[INFO] [Overrides]: No content-dir-specific overrides found at "sd:/retroarch/config/fuse/downloads.cfg".
[INFO] [Overrides]: No game-specific overrides found at "sd:/retroarch/config/fuse/Chuckie Egg (1984)(A'n'F).cfg".
[INFO] [Environ]: SET_VARIABLES.
[INFO] [Environ]: SET_CONTROLLER_INFO.
[INFO] Controller port: 1
[INFO] Cursor Joystick (ID: 257)
[INFO] Kempston Joystick (ID: 513)
[INFO] Sinclair 1 Joystick (ID: 769)
[INFO] Sinclair 2 Joystick (ID: 1025)
[INFO] Timex 1 Joystick (ID: 1281)
[INFO] Timex 2 Joystick (ID: 1537)
[INFO] Fuller Joystick (ID: 1793)
[INFO] Controller port: 2
[INFO] Cursor Joystick (ID: 257)
[INFO] Kempston Joystick (ID: 513)
[INFO] Sinclair 1 Joystick (ID: 769)
[INFO] Sinclair 2 Joystick (ID: 1025)
[INFO] Timex 1 Joystick (ID: 1281)
[INFO] Timex 2 Joystick (ID: 1537)
[INFO] Fuller Joystick (ID: 1793)
[INFO] Controller port: 3
[INFO] Sinclair Keyboard (ID: 259)
[INFO] [Remaps]: Remap directory: "sd:/retroarch/config/remaps".
[INFO] [Overrides]: Redirecting save file to "sd:/retroarch/cores/savefiles/Chuckie Egg (1984)(A'n'F).srm".
[INFO] [Overrides]: Redirecting save state to "sd:/retroarch/cores/savestates/Chuckie Egg (1984)(A'n'F).state".
[INFO] [Environ]: GET_LOG_INTERFACE.
[libretro INFO] port 0 device 00000101
[libretro INFO] port 1 device 00000201
[libretro INFO] port 2 device 00000103
[INFO] [CONTENT LOAD]: Loading content file: sd:/retroarch/downloads/Chuckie Egg (1984)(A'n'F).tzx.

6. (Maxbeta)
I’m gonna ask this again since we’re putting issues together on a list, maybe a list for consideration as well?

1. Any chance of integrating Aliaspider’s ppsspp as a retroarch core?
2. If not already added:

• Bring back "all users control menu" (it got removed officially in 1.8.9, but it a must for wii U)

7. (jacobsson)
Forgive me if I'm overreaching here, but I have one "issue" that just makes sense considering the system we're using:

• Wii mote to be used as mouse/pointing device (Today Wii motes only have gamepad support)

Thanks man!

8. (ShadowOne333)
I'm having an issue too.
For some reason, I can't seem to find any N64 or PSX cores on WiiU.
That's an issue

9. (ploggy)
Add the ability to have different scaling between the TV and the Gamepad..
The text/icons look squashed on the Gamepad Screen, it's possible to adjust the DPI in the Settings but that then throws out the scaling on the TV.

I do have a question for you actually Do you know why Retroarch doesn't like compressed RPX's?
I tried to load a compressed RPX (compressed with wiiurpxtool.exe) on Retroarch but it just throws an error? it compressed from 14MB to 4MB too so it was quite the space saver :/

 

[ploggy]

@gblues after a bit more tinkering I managed to get a couple compressed RPX's to run on RA
Snes9x Current Core shrinks to 4.66MB from 14.3MB!
FBA2012 Core that shrinks to 20.6MB from 59.4MB!!!
that's a decent space save lol.. sadly, like you said, the smaller file size has no effect on rom loading :/

 

[ploggy]

Thanks to @BullyWiiPlaza I've managed to mass compress all of the Core RPX files at once
It saved 871MB!! (1.44GB before - 569MB after) not too shabby.
All you need is Wiiurpxtool.exe and to create a bat file:

But you could process all rpx files recursively in batches by bat/shell script, such as:
save the follow bat script as "compress.bat" and run it on windows:

@echo off
for /f "delims=" %%i in ('dir <top_dir>\*.rpx /s/b/a-d') do (wiiurpxtool -c "%%i")
pause
or run the follow shell command directly on linux:
find <top_dir> -name "*.rpx" | awk '{print "wiiurpxtool -c "$1 | "sh"}'

(* change <top_dir> to your directory name)

I would upload the compressed files but really there no point since they're updated regularly, your better off doing it yourself..
Best case scenario would be if the RA devs could implement it in to the WiiU build script so its done automatically.

 

[ShadowOne333]

Thanks to @BullyWiiPlaza I've managed to mass compress all of the Core RPX files at once
It saved 871MB!! (1.44GB before - 569MB after) not too shabby.
All you need is Wiiurpxtool.exe and to create a bat file:

I would upload the compressed files but really there no point since they're updated regularly, your better off doing it yourself..
Best case scenario would be if the RA devs could implement it in to the WiiU build script so its done automatically.

I think that whole process would be better off to be done right in the WiiU Makefile.
With that it could save a lot of space for WiiU users, and more than anything, it would help greatly with the Online Updater, since the WiiU download and decompressing speeds are atrocious!

 

[ploggy]

I think that whole process would be better off to be done right in the WiiU Makefile.
With that it could save a lot of space for WiiU users, and more than anything, it would help greatly with the Online Updater, since the WiiU download and decompressing speeds are atrocious!

Thats a great point didn't even think about the Online Updater, another plus
The WiiU Makefile is what I meant. I'm guessing it shouldn't be too difficult to add??

 

[ShadowOne333]

Thats a great point didn't even think about the Online Updater, another plus
The WiiU Makefile is what I meant. I'm guessing it shouldn't be too difficult to add??

Shouldn't be.
He even gave the instructions on what the process should be depending on what the building OS is:

Compression.bat (For Windows):

@echo off
for /f "delims=" %%i in ('dir <top_dir>\*.rpx /s/b/a-d') do (wiiurpxtool -c "%%i")
pause

Compression.sh (For Linux):

find <top_dir> -name "*.rpx" | awk '{print "wiiurpxtool -c "$1 | "sh"}'
(* change <top_dir> to your directory name)

It's just a matter of adding it properly into the Makefile

 

[ploggy]

@QuarkTheAwesome @gblues any chance you'd look into adding this?

 

[Vague Rant]

I had @gblues' problem too - it's been a while, I wasn't really sure I wanted to re-introduce myself to RA with something as significant as a wut port, so I thought I'd fix some bugs - only to sit down and go "wait, what actually needs fixing?"

Obviously there's the list quoted above, but it's crowded with feature requests and per-core things and such. As far as I know, the RetroArch-wide features that are actually broken (not intentionally removed) are as follows:

1. The main retroarch.rpx launcher binary used when running RetroArch from the Homebrew Launcher crashes, making it completely unusable. Can be worked around with an older binary, e.g. I still use the one from 1.8.5 stable.
2. If a Wii U Pro Controller or Wiimote+Wii Classic Controller (or any derivative) combo loses its connection at any point, reconnecting it results in a broken, nonworking controller state until RetroArch is restarted entirely. This has been broken since some time after the 1.8.8 stable.
3. Extracting the assets.zip file containing all the GUI menu icons and stuff is broken, when using the Online Updater to Update Assets, the zip downloads (not sure if the download actually completes, but it starts and eventually stops) but extraction doesn't work, so users need to (download and) extract the assets manually, e.g. on a PC. As far as I know, this has never worked.

 

[QuarkTheAwesome]

A note for myself, too: something in the GPU coordinate calculations is wrong, which makes Ozone look kinda wrong, with overlapping text and wrong clipping and such. Will see if that gets better once the assets are downloaded (it takes its time, eh) but yea.

 

[ploggy]

A note for myself, too: something in the GPU coordinate calculations is wrong, which makes Ozone look kinda wrong, with overlapping text and wrong clipping and such. Will see if that gets better once the assets are downloaded (it takes its time, eh) but yea.

I've noticed this issue too.. increasing the UI's Scale helps abit.

 

[ShadowOne333]

Obviously there's the list quoted above, but it's crowded with feature requests and per-core things and such. As far as I know, the RetroArch-wide features that are actually broken (not intentionally removed) are as follows:

1. The main retroarch.rpx launcher binary used when running RetroArch from the Homebrew Launcher crashes, making it completely unusable. Can be worked around with an older binary, e.g. I still use the one from 1.8.5 stable.
2. If a Wii U Pro Controller or Wiimote+Wii Classic Controller (or any derivative) combo loses its connection at any point, reconnecting it results in a broken, nonworking controller state until RetroArch is restarted entirely. This has been broken since some time after the 1.8.8 stable.
3. Extracting the assets.zip file containing all the GUI menu icons and stuff is broken, when using the Online Updater to Update Assets, the zip downloads (not sure if the download actually completes, but it starts and eventually stops) but extraction doesn't work, so users need to (download and) extract the assets manually, e.g. on a PC. As far as I know, this has never worked.

Point 3 might get addressed by the PR Quark just made for WiiU:
https://github.com/libretro/RetroArch/pull/12672

The others I'm not sure, but it's nice to see the WiiU oort getting some love

 

[QuarkTheAwesome]

I got a Vita, and went "wait, a RetroArch port can be this good?" So yeah, a bit motivated.

I was planning on chasing filesystem access speeds and did the network optimisation stuff just to make that easier; but have stumbled upon something rather mystifying re: load times. Here's a quick comparison in RA boot times, timed from here to loading the favorites playlist. In the log files provided, that's from ARGV_PTR to "Loading favorites file".

• No CFW (Aroma legacy_env): 1.1 second (log)
  
• Haxchi/CBHC v1.6: 10.3 seconds (log)
• Mocha v0.2: 10.4 seconds (log)

I am pretty well mystified by this result since I explicitly remember people in this thread singing the praises of how fast the directory listings were after the libfat/CFW stuff was introduced, yet this suggests that access times are worse by a factor of 10.

Can I get some other people testing this? Note that (afaik) all the options in the CBHC autoboot menu install some kind of CFW, so if you're on CBHC it might be hard to test No CFW.

Here's the timing setup I used (linux):

udplogserver | ts -s "%.s"

Though frankly a 10 second vs. 1 second boot time should be fine to test by eye.

Is this just me? Is there some other area where using a CFW is faster (large playlists?) I don't really have a massive ROM collection to play with so I would appreciate some help here.

 

[depaul]

Wow! 1 second vs 10 seconds!
I always knew WiiU was capable of much more, and not exploited to its full extent yet!

Good luck and thanks for the test!

 

[QuarkTheAwesome]

I got a Vita, and went "wait, a RetroArch port can be this good?" So yeah, a bit motivated.

I was planning on chasing filesystem access speeds and did the network optimisation stuff just to make that easier; but have stumbled upon something rather mystifying re: load times. Here's a quick comparison in RA boot times, timed from here to loading the favorites playlist. In the log files provided, that's from ARGV_PTR to "Loading favorites file".

• No CFW (Aroma legacy_env): 1.1 second (log)
  
• Haxchi/CBHC v1.6: 10.3 seconds (log)
• Mocha v0.2: 10.4 seconds (log)

I am pretty well mystified by this result since I explicitly remember people in this thread singing the praises of how fast the directory listings were after the libfat/CFW stuff was introduced, yet this suggests that access times are worse by a factor of 10.

Can I get some other people testing this? Note that (afaik) all the options in the CBHC autoboot menu install some kind of CFW, so if you're on CBHC it might be hard to test No CFW.

Here's the timing setup I used (linux):

udplogserver | ts -s "%.s"

Though frankly a 10 second vs. 1 second boot time should be fine to test by eye.

Is this just me? Is there some other area where using a CFW is faster (large playlists?) I don't really have a massive ROM collection to play with so I would appreciate some help here.

Turns out this only happens when you have no assets on the SD, with assets to read the results are a bit more sensible (slow). Still a weird thing.

 

[ploggy]

Abit of interest in the PCSX WiiU bounty
https://github.com/libretro/RetroArch/issues/4852
Go and show some love

 

[depaul]

Abit of interest in the PCSX WiiU bounty
https://github.com/libretro/RetroArch/issues/4852
Go and show some love

Thanks!

embercold commented 11 hours ago
"Okay, I've settled on the pcsx_rearmed core for the task, as the standalone PCSX fork, WiiSX, is proven to run full speed on the WiiU. Of the alternatives, Mednafen is too slow, and Duckstation has neither a PPC recompiler, nor a build script for Nintendo platforms.

So far, I've figured out that the expected pcsxr mmap() problem is a non-issue: the relevant calls can be replaced with malloc()/free(), and it'll run just fine using the interpreter. There may be some lingering big-endian issues, and some misc system calls not implemented on the WiiU, but nothing insurmountable. So the plan is to make it build and crawl some games, then plunder WiiSX for spare parts to make the games actually playable.

I'll do a follow up once I have anything worthwhile to show."

 

[ploggy]

Thanks!

embercold commented 11 hours ago
"Okay, I've settled on the pcsx_rearmed core for the task, as the standalone PCSX fork, WiiSX, is proven to run full speed on the WiiU. Of the alternatives, Mednafen is too slow, and Duckstation has neither a PPC recompiler, nor a build script for Nintendo platforms.

So far, I've figured out that the expected pcsxr mmap() problem is a non-issue: the relevant calls can be replaced with malloc()/free(), and it'll run just fine using the interpreter. There may be some lingering big-endian issues, and some misc system calls not implemented on the WiiU, but nothing insurmountable. So the plan is to make it build and crawl some games, then plunder WiiSX for spare parts to make the games actually playable.

I'll do a follow up once I have anything worthwhile to show."

Hype slowly builds.....

 

[the_randomizer]

Well well, this is awesome :3