Zombeaver

It's fine. It's just that whenever the specific question of "What should I be doing with all these?" in relation to C64 disk importing comes up I always try to stress that all people need to be importing for C64 disks is the first disk/side. Anything else is going to be done in-emulator during play after that. And unlike say the PSX, if you try to start a game with anything other than that, most of them aren't going to work because they're designed to be loaded in a specific order. Some way to streamline this for the importing process would be nice but until then probably the easiest thing is just going through the final screen of the import wizard and just removing disks that aren't 1/A. Luckily the C64 doesn't have a huge number of multi-disk games. Not like the Amiga or something.

What does save states/save state loading have to do with having other C64 disks in additional apps? If you save/load a save state it's going to load the associated disk data (that was in use at the time) anyway. In which case the disk inserted at launch is completely irrelevant. This is true for both CCS64 and Hoxs64; and in both cases you can have literally nothing inserted at the time, load the save state file, and it'll continue right on where you left off (regardless of what disk/side that may be) because that data is getting dumped into the save state. In both cases you can even set the save state file as the "rom" in LB and direct it at the emulator and it'll start right from the save state. People are welcome to add them in if the wish, but my point is that it's a somewhat time-consuming endeavor for no practical purpose or benefit. If you're starting the game "properly" you're going to do it with Disk 1 / Side A. If you're using a save state, the disk at launch doesn't matter.

Wii should be easy. Gameboy I started on previously but because it has a kindof weird native aspect ratio it complicated things. It's definitely still doable, it'll just take a bit longer to get sorted. Wii U will take longer since it doesn't appear to have a system intro available from Emumovies currently so the clips would have to be assembled manually.

In most cases for C64, having additional sides/disks in the additional apps section is unnecessary because you're rarely ever going to start the game with anything other than Disk 1 / Side A. It's not like a Playstation game where you can throw in whatever disc you want and it'll take you to a main menu where you can load a save file. Saves, in and of themselves, are fairly rare for C64 games. Generally speaking if you're dealing with multi-disk/side games you're just going to want to import Disk 1 / Side A into your library and switch to others as prompted in-emulator.

Use Controller Automation. It has to be configured in both Launchbox and Big Box. In Launchbox it's in Tools -> Options -> Input -> Gamepad/Joystick -> Automation. You need to enable automation and then indicate a key to "hold" and then another button to combine with it for different functions. In your case "Close the active window": In Big Box, it's in Options -> Controller Automation. Same idea as before. There are a few instances where the controller automation close feature doesn't work, but PPSSPP and Dolphin both work fine with it.

Okay, I finally got this sorted out - for some reason I had to unplug everything and set the controls to default and then configure them and save the autoconfigs and they're working normally/independently/automatically now. Hurray! Typical RA weirdness I guess...

I'm thinking the hitching I'm getting (it's happening while scrolling through the game boxes) has something to do with description scrolling - the games that don't have scrolling descriptions are smooth to switch to and the ones that do aren't. This went away when I updated to 7.6 but seems to have reappeared.

Ah okay, gotcha. Demul testing results: Of 5 launches, 4 stopped the background music when starting but did not resume when quitting and in 1 case the music didn't stop after starting the game. Controls are still good. CCS64 is still working correctly. Did anything change with scrolling in the beta? I'm getting the hitching while scrolling through games that had disappeared in 7.6.

What do you mean by "multiple ROMs per game"? How is this different from adding another rom in additional apps and selecting "use emulator"? I'm downloading now. I'll test out Demul and report back.

Equally weird is that in the autoconfig folder in Retroarch there are two .cfgs - "USB Gamepad.cfg" and "Xinput Controller (User 1).cfg" and they do indeed have different bindings listed. But it's not actually overwriting them in Retroarch...

I tried with Remap Binds Enable set to on and it didn't make any difference. It recognizes different devices in the index and it says it loads one or the other depending on what's plugged in, but the controls themselves aren't actually changing at all - it's just whatever I made them last.

AutoConfig doesn't seem to be doing anything... It says it saves it and it says it loads one or the other when I switch from one controller to the other and start a game but the controls themselves aren't changing at all. "AutoConfig Enable" is set to on. "Remap Binds Enable" is set to off though. Maybe that's the problem?

Woot!

Thanks! I always thought it looked neat on the GBC (though I never had a GBC period - transparent or otherwise). I just had a plain old gray OG Game Boy, so maybe that's why. For N64 I had the normal black.

While that's technically true, a wireless 360 controller is my daily driver for most things and I never have any issue with input lag out of it. Hell, I use a wireless 360 controller to play via streaming on my Steam Link over WIFI and I still don't have any problems with it. I've beaten Contra III more than once in that scenario. That doesn't mean you're wrong, I'm just saying I think that point (which is made pretty frequently when the topic comes up) is a little overstated.

I hear ya like some ghosts with yer goblins! No ghouls though. Those are right out. Normal: Scanlines: Normal - Version 2: Scanlines - Version 2:

No problem! I don't even have GBC in my own library so I might as well make something that people who do will actually like. And hey, more options are always good.

Here's an alternate. I don't think it looks any better or worse honestly but it's using an opaque model rather than the transparent one.

It's at the the wrong angle. All of them are upwards and back towards the right. That would look way more out of place than this one does.

It's not from Chrono Trigger (which isn't on the GBC to begin with)... it's Dragon Warrior III. The GBC is at a somewhat less steep angle than some of them. The device itself doesn't have the same amount of physical depth as a console though so that's kindof unavoidable. The original Game Boy one is the same way...

Technically this is from the Super Famicom cover but it was used in promotional materials for the Game Boy Color version so I'm gonna let it slide

I was having a blast last night playing some Contra III and F-Zero with it. I'd kindof forgotten how small (comparatively) the SNES pad was. It didn't take too long to pick back up though. It's funny how different things feel just with a different control peripheral. A couple buddies of mine have a local retro game shop and they had one for sale for $15 so I figured what the hell. I wish it was wireless but it's not a huge deal.

Interesting! I've never used that before. Previously the only controllers I've had connected are my 360 controller and my Mayflash F300 which is also Xinput so the buttons are 1-to-1 between them. It appears that "Save Autoconfig" is already part of 1.3.6 stable. I'll give this a go tonight. Thanks!

So I bought one of these yesterday and have been having fun with it. The only problem is that the default mapping for the buttons isn't synonymous with the equivalent 360 buttons - so I have to remap them if I want to switch from one to the other. I remembered this post and wondered if this is something that's resolved in the nightlies. With 1.3.6 stable in the input section it recognizes that they're not the same controller if I switch from one to the other (the 360 controller says something like "360 Controller" and the SNES controller just says "USB Controller") but it doesn't actually differentiate/change the controls based on which one I have plugged in at the time. They just stay as whatever I map them to regardless of the controller plugged in. Re-reading your post, I'm not entirely clear on this - does it now remember the controls independently based on the connected controller? That's awesome if so. If not, I'm wondering what the best method would be to address this. Having to remap the controls every time I want to switch from one to the other is kindof a pain...