Zombeaver

Here's a new one for 32X. Cosmic Carnage: not-so-great game but a pretty-great cover

You set it to filets? jk jk jk Thanks for the update Jason! The memory function seems to be working great here!

That's not exactly a huge deal. If you run/save/load the game through LB it plays fine. I also use it for the CD version. In the worst case scenario you could always rename previous save files if you'd created them outside of LB.

You're very welcome! Thank you for the kind words. There definitely are some very interesting games worth looking into on the Amiga. I've got a couple projects I'm working on currently but once those are done I've got a few more of these I'd like to do - C64, Atari 8-bit computers and DOSBox are the main ones I'm planning.

None was inflicted. You're as welcome to your opinion as I am to mine. You asked a question and I answered. If the set isn't to your own tastes, that's fine - there are plenty of alternatives here that are exactly what you're looking for. The beauty of LB/BB is that anyone can adjust them to their own tastes and however they see fit; and the more people contribute these kinds of assets, the more options we all have. I have a specific aesthetic that I'm going for and stick with, but there's nothing to say everyone has to (or should) like it as much as I do. Ultimately I made these for myself - I had a specific aesthetic that I wanted for my own collection; but at the same time there's no reason not to share that with the community because others might like it too. I already invested the time and effort into making them - no reason to hoard them

Happy to help!

No command line parameters are actually necessary for using CCS64 via Launchbox. One thing I have encountered though is that if the rom filename contains certain special characters (apostrophes in particular) or are especially long that can cause a problem when trying to launch them through LB, even if they launch normally in CCS64 itself. You may want to try renaming the file and seeing if that helps.

Thanks! I was working on a project to do some platform backgrounds a while back but there didn't seem to be much interest in it. You can find some of them here:

That's not the same thing. Alt+Q is manually enabling warp/uncapping the speed, which you can also do in CCS64 (Alt + F3) but that's not what I'm referring to. The "Maximum 1541 Speed" option in CCS64 enables warp automatically (as in, without you doing/pressing anything) and then disengages when loading is complete. There's no such feature in Hoxs64 to my knowledge.

The font is because I wanted consistency. The reason I made these in the first place was because the ones that were available at the time were kindof a mishmash mess that looked entirely different from one to the next. I'm not using the logos because... 1) There are a ton of them that already do that 2) it's not particularly interesting visually and 3) it's boring as shit. imo

It depends on the theme. Typically they're in one of the platform selection views.

3DO is already in the set. GBC and Wii U are possible eventually, yes.

I just tested it out with Killer Instinct (which uses a .chd) and it seems to be working great!

Well, it's entirely possible it was something I did at the time early on in an attempt to get it working but wasn't actually necessary. I'm not sure. If you don't have to, great. I know for standalone they just have to be in the same folder as the roms; for some reason my recollection was that it worked differently in RA. There's so much stuff in my system folder at this point I'm not sure I could even distinguish which of them, if any, are MAME-related. Do games that use .chds work with the new core? I don't think I ever managed to get those working in RA MAME.

Err is that actually the case for the RA core though? I know it is for standalone MAME but I would swear I've had to put system files for MAME in RA's system folder in order for them to work.

You can use Demul for Atomiswave and Naomi, but I honestly don't have any experience with that. I believe you have to have separate emulator entries between DC and those though because I think they use different command line parameters. @DOS76 can you jump in here? I know you've got experience with this stuff. I've only ever used Demul for DC personally. EDIT: Actually this should be what you're looking for:

I mean it's entirely possible that that's what is happening; my point is why in the world would we want it to function like that? If you don't tell it to replace the fields, it's not actually updating anything it's just downloading/adding stuff that isn't currently filled out in your library entry. The only way to actually update existing fields that already have data in your library (like a description) is by telling it to replace. If you have a description that's a bunch of random gibberish (we had a problem with weird formatting recently that was causing gibberish to appear in descriptions even though they looked normal on the DB page) and it's been fixed DB-side, unless you tell it to replace existing fields it's going to remain gibberish in your library. It seems to me that the entire point should be to query the DB for specific entries that are already assigned in LB and replace the data for that entry, not to perform an entirely new search for DB entries (unless a DB entry isn't assigned to it in your library). I'm not saying you're wrong - I'm saying that it doesn't make much sense if that's how it's functioning currently.

Yep, bios files go in Retroarch's system folder.

It does replace the fields if you tell it to do so but why would it perform an entirely new search for a DB entry? I mean it makes perfect sense to me that you'd want to have the option to replace existing fields (because the DB is going to undergo revisions/corrections over time) but I don't know why you'd want it to perform a completely new DB search, and I'm not sure why one thing would be linked with the other. That seems like it kindof defeats the purpose to me. Now if you don't have it assigned to a DB entry at all, it would make sense in that situation - because maybe there wasn't an entry for it when you first imported the game but it's been added to the DB since then. But if you've already said "Hey Launchbox - this is game X" I don't know why you'd want it to disregard that simply because you want to update your metadata.

Yeah there's definitely something wrong there. Yes, that's the way it should already be functioning. Whenever I've done this in the past, the only time it seemed to actually perform a new search for a title was if it wasn't associated with any specific entry at the time - like in cases where there wasn't an existing DB entry at all and I'd just entered info manually in my library. Everything else has always just pulled updated info from whatever DB entry it was assigned to at the time. @Jason Carr and @Vlansix do you have any thoughts on this? If what cafcmike is reporting is occurring currently, surely that's not intentional right? Why would performing a metadata update do an entirely new search for DB entries if that's already been assigned?

When you say that you've "previously assigned the game" do you mean you've actually reassigned your library entry specifically to LB DB entry #16476 (Dig Dug for Famicom) or that you've simply unassigned it from the Dig Dug II entry that it defaulted to and renamed your library entry to "Dig Dug"? Because those aren't the same thing. If you directly associate it to a specific DB entry it shouldn't be doing a new search, it should be pulling the current metadata for that specific DB entry. If that's not what's happening it has to be a bug, and should be reported on Bitbucket if it hasn't already.

I think it's just one or the other. You can set image type per-platform but I don't think you can do it per-screen (wheel vs details). I don't think this could be addressed through image priorities either since that's basically just assigning "use this type of image if available and, if not, use this other type of image, if that's not available use this other type of image" etc. It might be something that could be specifically implemented into a theme though, I'm not sure. This is a neat idea though. You might want to submit a feature request ticket for it on Bitbucket.

It uses whatever you currently have them assigned to. If they're not currently associated with a DB entry, I believe it searches for them. If you already have them assigned to a specific DB entry though, it's not going to research and change it to something else.

This is entirely dependent on the game and what format you have the expansion in (physical disc, disc image, collection of files, etc.). Typically I do everything in DOSBox beforehand and then simply direct LB to the game after everything's done. In some cases I'm using physical discs and in others I'm using disc images + a virtual drive (DaemonTools). Either of those are functionally identical as far as DOSBox is concerned, you're just directing it to the corresponding drive, whether physical or virtual. In DOSBox you first need to mount the location where you want the game installed and then mount the disc. Mount C "path/to/desired/install/location/" Mount D "path/to/disc/" -t cdrom D: dir /p ["install", "setup", or whatever it's called for that game - it varies from one to another] Follow the prompts to install the game. When asked where to install it, just tell it "C:\" if you've included a folder with the game name in your initial "Mount C" path or "C:\game name\" if not. Here's an example of installing Rayman via disc image in DOSBox: The process for installing expansions is typically the same - you just follow the same steps for it after you've installed the base game first.

The key phrase there being "best open-source Dreamcast emulator". Reicast still isn't on the level of Demul. Demul is closed-source, Windows only, and has somewhat steep hardware requirements, but if you're on Windows and have the necessary hardware, it's the best option.