I’ll report the issue, it’s annoying not being able to clear shaders/overlays, I agree
Thanks, if anything can be done also about resolutions saving on a per core config basis it would be pretty much a perfect programme for me on Wii 
Just tested 1.0.2, works like a charm, the cores I used work very well, esp. GBA 
This is like 90% the reason why people wanted per core configs. I don’t understand why they just skipped it, the 640 width is not practical for a majority of cores.
This is like 90% the reason why people wanted per core configs. I don’t understand why they just skipped it, the 640 width is not practical for a majority of cores.[/quote]
Who knows why they did, are they aware of the per-core settings at all, or why it’s broken? It’s been broken ever since it was implemented. :rolleyes: Kinda defeats the purpose doesn’t it.
I love the quality of the emulation and the emulator as a whole, don’t get me wrong, it’s very solid and very stable, the best on Wii, but why this is still an issue is baffling. Are the bug reports falling on deaf ears?
This is like 90% the reason why people wanted per core configs. I don’t understand why they just skipped it, the 640 width is not practical for a majority of cores.[/quote]
Who knows why they did, are they aware of the per-core settings at all, or why it’s broken? It’s been broken ever since it was implemented. :rolleyes: Kinda defeats the purpose doesn’t it.
I love the quality of the emulation and the emulator as a whole, don’t get me wrong, it’s very solid and very stable, the best on Wii, but why this is still an issue is baffling. Are the bug reports falling on deaf ears?[/quote]
Not really, different input mappings may have been the driving force between per core configs
And yet, it’s broken, so, the question is, do they know about this issue at all. Do we need to contact them via PM or IRC or the Github as Charco suggested? I mean, surely, something will be done to neutralize this issue…? Not trying to sound desperate, but what can we do?
Did some testing there and found the following:
- Core options, path settings and aspect ratio all save for each core.
- Resolutions do not save.
- Buttons are unresponsive on Neo Geo Pocket core.
EDIT: I had a look in the fba_cores_cps2_libretro_wii.dol.cfg file and can see that it has the resolution I want for this core: custom_viewport_width = “384” custom_viewport_height = “448”
But when I load the core it defaults to retroarch.cfg with a default 640 x 480 resolution. Should it not choose the fba_cores_cps2_libretro_wii.dol.cfg file with the correct resolution?
I did two clean “installations” and in both cases, the savefiles and savestates paths get changed for the default “sd:/Retroarch/savefiles” both editing the cfg and changing the paths in the Wii itself, which I find annoying; but on the other hand, the rest of the paths doesn’t change, which is a great step forward.
Besides that, Fceumm hung up my console several times when I was trying to set it up, I guess is better to not use it for the moment (With QuickNES and Nestopia I don’t think is all that important, unless Fceumm was that much better before, IDK).
That said, I notice even better emulation in some cores, which is fantastic! And some of the new options look interesting, although I didn’t have the time to play and try things with them. Something I really want to try is making borders with those overlays.
Retroarch keeps getting better and better.
[/quote]
And yet, it’s broken, so, the question is, do they know about this issue at all. Do we need to contact them via PM or IRC or the Github as Charco suggested? I mean, surely, something will be done to neutralize this issue…? Not trying to sound desperate, but what can we do?[/quote]
It’s broken because it hasn’t received enough testing, the forum is a user forum and most of the time not the best place to submit bug reports. It’s a good place to discuss features and possible bugs but yeah someone needs to step in and submit a bug report every once and then.
Actually I’ve submitted a report about this once but it was overlooked, guess it might be because it only affected some trivial features: https://github.com/libretro/RetroArch/issues/522
Maybe you should add your findings there?
The neogeo pocket issue, does it happen if you use your standard config or only with per core configuraton? I need to know wether it’s related or not
Not trying to be a smartass or anything, actually I try to keep track of the threads so I can find and report more obscure bugs. Anyway here is something I read once regarding contributing to Open Source Projects http://blog.smartbear.com/programming/1 … rock-star/
I was just using the standard config, chose the core and loaded a game. None of the buttons worked, i checked input options and the correct input is detected, Classic Controller. Buttons work fine on all other cores.
Then that’s a different issue altogether, Can anyone else reproduce that one? If confirmed that should be reported here https://github.com/libretro/mednafen-libretro
I thought Mednafen PSX wasn’t for the Wii…? Anyways, so we know that it hasn’t been tested enough, but no matter how much we do on our end, what will the end result be? I guess I could add to that https://github.com/libretro/RetroArch/issues/522 my findings and other problems with per-core config.
I’ll mess with more settings, like changing the key mapping for fast forward, they don’t save either. Not sure what good it will do to get their attention by posting my findings, but it can’t hurt.
I thought Mednafen PSX wasn’t for the Wii…? Anyways, so we know that it hasn’t been tested enough, but no matter how much we do on our end, what will the end result be? I guess I could add to that https://github.com/libretro/RetroArch/issues/522 my findings and other problems with per-core config.[/quote]
it’s the same repository for all mednafen cores.
Testing will help the devs find about problems. Per-core configs was never deemed as ready as far as I remember, it’s impossible to find issues unless we report them.
I thought Mednafen PSX wasn’t for the Wii…? Anyways, so we know that it hasn’t been tested enough, but no matter how much we do on our end, what will the end result be? I guess I could add to that https://github.com/libretro/RetroArch/issues/522 my findings and other problems with per-core config.[/quote]
it’s the same repository for all mednafen cores.
Testing will help the devs find about problems. Per-core configs was never deemed as ready as far as I remember, it’s impossible to find issues unless we report them.[/quote]
Yeah, that’s true, just not sure what to test thoroughly or how to properly post my findings yet.
There is no right way, try to test thoroughly before opening one, confirm with other users on the forum or IRC if possible and post the problem, how to reproduce it and what should happen instead.
I’m not familiar with the code behind that but I’ll take a look anyway
The IRC if on efnet, #wiidev or #vwii or something like that? I forgot the channel. But I’ll try making base config files (opening the cores I use, then press “create new config”, close HBC, go on my laptop, then see what I can change, put them back on the SD card and go from there. Something like that, I can even record a video of the process to better explain how to reproduce the error
Never tried that, but I can drop by when I’m ready. But yeah, I think if I can capture the process or steps to show that it doesn’t save, might help explain to the devs clearer than if I tried to explain it =D
Godlance reported the NGP control bug on the main RetroArch issue tracker, which Squarepusher replied to and said he’d take a look at. The bug is known.
As for discussion of the hardcoded resolution saving being “broken”, I don’t believe this is the case. Rather, it’s simply not implemented. Maybe the devs have a reason they don’t want to save hardcoded resolutions, maybe not, but to call it a bug seems iffy because it’s clearly just not intended behavior at the moment. This is a feature that many of us (myself included) would like to see, not a bug.
EDIT: Also, some of you seem to be using per-core configs wrong. You don’t use the “create new config” menu option. When you have the per-core config option enabled (under General Settings, IIRC), RetroArch will automatically write any changed settings to both the per-core file and the overarching retroarch.cfg. When you load another core, retroarch.cfg is automatically populated using that core’s per-core values. So RetroArch will always default to retroarch.cfg, but this doesn’t mean per-core configs aren’t working. Basically, 99% of users don’t need to ever use “create new config”. The intended usage of this seems to be for users who turn per-core configs off but still wish to use multiple unique configs manually.
The need to use “create new config” for any kind of per-core settings is something that only existed in some unofficial, between-version builds before the functionality had been completed.
FYI, the way configs work (by copying them from per-core to retroarch.cfg on core launch) means you can actually use per-core config with old cores like Mednafen Neo Geo Pocket/Color from v0.9.9. While that core doesn’t understand per-core settings, it reads settings from retroarch.cfg just fine. So if you set up the current (broken) NGP core to your liking with per-core config, you can subsequently load the legacy core with settings intact. It does mean you need to load the current core prior to the legacy core any time you wish to play NGP games, but it’s easier than redoing your settings each time.