I don’t have a specific composed list on hand, but usually the information is listed on their wiki. In example for Wave Race Blue Storm: https://wiki.dolphin-emu.org/index.php?title=Wave_Race:_Blue_Storm
|**Enable Dual Core**|Off|Avoid menu freeze up|
The answer provided by thingsiplay is the definitive one, though it may not last. Since Dolphin disables dual core by default now, there’s a chance the information regarding dual core issues will be scrubbed from the Wiki. Hopefully, they’ll still keep some mention to it, like “do not enable dual core for this game”.
I’m confused. If the new Dolphin core doesn’t fix the dual core issue, what’s the difference with the old core?
Ubershaders don’t seem to be fixed as well, since i get the same behavior as the old core with them. I’m also getting the same (subtle) frame pacing issues with 30fps games, despite standalone Dolphin having fixed this ages ago, not to mention some more recent focus on perfect frame pacing.
So what exactly is improved with this new core, compared to the last one? Is there a changelog? Does anyone have witness something working better than before?
It’s a good question. Old core was based on an old build of Dolphin; new core on a newer one. What I noticed so far:
About Dual Core: hunterk told us that the limitation is on RetroArch, not on the core. So far, it doesn’t seem fixable, and the core developer can’t do much about it, except salvage some titles using the GameSettings files.
About Ubershaders: I’m not saying it’s working properly, but I’ve gotten good results by deleting the old Cache folder and starting anew (make a backup, just in case). I’m using the “sync Ubershaders” option (not async Ubershaders), stutters happen, though minimal. Need to say that Dolphin developers maintain that Ubershaders reduce the stutters, but not always eliminate them.
About FramePacing: you can turn off the “Skip Presenting Duplicate Frames” and restart the core. Then, check if the game benefits from having “dual core” disabled and do it through the “SyncGPU = True” hack. Finally, check if it happens with other hardware-based cores (Dreamcast, PS2), for it may be an issue within RetroArch and your machine.
New fixes are on the way:
This is precisely why it’s taken so long to update it. There’s a big misconception about what issues with cores are caused by technical issues and/or libretro integration deficiencies vs core/emulation issues that are applicable to a libretro core and a result of an older codebase.
Nobody’s ever going to want to put the time into fixing the technical/integration issues if we don’t give the core a chance to stand on its own merits. We finally have an opportunity to break through the chicken/egg situation of updates vs integration here, so let’s not squander it by dumping on the still very much WIP results.
I’ve definitely seen improvements from game to game. I plugged in FZero yesterday, just briefly, to check it and it used to have serious graphics problems that seem a lot better. I’m sure we can find a lot of in game fixes… people have been waiting so long for a core update that this is definitely a huge step in the right direction. We should keep an eye out for those in-game improvements, even if they are minor. 
OMG an update … i never thought this day would come
Making use of this opportunity: could you elaborate a bit more about the libretro integration, please? I get the impression there’s two RetroArches: one rock-solid, stable and fully featured, for software-rendering cores; the other is kinda flimsy, with variable results, for hardware-rendering cores. When newcomers complain about RetroArch’s stability, I usually see them having trouble with the hardware-rendering cores.
Is it just an impression? How’s the situation? I use RetroArch since almost the beginning, and its scope back then was much smaller, so I wonder if the application had to adapt beyond its foundations. I’m not complaining, as my focus is up to 6th-gen consoles and RetroArch does just that, mostly with good results. I’m just curious, as those things are undocumented.
so … works Vulkan ? oO freezes for me with it … GL works for me
Did you try the deleting the .opt file trick?
yeah already read the suggestion …maybe something with my black frame insertion or CRT switch res maybe …it video and all inputs freeze on first frame …retroarchivment messages shows …i hear the GC bios intro after that …nothing on vulkan before it freezes it siwtched the resulution once
That was my only suggestion because I had the black screen freezing and crashing and that fixed it.
edit Actually, you might try without the bios, because I’m not using one.
libretro was designed around the concept of frames of audio and video generated in lockstep and pushed out in the form of a frame’s worth audio samples and a frame of video pushed into a buffer. This is how most traditional emulators work, and they fit right in there.
A lot of more modern emulators juggle multiple threads of audio and video generating asynchronously and don’t really work in discrete frames. They also often want to “own” the hardware video context and don’t like to hand it off without incurring a (usually small) performance hit (this is mostly an OpenGL problem, but when people refer to libretro having “overhead,” they’re often overstating this).
Then there’s complications of dynamic recompilers (which until recently were typically not written in such a way to work from a dynamic library), which are extremely architecture-dependent (which is more important as ARM gains prominence) and the writing/understanding of which is an esoteric skill, and both dynarecs and hardware-rendering complicate a lot of things we need to do.
In general, the more complicated an emulator is, internally, the more complicated it is to hook into libretro. There are things that can make it easier, but the dev teams behind most of the modern emus aren’t prioritizing those things–as is their prerogative, and which is understandable since they’re not trying to do the sorts of things we’re trying to do.
i try it Tomorrow otherwise …to lazy to change all that stuff now …and on the other side of the room is my real wii hooked up to a CRT anyways xD
Not trying to sound like a cheerleader, but RetroArch is like a beautiful science fiction to me. I love that I can re-live most of the games I loved when I was younger and I can’t really complain about anything too much.
like i say it works with GL video driver i don’t think that the bios screws with vulkan …and i deleted the old dolphin system folder where the bios ,nand etc. was stored
Hope you can figure it out, or someone here will know. I’m sure I double-checked mine yesterday and it was on vulkan, but I can look again.
edit Just opened Zelda Wind Waker and it was set to vulkan.
just weird …cuz it starts with other video drivers …i mess around with it in the morning
Edit the INI files in: RetroArch-Win64\system\dolphin-emu\Sys\GameSettings
Test each game one by one (I haven’t tested the traditional method with .ini files in: C:\RetroArch-Win64\saves\dolphin-emu\User\GameSetting, but that should work too.)
Many AR and Gecko cheats are automatically enabled if dolphin_cheats_enabled = “enabled” is active.
To disable them: delete the lines or add a # at the beginning of each line.
Add this to the .ini file of the affected game. : [Video_Hacks] FastTextureSampling = False
Based on my personal testing. If you have any other tips or fixes, please feel free to share them. Translation from French to English