Homebrew Official Retroarch WiiU (wip.)

  • Thread starter Thread starter aliaspider
  • Start date Start date
  • Views Views 2,708,253
  • Replies Replies 15,205
  • Likes Likes 93
You can set haxchi to boot into system menu with sig patches, no need to actally enter to HBL

Look for SD:/haxchi/config.txt
and edit:
Code:
default=sysmenu
b=wiiu/apps/homebrew_launcher/homebrew_launcher.elf

This way when you select haxchi from Wii U menu it will apply sig patches but will not boot HBL, if you want boot HBL you need hold B while booting haxchi

I checked and I have the same configuration. Pressing nothing boots me in sysmenu with patches and B boots me to Homebrew menu.
I wonder if going coold boot hax will fix this for me...
 
I checked and I have the same configuration. Pressing nothing boots me in sysmenu with patches and B boots me to Homebrew menu.
I wonder if going coold boot hax will fix this for me...

You checked the config file? It should be on the SD card in the Haxchi folder. What does it say and is there anything else in there? Screenshots help.
 
I recall having issues with the tool as well, I had to do some Hex editing to fix the re-encrypted RPX files, but as far as I remember that issue got sorted out.

You can read about it here:
https://github.com/BullyWiiPlaza/RPL-Studio/issues/1

You can see my posts there as well as what I did to manually fix the encrypted RPX.
Trying following that, perhaps that gets them to run.
Hey, managed to get the executable working (had to associate jar files with JAVA manually, don't know what caused the issue...) anyway, any idea as to why the resulting (after compression) RPX file is half the size of the original?
 
You checked the config file? It should be on the SD card in the Haxchi folder. What does it say and is there anything else in there? Screenshots help.
Heres the config of the haxchi

Code:
a=wiiu/apps/homebrew_launcher/homebrew_launcher.elf
b=fw.img
default=sysmenu

Before running RA I used to click on the launcher channel and let it boot into sysmenu.

Should I just give up and set up CBHC?
 
I thought you had to have the paks for quake in the root of the SD? Still get a crash when I load a pak
 
Are some icons getting corrupted in the menu of Wii U version just "a feature" of Nightly builds until thing gets figured out and fixed out?
What I mean is initially, without assets every icon seemed to default to a character map of some sort scaled into an icon. After installing assets most icons are fine but collections still corrupt up into the character-map-as-icon and all games in a playlist show as such too. Also the "+" icon usually indicating "add a playlist" changes around.

I am just wondering and I am myself thinking it is just WIP nature of Retroarch on Wii U, but ask since I seen how it should look like on 3DS and PS3 versions of Retroarch.
 
I still cannot get commodore 64 games to play. I'm on the 1-31-18 nightly build. I obtained 500mb sized romset, which has some of the games I use in .d64 format. So I'll load the core, load "zaxon.d64" and all I get is the blue/purple c64 screen, waiting for something to type. I don't know what to do. :-(
 
Hey, managed to get the executable working (had to associate jar files with JAVA manually, don't know what caused the issue...) anyway, any idea as to why the resulting (after compression) RPX file is half the size of the original?
Half size?
There should be something wrong.

The DRPX file you get after decrypting the RPX should be almost double the size.
For example, I remember when I decrypted the vessel.rpx for F-Zero N64 VC, the resulting vessel.drpx was like 3-4MB in size, while the original and re-encrypted RPX file was around 1.5MB IIRC.
Check again, maybe that's what you are referring to.
 
Half size?
There should be something wrong.

The DRPX file you get after decrypting the RPX should be almost double the size.
For example, I remember when I decrypted the vessel.rpx for F-Zero N64 VC, the resulting vessel.drpx was like 3-4MB in size, while the original and re-encrypted RPX file was around 1.5MB IIRC.
Check again, maybe that's what you are referring to.
The resulting rpx is half the size of the original. Maybe the compression is "better" with wiiurxtool? As in, gets rid of garbage left over in the original? Anyway, it works fine. So im guessing the original isnt optimized at all.

Oh, and in my case the DRPX is EXACTLY (to the byte) the same size as the RPX file (the original one, obviously)
 
Last edited by sideskroll,
  • Like
Reactions: ShadowOne333
@ShadowOne333 I got the slowness issue you were experiencing, after loading-closing content back and forth the menu turns sluggish, I was testing a GB shader so I only loaded gamebatte core.

Can you open an issue?
 
  • Like
Reactions: ShadowOne333
New to Retroarch and having a noob problem...I can’t get retroarch to see my image file that I want to use for a wallpaper. I browse to the directory and it doesn’t see anything. Does it have to be in a special format? Or named a certain way? Or a specific resolution?
 
  • Like
Reactions: ShadowOne333
The resulting rpx is half the size of the original. Maybe the compression is "better" with wiiurxtool? As in, gets rid of garbage left over in the original? Anyway, it works fine. So im guessing the original isnt optimized at all.

Oh, and in my case the DRPX is EXACTLY (to the byte) the same size as the RPX file (the original one, obviously)
So decompressing the RPX does give you a DRPX of the same size as the original?
That's weird, unless the RetroArch ones don't really do decryption to some extent.
Try with RPX files of VC titles or things like that, maybe then you can see the difference.
@ShadowOne333 I got the slowness issue you were experiencing, after loading-closing content back and forth the menu turns sluggish, I was testing a GB shader so I only loaded gamebatte core.

Can you open an issue?
Did you get the same kind of thing I got?
The one I was having happened whenever I opened up a game and then RetroArch would stutter both in gameplay and in the menu.
Though for me it stopped after a while, like half a minute or a bit more.

Let me know if you had any changes in this behaviour to try to cover as much as possible and explain it in detail on the issue once I open it.

I haven't experienced it again after updating the cores and cleaning the CFG files, but then again, I haven't played much since yesterday, I only tried out a few cores to test if the issue was or not there, I didn't play longer than 5 mins.
 
Last edited by ShadowOne333,
Just to let you know, that issue is also present on the Vita port, so I guess this is not a wiiu specific issue.
So it's not console specific?
Interesting, perhaps this might be related to something like the Menu driver?

A video would be good to demonstrate the bug in detail.
Also, it would be interesting to see if the issue is still present when changing Menu appearances, like going from XMB to GLUI or RGUI.

I will try this out once I get home to see if I can replicate it.
 
  • Like
Reactions: Billy Acuña
If you use shaders the issue will be always there, as retroarch.cfg stores the last used shader here: video_shader = "" and apply that shader to the RA menu (on background), on top of built-in shaders (ribbon, bokeh, snow, etc...) so it become slow because is processing both shaders (or at least that's how I understand it).

If you use a shader even once you are screwed lol.

(you still can delete that line from retroarch.cfg from your PC, but it will appear again if you use a shader)
 
Last edited by cucholix,
  • Like
Reactions: ShadowOne333
Im sorry to ask but...
Does n64 games work on retroarch wiiu?

(Also, how about rogue squadron/battle for naboo/indiana jones? Anybody heard anything about these games working.. on any emulator?)
 
If you use shaders the issue will be always there, as retroarch.cfg stores the last used shader here: video_shader = "" and apply that shader to the RA menu (on background), on top of built-in shaders (ribbon, bokeh, snow, etc...) so it become slow because is processing both shaders (or at least that's how I understand it).

If you use a shader even once you are screwed lol.

(you still can delete that line from retroarch.cfg from your PC, but it will appear again if you use a shader)
I'm afraid that issue is different from mine, as I never used shaders.
I only used the default Menu themes ones for XMB, I haven't use shaders from the pack that should go inside /retroarch/media/shaders.
Also, does the menu continue slugging up even after some minutes?

This could be related to an issue with how the Main Menu of RetroArch handles its priorities when it comes to its own theme and the shaders.
I could still create the Issue, though, but just wanted to mention that this is not related to what I was experiencing. :P

If you want bud, send me the details over PM and I'll gladly file an Issue report on GitHub :)
 
I'm afraid that issue is different from mine, as I never used shaders.
I only used the default Menu themes ones for XMB, I haven't use shaders from the pack that should go inside /retroarch/media/shaders.
Also, does the menu continue slugging up even after some minutes?

This could be related to an issue with how the Main Menu of RetroArch handles its priorities when it comes to its own theme and the shaders.
I could still create the Issue, though, but just wanted to mention that this is not related to what I was experiencing. :P

If you want bud, send me the details over PM and I'll gladly file an Issue report on GitHub :)
you're right, we better wait until @Radius4 commit is merged, and we will found out if it's the same issue or if it's related to shader implementation too or not :)
 
Last edited by cucholix,
  • Like
Reactions: ShadowOne333

Site & Scene News

Popular threads in this forum