Zombeaver

LB already has an "extract rom archives" option you can enable for your emulator entries. It's not going to double-unzip stuff though. I'm not sure if anything could/would do that. I would suggest just extracting the first layer permanently.

What method are you using to do this currently? An "additional app"? There might be a way to create a bat to launch Vjoy and then launch your emulator, I'm not sure. What are you using Vjoy for exactly and in combination with what emulator? I wouldn't think you'd need Vjoy if you're using Retroarch.

Well Flashback is one of my favorite games of all time and I can tell you it sounds nothing like this normally. I don't know that I necessarily think it sounds better but it's most definitely noticeably different. EDIT: And Secret of Mana: I cringed several times watching this. Can't say I'm a fan of the changes to this one. I really like the normal soundtrack though so maybe it's just bias, I dunno.

That seems to be the main focus, yeah. "CD quality soundtracks" that are patched in.

According to the Libretro forums you can use MSU-1 games with BSNES you just have to "load the manifest.bml instead of the ROM itself". I have no experience with MSU games myself, full disclosure. I'm kinda curious now though. http://libretro.com/forums/showthread.php?t=5600 http://libretro.com/forums/showthread.php?t=2669 What happens if you just paste "E:\Downloaded Games\Emulation\Roms\Super Nintendo\Super Famicom\megaman7_msu1.sfc" in the "use command line-parameters" section in LB?

Why would you want to do that? .cdi is already supported by Demul. Make sure you're using the "GD-ROM plugin: gdrImage" in Demul. It's in Config -> Plugins and Paths.

It's been a while but if memory serves all I did was mount the image on a virtual drive via Daemon Tools and then direct DiscJuggler to that drive and told it to rip it to .cdi format. There are some special settings that you have to enable if you want to actually burn a Dreamcast game to physical CD (like Overburn) but I don't think they're needed to just create the .cdi image file.

I'm using a mix of those formats as well with Demul, both working fine. You can also use DiscJuggler to convert to .cdi from unsupported formats like .nrg.

I have two emulator entries for FS-UAE in LB - one is just regular old "FS-UAE" that's using the normal Launcher.exe from FS-UAE and the other is "FS-UAE UUID" which uses Eirulan's launcher. The reason the two have to be separate is because the "no quotes" and "no file extension" check boxes that are used for FS-UAE UUIDs makes it mutually exclusive from use with launching config files. If you want to launch your own config, you need to use FS-UAE and if you want to launch a UUID file, you need to use FS-UAE UUID. You probably could use Eirulan's launcher with your non-UUID emulator entry but you don't need to - launching via your own config files does not create the problem that his launcher fixes. Launching via a custom config updates the config_name field in the settings.ini so your saves will work normally as-is.

I figured out how to fix the handful of games that have the "half color" bug. In WinUAE I just set up their configs with custom brightness settings but I couldn't figure out how to do this in FS-UAE. It turns out though that Frode actually made a shader for this specific issue called atari-color-fix.shader that fixes them. Evidently this is a problem that affected some Atari ST to Amiga conversions, thus the "atari-color-fix" name. According to the FS-UAE forum this shader is supposed to come with FS-UAE but mine did not; I'm not sure if it's because it's the portable version or if it was just removed in later releases. I was able to find it on github, however, and just created the file myself. I've attached it below. This just needs to go in your base FS-UAE folder and then you create a custom config for the game you want to use it on and in the Additional Configuration -> Custom Configuration section just add in shader = atari-color-fix.shader save your config and you're good to go. atari-color-fix.shader Turning this (which is using the built-in config): Into this (using a custom config): I also figured out how to fix Hostages so you don't just get murdered immediately, even when you don't get caught in the spotlight. The game runs at the wrong speed with the built-in config which uses A1200 and the graphics are basically out of sync from the internal speed (which makes the game impossible). The model just needs to be changed to A500+. In WinUAE you had to enable "cycle exact" in the settings. With these fixes I'm no longer using WinUAE for any of my games so huzzah for that. I'll try to get that video out this weekend.

What does it show up as in Windows in your controller list? Does it have Xinput support? If it does, it should basically "just work" with most things. Which gamepad is it - the F710? https://www.amazon.com/Logitech-940-000117-Gamepad-F710/dp/B0041RR0TW

Something to keep in mind about Mednafen is that it's particularly picky about what you use with it - in the case of Saturn you could have bad rips or just rips that need to be fixed via CD Mage. You could also be using rips that are PAL region which are currently unsupported by the Retroarch core (and standalone Mednafen up until a couple days ago). You could also have bad .cue sheets - you need to open them up in Notepad and make sure they're not directed to the wrong file/directory. The first line should say something like FILE "yourromfilename.BIN" BIN not FILE "L:\subfolder\that\doesn't\even\exist\on\your\computer\wrongfilename.BIN" BIN This same thing applies for PSX .cues. If you've got valid .cue sheets, your bios files are good and named correctly and in the system folder in RA, and your rips are okay you should be good. My suggestion would be to start with getting PSX to work before moving to Saturn and my first suggestion for that would be to not use the "mednafen_psx_hw_libretro" core and use the normal Mednafen PSX one instead. I believe it's just "mednafen_psx_libretro". The HW one has upscaling but it's still somewhat preliminary/experimental - start with the normal one. You may also want to just try stuff out in RA by itself for the time being - once it's working then we can worry about getting it integrated into LB.

I've said this many, many times before but it bears repeating: Jason is the nicest dev you'll ever talk to. The fact that you can talk to him at all puts him a good deal above most from the very get go. He also works his ass off, by himself no less, to bring the community new features, bug fixes, and discuss development; and he does this on a daily basis for everyone here. And perhaps most importantly - he actually listens to the community. That's what you're buying into when they buy a license - not just an extremely cool piece of software. If you're having some kind of trouble getting a license because of some kind of financial difficulty, or just getting the short end of exchange rates, please please just talk to Jason about it before doing this kind of shady back-alley crap. He'll listen to you and help you get it figured out, I promise. Just send him a private message on here.

Wow... somebody's got some splainin' to do.

It makes perfect sense to me. Quake is one of my favorite games of all time, but if it's literally anything but regular-old chunky-ass software mode Quake I can't stand it - that's what I know, remember, and grew up with and anything else is just wrong. So believe me, that sort of thing is preaching to the choir for me. It's just that I have no childhood nostalgic connection to Amiga (I was a C64 kid) so for me it's just a matter of what runs smoothest/fastest and works. For my purposes I just prefer WHDLoad. There are some C64 games, on the other hand, that if I didn't see the cracktros by Ikari or Remember on some games I wouldn't know what to do with myself Thank you! No rush! It works as is - this is just extra QOL! Speaking of which, if it's at all possible - adding in "remembered" locations for the launcher.sqlite and the chosen export folder would be a nice touch too Awesome! I can't wait! I've got about 50 ScummVM games in my library but it is quite a pain in the butt to add each one. I have no experience with PCem so I'm curious about that one as well. I used VirtualBox with a W98 environment years ago - I imagine it's somewhat similar to that.

I don't disagree with this assessment at all - it's just that in the other thread one of the (likely) perpetrators had the audacity to ask for tech support Spending inordinate amounts of time and energy to combat this kind of thing is a lost cause, for sure. Just don't go to the very people you're scamming and ask them to help you set things up.

I see the problem with Mercenary now - it's not in the OAGD so it doesn't have a built-in config in FS-UAE. In those cases they need to be created manually. I just tested it out and my default settings (A1200 / 8MB Fast RAM / Empty Floppy Drive Volume: 0) seem to work just fine for Mercenary. I just added the zip to the hard drive section, added PRELOAD to the WHDLoad Arguments section (so it reads Mercenary.slave PRELOAD), and named/saved the config as Mercenary. It boots up fine. I have no idea what I'm doing in game though haha.

Oh? I haven't tried the first one but I know Damocles (Mercenary 2) works in WHDLoad format. I'll check out the first one tonight.

Yeah I assumed as much since ipf is part of the preservation project - C64 games in the PP are the same way. The video will be based on using WHDLoad games. The same basic principles apply to ADF versions though - the export/import process is the same, you'd just be directing LB to a different UUID if you wanted to use the ADF version. You could actually add different versions in as additional-apps in LB if you wanted to. I'll also go over creating/using .fs-uae configuration files for the games that aren't in the Open Amiga Games Database/don't have built-in configs. I've actually encountered a handful of games where the built-in config either didn't work (crashed) or didn't work very well (were abnormally slow loading). They all seem to be instances where they use the A600 for whatever reason. So setting up your own config is useful for those situations as well.

Oh? I must have missed that. I'll test it again tonight. I've just been using the "without variant name" option because I didn't think it'd been fixed yet.

No problem! I'm gonna go over all this for people when I do that tutorial video. The only thing really left to address is the LB importer bug with "use folder names" and folders that have a period in them (like "v1.2" or something; of which there are many unless you use the "Folder name without variants name" option in Eirulan's exporter). Even with the bug it's not a huge deal - you could always just delete the erroneous portion of the title on the final screen of the import, but I could see that being an issue if you're importing hundreds of games at a time. For the time being, "Folder name without variants name" is probably the easiest solution - you just have to make sure you're using the correct UUID for the version that you actually want to use (the exporter currently just chooses the first one from the list in FS-UAE to export). If it's the wrong one, you can open up the appropriate Open Amiga Games Database page by clicking on the little pencil icon in FS-UAE and then copy the UUID from there and rename your UUID file accordingly.

Go to Settings in FS-UAE and then go to the "Joysticks & Gamepads" section. Double-click on your controller. You should then see a map of all of the key names. Whatever you want to use as the button will need to be added into the "Advanced Settings" section in FS-UAE. For mine it's something like Xinput_Controller_Button_POV_5 (I can't recall from memory, sorry) and then a space, equals sign, space, action_key_f10 So something like: Xinput_Controller_Button_12 = action_key_f10 Another useful one to bind is "action_warp". This is the "fast forward" function

No problem! Yeah I was having the same issue with Perihelion so I did some reading and discovered that they're only permanently saved when the actual QuitKey is used. That doesn't bother me in and of itself but having half a dozen different keys used from one game to the next is what made it really annoying - with that prefs file you can just specify it once and it'll carry over to everything. I haven't tested it yet (not home at the moment) but you could probably change it to the Esc key in the prefs (which should be QuitKey=$45) and then the Controller Automation quit function in LB/BB should send the QuitKey command. The only reason I didn't do that is I feel like there are probably a few games here and there that actually use an Esc input in-game.

Hey, I just figured out something neat. If you add in a file into the base directory of FS-UAE named WHDLoad.prefs you can add in global parameters that will affect any WHDLoad game you load - in my case I'm using this to override the QuitKey (the little starting screen when you launch a WHDLoad file will show you what it is for that game - it'll say something like "Press F10 to quit"). Why does the QuitKey matter when you can just press start/F12 and then press the X button to close the emulator? Because for WHDLoad games, save data (as in, normal in-game saves) is only stored temporarily in RAM until you exit the game via the QuitKey (at which point it's saved permanently). The problem is that different games use different QuitKeys - F10 is the most common but I've also seen Home, *, /, and Delete as well; presumably there are others too. If you add in a WHDLoad.prefs file to your FS-UAE folder, you can specify a QuitKey which will override it to be whatever you specify for everything. The "High Key" table that I found here seems to correctly correspond to the appropriate keys. In my case, I wanted it to be F10 so the prefs file has "QuitKey=$59". 59 would be changed to something else from that table if you wanted a different key. I've got an "advanced setting" in FS-UAE to have the right thumb-stick button send an F10 input (action_key_f10) so now that will work for every game. I attached the prefs file I'm using. It has a number of parameters that can be adjusted but all of them except for "QuitKey" are commented out on the attached. WHDLoad.prefs

Well that was true prior to 2.8, and as far as I can tell 2.8 was only released very recently. There isn't a date on the download page and there's no blog post/changelog for 2.8 on the site and there's no mention of it in the development thread on the support.FS-UAE board. 2.6.2 was the latest stable up until like a week ago (maybe less) as far as I can tell. I'm not sure when UUID launch support was added but I think it was WHDLoad zip support that was the main thing that wasn't supported at the time.