Dolphin Emulator Iso Not Working

[Nichele Seibel]

Hifor some reason dolphin emulator will not recognise any controls (gamepad or keyboard) when trying to play Gamecube. Ive tried to configure them manually using the Dolphin application (using the F1 key to access), but still cannot get it to recognise anything.

riom

what kind of controller do you use?

and did you configre the button-mapping within batocera (Controller Settings, Configure A Controller)?

do the controls work in other systems like SNES for example?

Why do you open dolphin emulator within Applications?

You should just open the games via gameslist in Emulation Station and your controller should then work out-of-the-box (except, there is a compatability issue with Gamesir GS3 bluetooth controller, then this has to be investigated)

i know that there are some pads, that have issues, especially with dolphin (and Dreamcast (reicast or flycast) i believe).

at least i remember some users reporting issues with certain pads (xbox 360 clones for example).

maybe the GameSir GS3 (wirelessly) and that unbranded generic Bluetooth USB controller are also pads, that have some issues/incompatability with dolphin also?

best is to come to the discord and ask there under #support

regarding your issue with xbox 360 controller i will try to reproduce (i also own some Xbox 360 wireless controllers)

is it only the down direction of the left analog stick, that is not working or are there other issues as well?

I don't think this is related to audio, I had the same thing before applying the fix.

It's just that I was lucky enough to be able to lunch it a couple of times before.

Now it seems I have bad luck.

Anyway, that GitHub thread talks about JIT compilation, so I would have recommended that you run paxctl +m on the Dolphin executable, but it seems that we've been taking care of that automatically already. -emu/Makefile#L43-L45

HOWEVER, pkgsrc doesn't use this 'project-slippy/Ishiiruka.git' version of the code. We're using the code at dolphin-emu/dolphin.git. I'm not sure what the relationship between the 2 codebases is, but my guess is that dolphin-emu/dolphin not having had a formal release since 2016 (!!) is what's motivated this "Ishiruuka" thing -- which had a new release just a couple of weeks ago.

I wonder if it makes sense for the emulators/dolphin-emu package to use the "Ishiiruka" code base going forward. I might even try to make a package for "Ishiiruka" and put it in wip and we could see if it makes a difference.

You might also try emulators/libretro-dolphin, or maybe what we really need is a wip/dolphin-emu-git which keeps track of the bleeding edge, since running the "development" and "beta" versions seems to be the norm for Dolphin. I know I use them when I run Dolphin on macOS and Windows. -emu.org/download/?ref=btn

Super long story short: the version of Dolphin that has been made to integrate with RetroArch is not exactly the same one as the "vanilla" upstream version (github.com/dolphin-emu/dolphin.git). Therefore, it's worth trying out.

My dolphin-emu was working fine last night, but I updated arch today and now everything has stopped functioning. I am unsure of what to do. Whenever I launch a game through this application, the game will just sit there with a black screen and nothing initiates. After a few seconds pass by, the application will crash and my terminal output gives me this message:

EDIT: Furthermore, whenever I try and delete both configuration folders (dolphin-emu in .config (folder for application settings) & dolphin-emu in .share (folder for saved games and memory cards) and attempt to revert the application to its default state, it doesn't function correctly. Whenever I click on 'set game directory/double click' in the center of the screen and navigate to the folder with my games, it doesn't add them despite listing the directory paths in the games folder when I open the configuration panel up and look under 'paths'.

As it turns out, something broke with the package, dolphin-emu. After doing a bit of searching and testing on another machine, I found the same results. So that tells me that the maintainer or developer of this particular package could have changed something vital for the emulator to actually run.

Yes, you're right, I will leave it marked as unresolved for now. I really don't know what to say, it's been like this for a couple months now. The only thing I found to work around this is to use the git version

I've just recompiled dolphin-emu-git and didn't get any errors. However one of the dependencies, libspng, requires manually importing the GPG key (linked in its PKGBUILD) or forcing a gpg check skip on it, otherwise the whole installation will fail.

I did try the regular dolphin-emu from the Arch's repo just now as well and it still segfaults as before so I'll keep sticking with the AUR git version. I don't quite understand why fixing the official package is taking so long, I thought it was built from the AUR package anyway?

Like I said, the development version is the best bet at the moment, but even it has a few issues in building. (Easily fixed) It will at least play your games without segfaulting all the time. And I don't know either, if its in the official Arch repo, you would assume it's been verified but it's been in this state since June.

It had its inaugural release in 2003 as freeware for Windows. Dolphin was the first GameCube emulator that could successfully run commercial games. After troubled development in the first years, Dolphin became free and open-source software and subsequently gained support for Wii emulation. Soon after, the emulator was ported to Linux[28] and macOS.[29] As mobile hardware got more powerful over the years, running Dolphin on Android became a viable option.

Dolphin has been well received in the IT and video gaming media for its high compatibility, steady development progress, the number of available features, and the ability to play games with graphical improvements over the original platforms.

Dolphin was first released in September 2003[30] by Henrik Rydgrd (ector) and FRES as an experimental GameCube emulator that could boot up and run commercial games. Audio was not yet emulated, and the overall performance quality was very poor. Many games crashed on start-up or barely ran at all; average speed was from 2 to 20 frames per second (FPS). Its name refers to the development code name for the GameCube.[31]

Dolphin was officially discontinued temporarily in December 2004, with the developers releasing version 1.01 as the final version of the emulator.[32] The developers later revived the project in October 2005.[33]

Dolphin became an open-source project on 13 July 2008[28][34] when the developers released the source code publicly on a SVN repository on Google Code under the GPL-2.0-only license.[28] At this point, the emulator had basic Wii emulation implemented, limited Linux compatibility and a new GUI using wxWidgets.[28] The preview builds and unofficial SVN builds were released with their revision number (e.g., RXXXX) rather than version numbers (e.g., 1.03).[35][36] As with previous builds, differences between consecutive builds are typically minor.[37]

By April 2009, most commercial games, GameCube and Wii alike, could be fully played, albeit with minor problems and errors, with a large number of games running with few or no defects. Adjustments to the emulator had allowed users to play select games at full speed for the first time, audio was dramatically improved, and the graphical capabilities were made more consistent aside from minor problems.[39]

By late October 2009, several new features were incorporated into the emulator, such as automatic frame-skipping, which increased the performance of the emulator, as well as increased stability of the emulator overall.[40] Also improved was the Netplay feature of the emulator, which allowed players to play multiplayer GameCube and Wii games online with friends, as long as the game did not require a Wii Remote. The emulator's GUI was also reworked to make it more user-friendly, and the Direct3D plug-in received further work.[41]

By the end of November 2010, the developers had fixed most of the sound issues such as crackling, added compatibility with more games, and increased the overall emulation speed and accuracy.[citation needed]

On 25 December 2012, version 3.5 of Dolphin was released, featuring support for emulating the GameCube Broadband Adapter and Microphone accessories. It introduced a FreeBSD port, free replacement for the DSP firmware, and the WBFS file format.[44][45]

On 6 April 2013, the Dolphin development team released the first builds for Google's Android mobile operating system.[46] As of September 2013, only a handful of devices contained the hardware to support OpenGL ES 3.0, with Google officially supporting the standard in software since July 2014 with the introduction of Android 4.3 Jelly Bean. Games ran at an average of one frame per second. The developer has cited the Samsung Galaxy S4 as one of the first phones capable of playing games at higher speeds, but even it would have considerable performance limitations.

On 22 September 2013, version 4.0 of Dolphin was released, featuring back-end improvements to OpenGL rendering and OpenAL audio, broader controller support, networking enhancements, and performance tweaks for macOS and Linux builds.[47][48] Months later, versions 4.0.1[49][50] and 4.0.2[51][52] were released, fixing minor bugs.

On 12 October 2013 (4.0-155), Direct3D 9 support was removed from the project, leaving Direct3D 11 and OpenGL as the two remaining video back-ends. The Dolphin Team explained this, stating that the plug-in was "inherently flawed" and that trying to evade its several flaws "wasted time and slowed development."[53]

On 19 May 2014, the Dolphin Team announced that 32-bit support for Windows and Linux would be dropped.[11] The Dolphin Team stated that it was becoming increasingly difficult to maintain the 32-bit builds, and that the 32-bit releases simply offered an inferior experience compared to their 64-bit counterparts. Furthermore, the vast majority of their users were already using 64-bit CPUs, and most users of 32-bit builds were 64-bit compatible yet were using 32-bit by mistake. The combination of these factors made 32-bit support unnecessary. 32-bit Android builds suffered from similar issues, but ARMv7 support[54] remained for another year until the AArch64 JIT was ready and devices were available.[12]

3a8082e126