December 4, 2012 - 12:43pm
#1
Jhonn
Offline
Last seen: 2 months 4 weeks ago
Joined: 2008-10-06 12:32
Dolphin Emulator Portable 5.0 Pre-Release 1
Application: Dolphin Emulator
Category: Games
Description: Dolphin is an emulator for two recent Nintendo video game consoles: the GameCube and the Wii. It allows PC gamers to enjoy games for these two consoles in full HD (1080p) with several enhancements: compatibility with all PC controllers, turbo speed, networked multiplayer, and even more!
Download Dolphin Emulator Portable 5.0 Pre-Release 1 [8MB download / 28MB installed]
(MD5: 618C5597BDD65D65C6A8D5F29FBB9846)
Frequently Asked Questions:
Why are there a lot of DLLs that doesn't come in the official release and builds from dolphin-emu.org?
- Those additional DLLs must be bundled for app-local deployment of Visual C++ 2015 compiled apps (like Dolphin) and some DirectX runtimes must be bundled as well to make Dolphin Emulator fully portable.
Is this PAL compatible with the current development versions? How can I update?
- Yes, it is. As Dolphin development are quite active and new builds come almost every day, this installer ships with the latest official stable release (currently 5.0) and it's up to the user to update it to a newer development build if they want. To use this launcher with development builds released after 5.0, just download the build you want directly from the official website and unzip its contents in App\Dolphin, always overwriting any files and folders that already exist. Any build released before 5.0 (regardless of being a stable release or not) is not supported and won't work.
I manually updated to a newer development version of Dolphin and PortableApps Menu Language Switching feature isn't working anymore. Why?
- Starting with version 5.0-823, Dolphin now uses ISO 639 locale codes when storing its language settings. To make this PAL compatible, you need to manually edit the launcher's INI file with some replacements (already bundled with this PAL). Read the commented section at the end of "DolphinEmulatorPortable\App\AppInfo\Launcher\DolphinEmulatorPortable.ini" for more details on what you should do to restore language switching feature on those newer builds.
Release Notes:
5.0 Pre-Release 1 (2016-09-13):
- Updated to Dolphin 5.0
- As Dolphin is now a 64-bit only application, the launcher now checks the OS and abort if running on a 32-bit PC
- Due the high amount of changes in Dolphin itself, this release will only work with Dolphin 5.0 or development builds released after it
- Following Dolphin changes, DSP and IPL ROM dumps should be stored directly in Data\User\GC. If you had them stored previously in App\ROMs, they'll get wiped during the update, so make a backup before updating to this release
- Automatic language switching based on PAM settings is now supported
- Multiple portable and local instances can be executed concurrently without any issue now
- Many under-the-hood improvements to make the launcher more stable and reliable
- DirectX Portable dependency removed (it's abandoned and can't even be downloaded anymore). For compatibility purposes, the launcher can still load the required runtimes from it if they're not found elsewhere and you still have DirectX Portable installed
- Updated EULA: now using RTF format and in addition to DirectX EULA, Visual C++ 2015 EULA added as well
4.0.2 Development Test 2 (2013-12-03):
- Updated to Dolphin 4.0.2.
- DSP and IPL ROM dumps are properly handled again (updated the launcher to use the new locations from Dolphin 4.x)
- XAudio2 is now properly handled and a portable copy can be used by running the launcher with administrative privileges. The launcher also warns the user now if XAudio2 is selected in an environment it isn't available
- All directory moves are handled correctly now
- The launcher now correctly detects the presence of the needed DirectX DLLs and handle it accordingly, either using a bundled copy, a local copy or the DirectX Portable install
- Added a feature to prevent storage device entering sleep state (see the launcher's Readme.txt for more details)
- Updated help files and EULA
- First run delay on slow devices fixed by moving the folders instead of copying them
- Both variants (x86 and x64) are mandatory now and Multilanguage support became optional
- Overall size reduced. Many duplicated files between 32 and 64 bit builds were merged to CommonData folder
- User can now enable backward compatibility by adding LegacyMode entry in the launcher's INI, bringing back correct DSP and IPL ROM dumps handling for Dolphin builds older than 3.5-2381 (see the launcher's Readme.txt for more details)
4.0 Development Test 1 (2013-10-01):
- Updated to Dolphin 4.0. Please note that this version may have issues with the DSP and IPL dumps. A completely new launcher will come soon with all features and bugfixes needed to be released as official
3.5 Development Test 2 (2013-02-21):
- Dropped online installer in favour of DirectX End-User Runtimes Portable
- Custom code completely rewritten
- CLI argument passing is working again
- The installer is now fully compatible with PortableApps Updater
- Removed Run As Admin requirement
3.5 Development Test 1 (2012-12-24):
- Updated Dolphin to 3.5 Stable
3.0 Development Test 3 Rev 2 (2012-12-18):
- XAudio2 backend now works properly (requires administrative privilegies)
- Fixed some issues that would occur when the optional x64 build weren't installed
- Some code refactoring
3.0 Development Test 3 (2012-12-13):
- Prevent breaking Microsoft EULA by downloading the files during the install and by including the DirectX EULA
- The 64 bit variant install is now optional
- The settings and ROM dumps are now properly handled by the installer: they won't get deleted anymore during an app update
- Full support for command line argument passing through the Launcher
- Updated help file and other related stuff from "Other" folder
3.0 Development Test 2 (2012-12-07):
- Proper handling for the DSP LLE required ROM files and the optional GameCube IPL files
3.0 Development Test 1 (2012-12-04):
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
The "help . html" file in the root, must not be the generic help file. Then please include an "help . html" file related to Dolphin Emulator.
This help file will be updated soon, actually I just included the generic one in this release because PortableApps Installer required this file to compile the install package
The package include now a proper help file
Where someone place roms to use it in this portable version.
Did it go Inside "Data" ?
And/Or someone will have to create a "Roms" directory inside Data ?
Like see below
DolphinEmulatorPortable
|
|||Data
|||
||||||Roms
Please note, ... "DolphinEmulatorPortable 100% portable software", must have all file(s) included in the "DolphinEmulatorPortable sub directory(s)", in example for iso and roms must go Inside "Data\Roms" sub directory.
I'll make sure that a default folder for ISOs and WADs are specified with the Default Data (config here get copied in the first run of the apps). If I put the default ISO folder in Data folder, this would cause issues, GC ISOs have around 1.35GB and Wii ISOs around 4.7 or 8.5GB. If you, sometime, go to the PortableApps Backup and choose "backup app data (settings, bookmarks, etc)", you would get the big ISO files together the other app data.
This is why I'll make a default folder for ISOs inside "Documents" folder, something like default download directory for uTorrent.
About the ROMs, Dolphin doesn't play any ROM file, however, to use DSP LLE backend you'll need the files dsp_rom.bin and dsp_coef.bin (that must be dumped from a real GC or Wii). As it's like an addon, it'll probably go to a subfolder in App folder (like Audacity does with Lame and ffmpeg)
I'm working on this, so these issues will probably be all addressed when I release Dev Test 2
Also, thanks for the feedback
I'd suggest placing it within App\Roms or similar. Specify that as a 'plugins' directory within AppInfo.ini and a preserved directory within installer.ini.
Sometimes, the impossible can become possible, if you're awesome!
Yes, I'm going to add this like that. Also, thanks for the information about installer.ini, didn't know about this fuctionality...
As someone who has done a few emulators, it might be best to store the Roms in the Documents folder. I accidentally lost a lot of Roms because I uninstalled one app.
Whether you put it in App or Data, an app uninstall would have nuked them all.
I still have one more emulator to release, Project 64, and I wonder how that will work now that mudlord posted the source code. That leaves me wanting PS1/2 and this emulator, which now has a dev test.
Link still goes to Dev Test 1.
Fixed that, sorry for the delay
by distributing the dlls for the directx runtime you are breaking the eula microsoft has for them, unfortunate as this is, there is no way around it.
your friendly neighbourhood moderator Zach Thibeau
He might want to look at my VBA-M and Snes9x betas. I copy it off the PC if it exists, so if you run it on one PC that has it, you are set when another doesn't.
No distribution in the app there. I then make sure to preserve it using installer.ini.
vba-m has a compile switch to disable d3d/xaudio2 stuff using opengl/openal which are allowed to be redistributed
your friendly neighbourhood moderator Zach Thibeau
Yeah, well my machine and a lot of others can't use them properly.
XAudio2 I believe is a part of Vista+.
I'm not sure how much this needs DX.
Doesn't LibreOffice do something with the VC Runtimes?
Microsoft Developer Guide says that developers should add an offline installer or use the web installer, including Microsoft EULA during setup and then calling a "silent setup" through the directX web installer we just downloaded, to download and install the required components.
Since this is a portable version, we can include the Microsoft EULA in the installer and specify the installer to download these files but to unzip the required files using 7za or something similar instead of installing it. Also, there isn't any enclosure in Microsoft EULA that prevent us of doing something like this (as long as we use Microsoft URLs to download them)
Also, copying the files from the PC that already have it wouldn't solve this issue if the computer doesn't have the DLLs when you launch the application. Also, there isn't any way of making Dolphin not use these DLLs (like what can be done with VBA-M)
I'll implement this in the next installer (for Dev Test 3)...
Apparently there isn't any way of downloading more than one file right? Currently I'm using custom code, however this make the installer be not compatible with the Updater, right? What should I do to "fix" this (I'm pretty sure this app can't be official with an issue like this)?
I would like to hear from John if this is fair game.
I'll gladly add such a technique to Snes9x and VBA-M if he allows it.
Also, did you see my INI stuff to add that ISOs directory?
Does it work if the files are included in the PATH, say if we have a CommonFiles\DirectX location and include that? That way we could have them as an option for folks who want it (without duplication) and not worry about it for others.
Sometimes, the impossible can become possible, if you're awesome!
Not sure, but I guess it would be an app basis.
VBA-M only needs the dx43 (whatever name), while Snes9x only needs the 38dll.
They can load them from their current directory.
How can I set it to PATH? I'll test it out and could work up an installer.
EDIT: Seems I got it set to C:\DX and got Snes9x to load video using Direct3D just fine.
We'll do something like extract it to CommonFiles\DirectX. You can point it to that in the [Environment] section of the launcher.ini setting PATH so it works. You can use %PAL:PortableAppsBaseDir%\CommonFiles\DirectX as that actual piece.
Sometimes, the impossible can become possible, if you're awesome!
My test of DirectX was mostly successful.
I wasn't sure how to handle PATH in the launcher (could you show the whole thing?), so I added it using Environment Variables in System CPL.
I tested Dolphin, Snes9x and VBA-M on a clean XP SP3 VM.
With no DirectX, none of these apps will run at all, with path set to my DirectX installer, all run.
All video (which requires DirectX for Direct3D) runs fine.
The gotcha occurs when you need XAudio2 (which is actually a part of Vista+, so you have to test XP).
It cannot initialize XAudio2 just by finding the DLLs. While you can use DirectSound (which doesn't need DirectX), XAudio2 should work for a proper DirectX setup.
I tested what dxwebsetup.exe does, and I got all the DLLs in one place. Other files I don't need are cat and inf stuff.
It adds some CLSIDs to the registry (DLL Registration).
We have to register the DLLs in order for full function. I believe the Platform could easily handle the register and unregister, but for now I will write custom code for apps to use.
I suppose Dolphin could rely on the DirectX installer that I can release, like how I use gluxon's OpenJDK for Netbeans now (though that "just works"). Either way, we need to register stuff to handle XAudio2.
I could provide register/unregister code, you add it to Dolphin, and I add it to Snes9x and VBA-M.
What I need is a reliable way to tell if DirectX is installed. We shouldn't screw with the DLL registration if a local DirectX exists (we could though, but I don't see the need).
I'd like to only unregister if DirectX isn't installed.
My tests confirmed that you can run regsvr32 on the xactengine dlls and xaudio2 (not x3daudio, don't need to touch those), and you can get XAudio2 sound working in all emulators.
So DirectX Portable + Register XACTEngine and XAudio2 + Unregister When Done = Fully Portable DirectX Runtime.
OK I got the [Environment] Path stuff working.
I made Custom.nsh Launcher code to register DirectX dlls if needed.
My procedure is to check $SYSDIR for all of the dlls that need registered. If any one of those DLLs is missing, I register the copies in CommonFiles\DirectX\bin.
The same macro to check installation is used on app close. If one of those DLLs was missing from $SYSDIR, I unregister all of them.
I only check for the dlls that need registered. It doesn't matter if any other dlls are missing as they all end up in the %PATH%, and none of those other DLLs need registered.
So I assume that if all those DLLs exist, then the PC must have local DirectX and that will take precedence (all DLLs would be searched in System32 first, if missing in CommonFiles\DirectX\bin).
Where I need to figure out 1 implementation detail is the following.
I made 32 and 64 bit DirectX runtimes. I believe a 64 Bit app needs the 64 Bit runtimes.
A launcher sets the path, and there is the option to choose exe to run if OS = 64 Bit. But you cannot set the path accordingly based on the bitness.
I believe this could be handled by custom code for now. Only Dolphin runs into this issue, as Snes9x and VBA-M and 32 Bit only (always use 32 Bit runtimes). I see Jhonn sets the Working Directory based on $Bits. You could set PATH here for Dolphin DirectX based on this as well, instead of using [Environment].
I need to register the 64 Bit DLLs as well, but I suppose no harm done in registering both instances if the OS = 64 Bits.
Testing with Dolphin, it'll only load the DLL if it's on C:\Windows, C:\Windows\system32 or in the Dolphin.exe folder.
The app open, but when I start a game I get the error "Failed to load an compatible DirectX DLL"
I think that a best way should be creating an "plugin installer" that unpack all DirectX runtimes DLLs in CommonFiles\DirectX and then in the app launcher we set a flag or something that copy the required DLLs to App folder, run the app and after that, delete the copy (or move it back to CommonFiles)...
I'll test further, still working on the best and cleanest way to handle this.
I'm going to test Dolphin, VBA-M, and Snes9x for DirectX support.
I managed to create a DirectX plugin installer for both 32 and 64 bit (separate like jPortable).
I'll do so tomorrow.
If you want to add in the ability to have a Roms directory, try the following.
1. Add a Roms folder to DefaultData
2. Add this Dolphin.ini to DefaultData\Config
3. Add the following to the launcher ini file:
Now on first run, you have created the Roms folder, and the launcher will always update it. Any roms put in this folder will be found by Dolphin.
PS: It may be more accurate to call the App\ROMs folder App\BIOS, given that roms = games, whereas the IPL files are BIOS files.
I am thinking of adding a BIOS folder to VBA-M (but in Data), though there is little benefit to using a GBA BIOS on VBA.
You write
GCMPath0 =
Did it's instead of GCMPath0 =
GCMPath0 = ./Roms
Did someone that have in example, "10 Wii game iso" and "10 GameCube game iso", will have to wait each time it close the Dolphin Emulator portable software, for the transfert of Roms inside data directory on a slow portable device ?
Not sure what you are asking.
There should be no lag caused by adding to that folder, we never move it around unlike all the others.
The path I set requires no editing or movement of folders.
Dolphin doesn't run any kind of ROMs, only ISOs. I called the dump folder as ROMs because they're ROM dumps from physical chips in the real consoles. BIOS isn't an appropriate directory name because the DSP dumps aren't BIOS files, and the GameCube itself uses the name IPL instead of BIOS. Also, these dumps are optional, like additional plugins (see ffmpeg for Audacity). This is why they should be put in Apps folder, not in Data folder (I'm just following the PortableApps Specification).
The default ISO folder will be put in Documents directory instead of Data directory: this prevent issues with PortableApps Backup utility and also prevent the deletion of all ISO files that the user has if it choose to uninstall the app...
Thanks to clarify, the usage of ROMs inside Dolphin portable.
The Development Test 3 version actually contains the biggest code changes that I've ever made since I started working on this. Some DLLs are downloaded from Microsoft, but since my PC already have them, I can't do some tests.
What I'm asking is testing the emulator in older machines running Windows XP. The most important: test a lot using the DX9 or DX11 as GFX backend and the XAudio as audio backend. If you get some error about missing DLLs or things of this kind, let me know, to make the needed fixes...
Sorry to have posted all the DirectX Portable stuff here, but the takeaway here is that video will work in Dev Test 3 but audio won't.
By default Dolphin uses DirectSound so you don't notice. You have to explicitly enable XAudio2 then run a game.
It will popup a few messages about the audio fail, then play with no sound.
Some games have proper audio only with XAudio backend, I'm far away from my home, but as soon as I can I'll try the register/unregister with XAudio2. Also, thanks for your contributions in portable DirectX part...
You could use the DirectX Portable + Custom code there, or at least derive some to only register the needed DLL.
But assuming Dolphin and DirectX became official, using the DirectX would be the way to go. That is why my Netbeans Portable now requires OpenJDK by gluxon.
Your downloader code was essential in my making of DirectX Portable, and my updated emulators now use and require it.
So, should I assume that DirectX will become an official portable plugin that is installed in CommonFiles\DirectX (like jPortable) or still use custom download code to download the required files during the install and maintain it in the App folder (like it's done in the current Dev Test 3 from Dolphin)?
Next release will handle the register/unregister of XAudio2 DLL, I played around and worked fine in this way... But don't expect next release before January, I'm in vacation now with just an very weak netbook that doesn't even handle Google Chrome Portable at an optimal performance...
Also, do you have an Development Test release of DirectX Portable available? This way I can already develop Dolphin Portable using it, to allow an easier release when both apps become official (I hope that this occur as soon as possible, at least for DirectX)...
Yes, like jPortable.
I posted a topic Dev Test, but you can get to my SkyDrive from any Dev Test I posted.
That will allow you to scrap the download, but you'll have to make use of the sample code in some way, as it does the registration.
An official release would likely get Platform assistance, like how it sets JAVA_HOME for you to use in the launcher for Java.
When you update from 3.0 to 3.5, the language may get messed. It's recommended also to delete all content from "Data" folder (except the GC and Wii folder, to maintain your saved games)...
Starting with 3.5 Dev Test 2, DirectX End-User Runtimes Portable are required by default. Please report me any issue you may have, including the steps to reproduce the problem, your OS version and Architecture (32 or 64 bits) and which variants of Dolphin Portable you installed (x86 only, both, etc.). Also, tell me if you already had a local copy of the DirectX Runtimes installed...
This seems to run fine except one run my wii saves were lost, luckily i backed them up as i was testing. runs just as well as the original except that one time.
I noticed when the emulator is running the files in Data folder are temporarily moved to Apps/Dolphin and moved back when closed even when 64 build is run. Then, moved back on close,My question is what happens when to data is a crash.
Also would it be too much trouble to make a 3.0 build with this as well. "TimeSplitters: Future Perfect" (A Gamecube Game) hangs on me on 3.5. no fault of portable, happens on regular builds. 3.0 doesn't require the 2010 distribs but still needs directx. i would like to be able to play that game anywhere and not all have needed directx versions.
I love the portable by the way. Will continue testing.
Proud user of Firefox
Ran 52 games and 5 complete playthroughs. only 2 crashes and one session of that lost my wii saves.
Proud user of Firefox
Thank you for the testing reports. I'm a bit busy at the moment, but I'll push an updated version soon...
About the crash, it's probably related to Dolphin itself, and not the portable launcher. The folders are guaranteed to move correctly even when Dolphin crashes because the moving/backing up operations are handled by the launcher, so, unless you manually kill DolphinEmulatorPortable.exe while running the emulator, the folders should be moved/backed up without issues. I'll add an additional check to ensure that Wii saves don't get lost (something went wrong with the Wii folder)
Regarding Dolphin 3.0, this launcher should be compatible with any Dolphin revision, so you need only to unpack Dolphin 3.0 in the App\Dolphin (or App\Dolphin64 for the x64 build) and make a copy of the content from User folder to App\DefaultData and Data...
Furthermore, any recent revision released post Dolphin 3.0 (including Dolphin 3.0 too) needs the Visual C++ 2010 redistributables, portable version won't run without the copy included unless your computer have a local copy installed...
Thanks for info
Proud user of Firefox
Dolphin 4.0.1 Release Announcement
Written by neobrain on Oct. 21, 2013
Jhonn = Please update the portable version to 4.0.1.
I'm doing some changes in the launcher and trying to finish the language switching code, so, it may take a while... Until it's updated, you can unpack the 4.0.1 inside App\Dolphin (or App\Dolphin64) and it'll work just fine (make sure to not delete the file portable.txt)...
Windows 7 x64, Ultimate Fr. Sp1.
Portable "V3.x and V4.0 Development Test 1", always open x86 dolphin.
I try your portable version, but found that the x86 version of dolphin is always opened instead of the x64 version of dolphin.
i look at "DolphinEmulatorPortable | App" section.
AppInfo
DefaultData
Dolphin
Dolphin64
ROMs
Readme.txt
Please verify at your side.
Have you selected the optional x64 version when installing? It should work, but I'll take a look...
In fact, I introduced this issue in 4.0 dev test 1 without noticing it... As a workaround, go to DolphinEmulatorPortable\App\AppInfo\Launcher, delete "DolphinEmulatorPortable.ini" and rename "DolphinEmulatorPortable64.ini" to "DolphinEmulatorPortable.ini". I'll fix it in the next release...
EDIT: fixed in 4.0.2 Dev Test 2
Okay The problem with my freezes is disc access speed. also happens with non-portable dolphin on a removable harddrive. I hear my hard drive spinning whenever it freezes and sometimes doesn't unfreeze when it reads the data sometimes. Works most of the time . guess i should get a USB 3.0 port to completely stop the problem or just use the internal hardrive for ROMs. happens rarely. Thought you should know and test how well it works on various hardware specs
Proud user of Firefox
Many external HDDs stop spinning after some time due power saving, and this occurs even with USB 3.0 drives. Saind that, I'll try to implement a small piece of code to make the launcher prevent the storage device entering sleep state...
EDIT: implemented in 4.0.2 Dev Test 2
Thanks. Sorry for the extremely late reply, but had no issue with freezes since then. I had a lot of unexpected things keeping me extremely busy.
Proud user of Firefox
It took long, but here we go. The 4.0.2 Dev Test 2 introduced a big set of changes, so, please, test this release a looot
so far so good, all ROMs play like the non-portable and data is saved and kept. Sorry I haven't been around due to work.
Proud user of Firefox
Well, I have plans in getting Dolphin Emu Portable to be an official portable app some day (still having some blocks, like depending of DX portable which isn't official too). However, something may completely break the requisites of being an official app: Dolphin is going to be 64-bit only...
According to current PAF specification, portable apps should be 32-bit and should bundle 64-bit edition too only if necessary(e.g. provides speedup, required because the 32-bit variation won't work on 64-bit, etc.)
Seen that Dolphin is gonna be 64-bit only, it's violating PAF specification and then can't be official some day... I would like to hear this from someone like John, after all I plan coding the remaining launcher features around the same time next stable release of Dolphin is released, which will of course be 64-bit only.
What I'm trying to say is, now that Dolphin is gonna be 64-bit only, should I still hope it being released as an official portable app someday or this change is a no way to the official road?
I'd wager this will be an issue in the future overall but not for a little while. With Dolphin, it makes sense for what this app is from the publisher's perspective to go 64-bit only. For example, by 2012, the majority of gamers on Steam were 64-bit and I'd wager it's a very large majority today. It doesn't quite work with where we are in terms of portable apps and our overall userbase, though.
Overall, we're still dealing with lots of Windows XP users, virtually all of which are 32-bit. Vista was about 90% 32-bit in terms of installs. Windows 7 was the tipping point for 64-bit, though. By mid-2010, it was about 50-50 (source). These days, most systems ship as 64-bit. Still, that leaves quite a lot of 32-bit machines out there, some of which our users will encounter at university, a hotel, a net cafe, etc.
But that doesn't mean leaving an app like Dolphin out. What we can do is setup a service similar to how we'll do .NET apps, allowing users to choose whether or not such apps will be shown in their app directory and turning them off by default for new users (since the apps won't work on all PCs). I'm finishing up the .NET stuff in the next month, so we can add it in after that.
Sometimes, the impossible can become possible, if you're awesome!
I know it is more work for you, but what about an option in the Platform to hide and/or alter the appearance of an app that doesn't support the current system eg. 64-bit app on a 32-bit system, required .NET version(s) not found, Java apps when JRE can't be found etc?
That's already planned and a part of the .NET release. Apps that won't run on the current system (.NET version not available or 64-bit on 32-bit) will be greyed out or crossed out and show a message when selected.
It's unnecessary for Java apps as we'll just prompt to download jPortable. Java apps will be a part of the directory proper and shown by default since they'll run on every PC. Users can optionally hide them like they can with non open source apps if they choose. Java apps that don't work with jPortable won't be permitted.
Sometimes, the impossible can become possible, if you're awesome!
Sorry If my question is not straightforward, I'm new to the forums. So I've been using this emulator for quite a long time now, and the portable version seems to run just as good as the original except it wont save anything... Controller setups, game data, emulation settings, etc. Just now, I found that when the emulator is closed it is deleting (or moving...?) the game data for whatever I just played. The next time I open it, it behaves just like when first launching Dolphin. Could someone help me understand why it is doing this or what I did to it?
The current launcher version already handles that case, if it's not working I suggest completely removing Dolphin Emulator Portable then reinstalling it. Also, Double check you have a file named portable.txt inside Data folder...
Why don't you list the dlls needed for Dolphin without DirectX download.
There's already a launcher version not dependant of DirectX Portable available in the OP. If you want to get the list of included DLLs, just unpack the installer with WinRAR or 7-Zip and look the contents of DXInstaller folders...
Thank you, I needed a portable version that I did not have to configure every time I formatted the PC or used another, because I use it on a Pen Drive!