Bedwyr
-
Posts
444 -
Joined
-
Last visited
Content Type
Profiles
Forums
Articles
Downloads
Gallery
Blogs
Everything posted by Bedwyr
-
This did not happen on a previous 1.4.1 setup. I have savestate set to hotkey activation such that on my XB1 controller, holding down the right stick activates hotkeys and d-pad down saves state. With a game loaded on mupen64plus core only, this crashes Retroarch immediately. Changing savestate slot and loading do not do this. I have tried experimenting with the keyboard commands and get the same behavior. I'll try backing up one more copy of the 1.4.1 directory contents to see if this repeats (a previous 1.4.1 install had different issues). Any known issues?
-
It was a good try, but it seems like they're still tied together somehow. I saved separate and renamed copies of both the dll and info files. I set Launchbox to load the separate dll file with no luck. A shader override would simply continue to apply to both. Moreover I was unable to undo the shader setting whether I edited and saved by loading content or launching through Launchbox and editing the shader setting from there. The shader setting stuck and I had to delete the folder contents and start over. For separate shader settings it seems best to probably use a different core entirely.
-
Which folder is that located in?
-
Ok ok ok. One more question. Given the new setup for core overrides, it seems impossible that I could run a green gameboy shader for GB games and a separate shader for GBC as they both use the same core (gambatte). I tried copying the dll file of the core and renaming it, but Retroarch is smart and still reads it as Gambatte. I'm not too fussed, but if anyone has any suggestions or workarounds, I'm game.
-
And done and settled. I see Rogue Squadron and Pilotwings are still problematical on Mupen64. We strive I suppose.
-
See above edit. It's just returning ambiguous control readback that I misinterpreted.
- 64 replies
-
- 1
-
-
- retroarch
- controller
- (and 1 more)
-
Hmm. Maaaybe ran into a bug? I normally set savestate controls like this in the retroarch config "hotkey input" controls: - Hotkey activator: click right analog (9) - Savestate +: right d-pad - Savestate -: left d-pad - Load savestate: up d-pad - Save savestate: down d-pad Left and right change current savestate, but up and down only save and load to and from slot 0. Oddly I see feedback when saving that the game saves and then loads slot 0. Am I missing something? Nope. It's working correctly. It's just that the Retroarch text feedback is telling me the key I'm pressing which is #0 (the "hat" set of d-pad controls) rather than which slot it's saving to. Kind of ambiguous feedback if you ask me. After further testing, the behavior is actually correct.
-
Ah. I see what they're doing now. It's certainly simpler than carting around a bunch of individual cfg files. Yeah, I got the overrides working fine as well as the analog. Once you get the hang of it, this is actually more reliable. Thanks! ps- What's the status on the Vulkan N64 and Dolphin cores? Still off in the future? I've been out of the loop.
-
Ok, just getting Retroarch 1.4.1 configured. I have a few custom setups for controls, all with the usual xInput controller (XB1). Some changes I've noticed: - Control input changes now apply to the Retroarch UI. Has this always been the case? For instance when configuring NES control, I prefer to have left button (x) be NES B and down (A) be NES A. This makes it more comfortable as the right thumb rests on the inside buttons. This also appears to be changing the "confirm" and "cancel" buttons in the UI as well to X as confirm and A as cancel. I don't recall this happening in 1.3.6. - I can't seem to double up controls. I have NES directional control mapped to the d-pad, but I would also like the left analog stick mapped to NES directional control. This gives the player (my guests) the choice of using either the joystick or d-pad. It worked fine in 1.3.6 but I can't seem to figure out how to do this in the new version.
-
No objection per se. Wouldn't it be reasonable, though, to associate the no-intro sets into the search algorithm and pre-associate as an initial heuristic? I don't think that would increase search time much and it would sort of work as a "dictionary attack" to start the algorithm with as you say, as a baseline.
-
Whoops.
-
So per another thread I was trying to import Super Mario Advance 1. Did so successfully, but tested a few GBA games and noticed that the audio has now decided to lag. I've had the system working fine before, so I'm not exactly sure what changed. Right now I'm using VBA Next with some custom control changes. I experimented with audio delay, pushing it to 96ms and then back with little help. I tried doing a default VBA M config and have the games running super slow. Does anyone have a good PC core and config setup they can lend me? I'd like to try a known baseline and see if that works best before spending lots of time trying to troubleshoot. edit: Just FYI my home setup is hefty PC build using a haswell i5, 1060 GTX, and 16MGB of ram. This should not be a performance limited problem.
-
Yeah that did it. Perhaps this should be considered vis a vis the scraper algorithm. While understandable that the algorithm probably got hung up on which SM advance game it was, IMO the algorithm should always at least process the official no-intro title correctly. I know it's just a minor inconvenience, but the no-intro convention is so common that it seems an algorithm ought to always catch these cases.
-
What do you think I should try? edit: The database link is http://gamesdb.launchbox-app.com/games/details/2225 During the import process, should I manually edit the name to something like this? The rom name is: "Super Mario Advance (USA, Europe).gba". The importer parses the name as: Name File Extension Disc Super Mario Advance D:\Games\Emulators\GBA\Roms\Super Mario Advance (USA, Europe).gba .gba
-
Weird. I pulled it straight from a brand new no-intro archive.
-
I think I have had issues with this title before. Super Mario Advance refuses to be imported into the library. The sequels import and operate fine but this one seems to stubbornly resist both Launchbox and the scraper. Is this known?
-
Thanks!
-
So if the no-intro roms are stripped of their headers is there a way to patch that back in?
-
I'm reluctant to hook up my ibuffalo controller to run Retroarch SNES games. Everything works well right now with both the Xbox One and 360 controllers. What is the process by which I make Retroarch understand two different controller assignments automatically depending on which controller I have plugged in? Or is there not one? Thanks
-
It seems to have worked. One question though. If I have a no-intro japanese rom, it appears that most of the full translation IPSs do not patch properly with these versions*. What rom is expected from most of the "famous" translations on romhacking.net? Or at least is there a way to process a no-intro rom that will be accepted by the ips patch and run correctly? I preserved the translations I already have, so I'm good there. But now I'm curious. How does someone new to the scene do with, say, a full cart dump from a Super Famicom cart and get a successful translation patch? *testing in retroarch in Windows right now, snes9x_next core
-
I see. So it's possible that in my hodge podge I have some units that will not match no-intro checksums and that this is most likely the culprit? edit: I'll be taking care of some errands right now. This is helping me trace the root problem. Maybe when the RetroPie responders are talking about "headers" these no-intro sources are what they are talking about?
-
As I said, my collection is a hodge podge. What is no-intro and its purpose and how would I know? I've seen it mentioned a fair bit on the Hyperspin forums, but remain confused about them. Re: transferring. I copied over everything in my windows roms folders and then did a selective cp on a linux command line: *.smc *.sfc to the appropriate folder.
-
No problem. I bit my tongue long enough to keep a little flareup from happening. Pax it is and thanks for helping. None are zipped. I've been trying to find repeatable patterns (and did search the retropie forums). One thing I see responders suggesting is "header" problems. Maybe the ARM/Retropie cores are much stricter about processing ROM dumps. I have no idea what's valid or not valid as I've sourced these over time (no further details). I have both smc and sfc files and there are instances of both working and not working, so no pattern there. I have several old language hacks and *all* work (FFV, DQ I.II, DQ III, etc) oddly enough. If a strict checksum were needed I wouldn't think these would load. Wing Commander and Wing Commander Secret Missions bugs me. Why would the former work and the latter not? Lagoon used to be a reliable rom. It has run on every core I've tried on Windows, no problem where some that run on RetroPie have had issues (usually with Bsnes flavors). I've tried a sequence of 2002, 2005, 2010, and plain vanilla Snes9x on about half of these, but didn't have the patience to do a full permutation yet. The pattern described above is holding.
-
Well, sir? A few things. First: I'm not currently a member on their forums and would just as soon not join if I can discover an answer for a one-off problem. I may have to, but I thought I would try here first. Second: There's a critical mass of knowledge here that I thought on an offhand chance someone else has used the same hardware (or at least some kind of ARM architecture) and might be interested in helping out. Third: This is off-topic emulation. I see no particular restriction that it be related to x86 architecture or that Launchbox be able to run on top of a particular emulator.