Hacking Retroarch Wii U, devkitpro r38 and WUT

[ukigh4ie]

Hi @hito16 ,
why don't you use the devKitPro docker image? Should contain the compiler and all libraries.

 

[hito16]

Hi @hito16 ,
why don't you use the devKitPro docker image? Should contain the compiler and all libraries.

Docker is definitely one good option. For those who want to just build cores, I would recommend that.

My interest is a bit different though. Docker is required today, because Retroarch is built on a 2017-ish toolchain that is no longer supported by the toolchain owners. While the base port of retroarch is frozen in 2017, the build platform, compilers and cores continue moving forward. The 2021(almost 2022!) versions of the Devkitpro ,devkitppc & wut include bug fixes, perf improvements and even new language features... all great stuff, but for retroarch, these are breaking changes. So what? maybe it's a minor issue that retroarch can't benefit from perf and stability improvements. Sure. I would agree. The major issue is one of deprecated platforms; soon or later something will break or introduce a feature we all really really want... and the fix /feature will only be available if retroarch is compatible with the new tool chains.

On possible example: Retroarch media player only complies on platforms with GL2 ports. WiiU does not have a sufficiently functional GL2 port. If one were to make a GL2 port for WiiU, they would probably make it on a 2022 version of DKP, which would likely be incompatible with 2017 versions due to other breaking changes.

 

[ploggy]

Docker is definitely one good option. For those who want to just build cores, I would recommend that.

My interest is a bit different though. Docker is required today, because Retroarch is built on a 2017-ish toolchain that is no longer supported by the toolchain owners. While the base port of retroarch is frozen in 2017, the build platform, compilers and cores continue moving forward. The 2021(almost 2022!) versions of the Devkitpro ,devkitppc & wut include bug fixes, perf improvements and even new language features... all great stuff, but for retroarch, these are breaking changes. So what? maybe it's a minor issue that retroarch can't benefit from perf and stability improvements. Sure. I would agree. The major issue is one of deprecated platforms; soon or later something will break or introduce a feature we all really really want... and the fix /feature will only be available if retroarch is compatible with the new tool chains.

On possible example: Retroarch media player only complies on platforms with GL2 ports. WiiU does not have a sufficiently functional GL2 port. If one were to make a GL2 port for WiiU, they would probably make it on a 2022 version of DKP, which would likely be incompatible with 2017 versions due to other breaking changes.

Hi there, Have you made any progress?

 

[hito16]

I plan to have some time in January 2022 to revisit this. This was the second pass. I think I identified the main pitfalls that need to be solved. There are 3 themes that ideally should be done first, but once done, the port should be "easy" and clean.


1. Missing WUT stuff - A handful of WUT headers look less battle-hardened or are missing; these are candidates for moving retroarch code into WUT. Ex. WUT is missing some AX sound api bindings, that retroarch has. GX2 shader headers in retroarch are more type-safe and readable than those in WUT, but are different enough they are incompatible with WUT. Merging these updates into WUT first would address a big part of the breaking changes, and benefit all WiiU homebrew developers going forward
2. Missing HBL stuff - A few WUT dependencies are ahead of core Homebrew dependencies; these dependencies should be modernized first. Ex. Retroarch imports HBL stubs to launch apps. These HBL stubs are copied directly from the HBL project. These asm stubs are different than those shipped w/ WUT - it may be as simple are the symbol names have changed, or maybe we need to update WUT with more symbols, testing required. Retroarch also has extra stubs for exception handling. Need to get input whether these error handling symbols are appropriate to add into WUT stubs.
3. Middle ground - Some system and os libraries are different in between Retroarch and DKP/WUT, but I think these are best handled by typedefs in Retroarch. Ex. there are 3 close-but-different networking libs/headers in play: Retroarch, Devkitpro and WUT packages. Retroarch snarfed file system libraries from some other project in an unclean way. Memory and most GX2 libraries in DKP/WUT are good enough that we should probably just typedef the difference. In total, several nights work if 1 and 2 were addressed.

The remaining work is just makefile cleanup.

I've never interfaced with the Devkitpro teams, so I don't know how feasible 1 & 2 are.

Here is a pastbin of the git diff from my second pass. Pastebin dot com slash jEZtxvby (no URLs allowed for noobs like me)

You'll see I moved most of the overlapping dependencies out of the way, then hand picked a few missing files and crafted some shim headers. These headers are little more than typedefs to bridge the breaking changes between 2017 and 2021 Devkitpro.

 

[ploggy]

I plan to have some time in January 2022 to revisit this. This was the second pass. I think I identified the main pitfalls that need to be solved. There are 3 themes that ideally should be done first, but once done, the port should be "easy" and clean.


1. Missing WUT stuff - A handful of WUT headers look less battle-hardened or are missing; these are candidates for moving retroarch code into WUT. Ex. WUT is missing some AX sound api bindings, that retroarch has. GX2 shader headers in retroarch are more type-safe and readable than those in WUT, but are different enough they are incompatible with WUT. Merging these updates into WUT first would address a big part of the breaking changes, and benefit all WiiU homebrew developers going forward
2. Missing HBL stuff - A few WUT dependencies are ahead of core Homebrew dependencies; these dependencies should be modernized first. Ex. Retroarch imports HBL stubs to launch apps. These HBL stubs are copied directly from the HBL project. These asm stubs are different than those shipped w/ WUT - it may be as simple are the symbol names have changed, or maybe we need to update WUT with more symbols, testing required. Retroarch also has extra stubs for exception handling. Need to get input whether these error handling symbols are appropriate to add into WUT stubs.
3. Middle ground - Some system and os libraries are different in between Retroarch and DKP/WUT, but I think these are best handled by typedefs in Retroarch. Ex. there are 3 close-but-different networking libs/headers in play: Retroarch, Devkitpro and WUT packages. Retroarch snarfed file system libraries from some other project in an unclean way. Memory and most GX2 libraries in DKP/WUT are good enough that we should probably just typedef the difference. In total, several nights work if 1 and 2 were addressed.

The remaining work is just makefile cleanup.

I've never interfaced with the Devkitpro teams, so I don't know how feasible 1 & 2 are.

Here is a pastbin of the git diff from my second pass. Pastebin dot com slash jEZtxvby (no URLs allowed for noobs like me)

You'll see I moved most of the overlapping dependencies out of the way, then hand picked a few missing files and crafted some shim headers. These headers are little more than typedefs to bridge the breaking changes between 2017 and 2021 Devkitpro.

Excellent, I really hope you pull this off and get Retroarch Aroma safe

EDIT: I'll post your link for you - www.Pastebin.com/jEZtxvby

 

[hito16]

Excellent, I really hope you pull this off and get Retroarch Aroma safe

EDIT: I'll post your link for you - www.Pastebin.com/jEZtxvby

Thanks for resharing the pastebin ! I'll share the following zeropaste of the "git log -u 1 " so folks can get a sense of the scope of work. If you blur your eyes and scroll, you can see the pattern.
1. GX2 & GX2 shaders - a LOT of unnecessary code if WUT GX2 headers are updated
2. AX.*Multivoice - missing headers added by aliaspider Jan 2021, should add to WUT
3. Misc memory utils, KPAD, fsutils, etc - 50/50 whether typedefs are good enough or should we update WUT
4. other misc header includes that exist in WUT with other paths - easily typedef'd. see: wiiu/missing_wut.h
5. Fancy exception handling and some homebrew RPX/RPL boot strapping code + stubs - I'll need help on these.

zerobin dot net slash ?b96d5d0e3c358028#OoqYpsDokcSms5aRJXAKT+ywKcfKaVfHBnzwIrk9QMk=

As you can see, it is too messy to just solve with typedefs, but I'm hopeful. we can clean this up.

 

[ploggy]

Thanks for resharing the pastebin ! I'll share the following zeropaste of the "git log -u 1 " so folks can get a sense of the scope of work. If you blur your eyes and scroll, you can see the pattern.
1. GX2 & GX2 shaders - a LOT of unnecessary code if WUT GX2 headers are updated
2. AX.*Multivoice - missing headers added by aliaspider Jan 2021, should add to WUT
3. Misc memory utils, KPAD, fsutils, etc - 50/50 whether typedefs are good enough or should we update WUT
4. other misc header includes that exist in WUT with other paths - easily typedef'd. see: wiiu/missing_wut.h
5. Fancy exception handling and some homebrew RPX/RPL boot strapping code + stubs - I'll need help on these.

zerobin dot net slash ?b96d5d0e3c358028#OoqYpsDokcSms5aRJXAKT+ywKcfKaVfHBnzwIrk9QMk=

As you can see, it is too messy to just solve with typedefs, but I'm hopeful. we can clean this up.

It all sounds amazing if you can pull it off a little over my head though

I'll post your link again
https://zerobin.net/?b96d5d0e3c358028#OoqYpsDokcSms5aRJXAKT+ywKcfKaVfHBnzwIrk9QMk=

 

[Zeox-gamer]

It all sounds amazing if you can pull it off a little over my head though

I'll post your link again
https://zerobin.net/?b96d5d0e3c358028#OoqYpsDokcSms5aRJXAKT+ywKcfKaVfHBnzwIrk9QMk=

friend how to start netplay on retroarch wiiu ? my retroarch is 1.9.2 but, net play is nothing work, i'm tried with my friends but, error nothing iniciate online game, just start game but, nothing online.

 

[ploggy]

Netplay doesn't work very well, I think I manged to connect to someone once or twice ages ago.. and that was a nes games, snes and up would be too slow to work right.

I havent tried recently but I wouldn't be surprised if it still doesn't work.