In each instance I can correctly default autoconfig the controller in the correct index and just set it up. Only loading through rocketlauncher and possibly based on paths. I was thinking of running 3 instances of retroarch. Its annoying but I understand Im trying to use it in a way its not designed to be used so instead I have a kind of solution but dont know if I can properly implement it. It also drops keys so on one controller I needed to map a “z trigger” to a core and it seemed to be attached to the Y button but the Y button disappeard, again no problem for controller 2 but the point is it really doesnt like swapping out controllers). This causes all sorts of extremely convoluted mapping options including entire keys disappearing and swapping buttons (I had one system set up correctly and exactly the same for each controller but had to swap “A” and “B” around on only one controller, the other worked fine. When I plug in a controller I want to use just before I “Enter” that system, RA has a bit of a meltdown and reassigns itself to the orginal config in index 0 or 1, yet still tries to use some of your original mapping for another controller that was previously sat there. I have 6 controllers (3 different types). Where Retroarch seems to fall down is index mapping. This is absolutely fine and can take a bit to get used to but works solid and is very easy to set up when you get the hand of it and when you are only using one controller across the entire board, like the xin mo, or an xbox controller. It is more ideally suited for an xbox controller that gets either set up manually or autoconfigs and then you just map each core if you want to make any changes. Its far too convoluted a control method to use multiple controllers. Retroarch will not map a controller to a core. The 8bitdo will be blu tooth and will not always be connected, only switched on for certain systems. The N64 Generic USB will be only plugged in when wanting to use the N64 “wheel” and unplugged immediatly upon retuning to hyperspin. The Xin Mo is plugged in permanantly and will not be removed as its part of the arcade machine. I belive this might be why RA does this.Ĭontrollers will not always be plugged in. USB is a bit tricky though and windows does like to reassign things differently. Retroarch does not distinguish between Port (Device index) and controller. Xin mo can cover certain systems like Mame and NES, N64 can cover N64 only and 8bitDo for things that require analog sticks and triggers etc. (2x Controllers each time (Player 1, player 2)Ī) My arcade machine (A Xin Mo controller that see two controllers) It seems I cant create an ideal scenario for my arcade setup using Hyperspin as a front end, Rocketlauncher as a back end and some systems using Retroarch so I need to think a little outside the box.Ĭurrently I want to use 3 methods of controller. Think it was around 120 games working last I checked.ĭreamcast I have gdi converted to CHD and some obscure games are in the cdi format.Hi. Naomi only works with the non-merged rom sets or bin files. These launch directly now, in the past we had to make "lst" files. I've added all 3 to a custom retroarch ahk and they all do work.Ītomiswave I have games that were converted to Naomi.bin files. Dreamcast has a beetledc_wince core as well now. I do Atomiswave with the beetledc core, Sega Naomi 1 can use the same core. Looks like he hasn't spelled the core name correctly to me. He should be playing the games in RA first, make sure they work before worrying about Hyperspin. bios, files inside the roms, chd or an outdated core, unsuported games and so on he will get an error for sure. just wanted to help the guy in his process Worked on my side but i only tested 2 games so i have no clue if this core is good or not. I added the line he was testing in the module (Sega Naomi|LibRetro_NAOMI|reicast_libretro) did a run test just to verify and make sure the line was not his problem
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |