Homebrew Official Retroarch WiiU (wip.)

ChiefReginod · May 18, 2021

Just to clear up any confusion, the info cache update only helps to rule out RetroArch itself as a point of slowdown, but if you're loading a big core or ROM it's going to take longer no matter how you slice it, especially if you have core reloading enabled.

20100 said:
No real improvement in ROM loading times with 1.9.3
For FBNeo Roms, I'm between 20 and 30 seconds (Core + ROM loading)

Everything is on a Sandisk Ultra 32GB SD-Card
ROMs zipped
Cache Core info file enabled
Core reloading Enabled (No crash when enabled, Used to crash randomly when disabled on older version, I will give a try)

THe good news is that everything is quite stable with most common cores (FBneo, Mame2003+, QuickNES, mGBA, Prosystem, Atari800, GenplusGX, Mednafen supergrafx, Mednafen Lynx, Snes9x, Stella2014)

Cannonball still freezing
And last but not least, Mednafen PSX and Mednafen Saturn working perfectly ! But it's a special version just for me

Disabling core reloading has been really stable from what I've tried. I launched 25 FB Neo ROMs without switching cores on 1.9.3 and didn't get a single crash. I even made a point to load games from different arcade systems, different sizes, games that are known to be hard to emulate, late-era CPS and Neo Geo, etc. If you still have issues, I would try auditing your ROMs with the latest DAT.

MarioSilva said:
Playlists have always worked

The problem was RetroArch reloaded basically everything each time you used them before, but now we have options to stop it from doing that.

vbarros22 · May 19, 2021

MarioSilva said:
Playlists have always worked

with that old editor
now I can make on the retroarch on wii u itself

n00bsaib0t · May 19, 2021

vbarros22 said:
with that old editor
now I can make on the retroarch on wii u itself

I’ve been making mine on WiiU the entire time.

ChiefReginod · May 19, 2021

I've encountered a bug that seems related to disabling core reloading.

How to reproduce:
1. Load a ROM in Genesis Plus GX or Snes9x Current (it happens in most/all other cores but is easier to reproduce in these two).
2. Quit RetroArch (don't click "Restart" or it might not reproduce).
3. Relaunch RetroArch.
3. Try to load a ROM with the last-used core via playlist or history. This leads to either a crash or 2048 launching instead.

It seems like RetroArch thinks the last core before the restart is still loaded, but by default the 2048 core is loaded on startup, so it mistakenly tries to load the content in that core.

An easy workaround is to just manually load any core on startup. After that, the error doesn't occur. Strangely, you can even reload 2048 on startup and it still seems to smooth things out.

tmnr1992 · May 19, 2021

Does version 1.9.3 fix the controller issues?

willianholtz · May 19, 2021

tmnr1992 said:
Does version 1.9.3 fix the controller issues?

In my tests, no!

20100 · May 21, 2021

ChiefReginod said:
I've encountered a bug that seems related to disabling core reloading.

View attachment 263474

How to reproduce:
1. Load a ROM in Genesis Plus GX or Snes9x Current (it happens in most/all other cores but is easier to reproduce in these two).
2. Quit RetroArch (don't click "Restart" or it might not reproduce).
3. Relaunch RetroArch.
3. Try to load a ROM with the last-used core via playlist or history. This leads to either a crash or 2048 launching instead.

It seems like RetroArch thinks the last core before the restart is still loaded, but by default the 2048 core is loaded on startup, so it mistakenly tries to load the content in that core.

An easy workaround is to just manually load any core on startup. After that, the error doesn't occur. Strangely, you can even reload 2048 on startup and it still seems to smooth things out.

Hi,
Same thing for me.

ploggy · May 21, 2021

ChiefReginod said:
I've encountered a bug that seems related to disabling core reloading.

View attachment 263474

How to reproduce:
1. Load a ROM in Genesis Plus GX or Snes9x Current (it happens in most/all other cores but is easier to reproduce in these two).
2. Quit RetroArch (don't click "Restart" or it might not reproduce).
3. Relaunch RetroArch.
3. Try to load a ROM with the last-used core via playlist or history. This leads to either a crash or 2048 launching instead.

It seems like RetroArch thinks the last core before the restart is still loaded, but by default the 2048 core is loaded on startup, so it mistakenly tries to load the content in that core.

An easy workaround is to just manually load any core on startup. After that, the error doesn't occur. Strangely, you can even reload 2048 on startup and it still seems to smooth things out.

20100 said:
Hi,
Same thing for me.

This is a know bug (not the crash the loading of another Core)

Important caveats:

There is a significant annoyance in the way that static builds work. If you run the ‘top level’ RetroArch app, then everything works as you would expect – but if you run a core directly (e.g. a specific core cia on 3DS), RetroArch doesn’t actually have any way of knowing which core is currently loaded. It ‘assumes’ you are running the last loaded core – which may not be the case. If it isn’t, the first ‘run content’ operation with Always Reload Core on Run Content disabled will cause an unnecessary fork (but the next ‘run content’ will behave correctly). Unfortunately there is nothing we can do about this…

ChiefReginod · May 21, 2021

ploggy said:
This is a know bug (not the crash the loading of another Core)

I'm sure it's more complicated than it sounds, but I wonder if something like automatically reloading the current core on startup for static builds would work. I've just been manually loading the 2048 core on startup as a workaround, which only takes a few seconds anyway.

I probably should have mentioned that I'm launching from the forwarder and only copied the "retroarch" folder to my SD card. Maybe it's different if you run RetroArch from the Homebrew Launcher.

ploggy · May 22, 2021

ChiefReginod said:
I'm sure it's more complicated than it sounds, but I wonder if something like automatically reloading the current core on startup for static builds would work. I've just been manually loading the 2048 core on startup as a workaround, which only takes a few seconds anyway.

I probably should have mentioned that I'm launching from the forwarder and only copied the "retroarch" folder to my SD card. Maybe it's different if you run RetroArch from the Homebrew Launcher.

That's cool, as long as there's a workaround that's good enough for me.

Iirc there was a line in the Retroarch.cfg you could change to specify a core to load on startup. I think it was called Libretro_path?
I don't know if it's still in there though?

.....................................................................................................

This was posted in another thread.. I'll post it here so it gets more attention

https://gbatemp.net/threads/retroarch-wii-u-devkitpro-r38-and-wut.581160/page-4#post-9476586 (from here)

ChiefReginod · May 22, 2021

ploggy said:
That's cool, as long as there's a workaround that's good enough for me.

Iirc there was a line in the Retroarch.cfg you could change to specify a core to load on startup. I think it was called Libretro_path?
I don't know if it's still in there though?

I just checked and there are actually two libretro_path lines. One is in retroarch.cfg and the other is the only line in retroarch-salamander.cfg. The first one seems to stay at 2048 no matter what do you but the salamander one is the last core that was loaded.

I've just confirmed that as long as those two lines match up, the error doesn't occur. This seems like something that could be fixed by deferring to the line in retroarch-salamander.cfg. I get that defaulting to one of the smaller cores makes for a faster startup, but it's only a one-time delay and most people are just gonna reload the last core they used anyway.

EDIT: Another way to fix this would be to automatically reset or delete the entry in retroarch-salamander.cfg on startup. The error doesn't seem to happen if you delete that file between shutting down and relaunching RetroArch.

ploggy · May 26, 2021

I managed to compile the Opera (3DO) Core but unlike the other Cores I compiled I had to mess with the Makefile, something I know nothing about

I'm almost sure I did something wrong but it does successfully compile and runs on WiiU.. but it just shows a black screen when I load a game :/

I'll upload it here incase I'm doing something stupid and someone else can get it to load a game successfully..

azy77 · May 27, 2021

Wow thanks Ploggy, who knows one day it may reach a playable state.

Also, apologies if this has been asked before, is there any way to make shaders work on 1.9.3? I placed the slangp shaders in shader folder but everytime I try to load any shader it says failed to apply shader.

Edit: Nevermind, needed compiled shaders which I finally found online and all is good now. Flipping heck I should never have deleted my old RA folder as forgot all these things.

willianholtz · May 27, 2021

Who are responsible for the builds of wiiu?
Is there any news coming there? How is the project progressing? (wii u only)

ploggy · May 27, 2021

willianholtz said:
Who are responsible for the builds of wiiu?
Is there any news coming there? How is the project progressing? (wii u only)

This was posted in another thread..
https://gbatemp.net/threads/retroarch-wii-u-devkitpro-r38-and-wut.581160/page-4#post-9476586 (from here)

ChiefReginod · May 29, 2021

1.9.4 is up on the buildbot.

http://buildbot.libretro.com/stable/1.9.4/nintendo/wiiu/

Changelog:

CHEEVOS: update rcheevos to v10.0.0
CONTENT LOADING/FILE IO: Prevent unnecessary extraction (to disk) of compressed content files when need_fullpath is false
CORE INFO/FILE IO: Enable core info cache by default now for all platforms
CORE INFO/REGRESSION FIX: Fix regression caused by core info file caching - Downloads was no longer showing up in Load Content
FILE IO/COMPRESSED: Ability to load content inside ZIP files directly into RAM
INPUT/OVERLAYS: Add option to select between 'touched' elements and physical controller inputs when showing inputs on overlays
INPUT REMAPPING/OVERLAYS: Prevent duplicate inputs when using remaps with input overlays
LAKKA: Add brightness restore hook
LOCALIZATION: Fetch translations from Crowdin
MENU/OZONE: Added simple playlist entry enumeration
MENU/XMB: Fix display of 'Maximum Users' menu entry dropdown list
PS3/PSL1GHT: Joypad driver works again
PSTV: Fix Vita input driver for PSTV
PSTV: Support for 720p on PSTV when using 'Unlock framebuffer' in Sharpscale plugin
RPNG: Fix some memory corruption if processing broken input PNG file
SECURITY: Fix CVE-2021-28927

ChiefReginod · May 29, 2021

I did a bit of testing and it looks like zipped ROMs load much faster now in some cores. Super Street Fighter II in Snes9x took 3-4 seconds before but only takes about a second now. There was no change in Genesis Plus GX or mGBA. I haven't checked many others yet.

I guess not all cores support loading zip files straight to RAM, but it's a significant boost for the ones that do.

20100 · Jun 2, 2021

Hi,
No real change for me (between 15 and 30 seconds overall depending on the core and on the Rom)
Probably a lazy SD Card.

ShadowOne333 · Jun 2, 2021

20100 said:
Hi,
No real change for me (between 15 and 30 seconds overall depending on the core and on the Rom)
Probably a lazy SD Card.

Try deleting the retroarch.cfg and try again with a fresh setup.

20100 · Jun 2, 2021

Hi,
Thanx, I will try
As Brian Molko says, ..... and start again, start again.

EDIT : Absolutely no change inloading time after deleting retroarch.cfg
For Example :
21 seconds loading Mame 2003+ Core
Total 25 seconds loading Outrun Arcade + Mame 2003+ Core

Homebrew Official Retroarch WiiU (wip.)

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

WAKA! WAKA!

Well-Known Member

WAKA! WAKA!

Well-Known Member

WAKA! WAKA!

Attachments

Well-Known Member

Well-Known Member

WAKA! WAKA!

Well-Known Member

Well-Known Member

Well-Known Member

QVID PRO QVO

Well-Known Member

Similar threads

Popular threads in this forum