Some kind of categorization or multi level game browsing is absolutely needed.
Only MAME arcade games are 3000+. they are impossible to browse through a simple scroll list.
Even a simple second level alphabetic initial scroll list would be better than nothing.
For anyone interested in this “auto-load most recent content” solution, until its added oficially, I’ve come up with a very ugly and dirty way of doing it through a .bat file (Windows only)
Save a text file as .bat at retroarch’s root with the following content:
@echo off
for /F "skip=9 delims=" %%a in (content_history.lpl) do set "recentgame=%%a"&goto nextline
:nextline
for /F "skip=11 delims=" %%G in (content_history.lpl) do set "recentcore=%%G"&goto nextline
:nextline
call "retroarch.exe" -L %recentcore:~19,-1% %recentgame:~14,-1%
Executing this should open retroarch loading the first game saved on your content_history.lpl, whatever it might be.
Just throw a shortcut to this on your desktop or add as a non-steam game on Steam if you use Big Picture Mode like me. You can set the shortcut to “open minimized” on properties if the cmd window popping up bothers you. Enable Auto-Load State on config for absolutely no “resume gameplay” downtime. Yes, I know, I’m very lazy.
The latest improvements for multi-disk support are a good start, but I think another step is needed.
One of the issues is that sometimes the disk are not simply numbered. This was especially true of Japanese disk releases where you would have a Main or Game disk and then a number of “Data” disks, and often also a “User disk” which was the save-game disk. This last disk would often not be included, but had to be provided by the user (they did sometimes include a disk label for the user disk). The games would often require the user disk to be inserted at the start of the game and at set times to save progress so you really need this disk.
With some games you could also have one disk in drive A and another disk in drive B (if you had a system with multiple drives), this would save you swapping disks.
The problem is that how can the emulator know this for every single game. And the answer is that it cannot unless we create a per-game config file.
So that is my proposal, create a per-game JSON file which would have a description of the disks and the mount points. Something along the lines of:
{
"type": "object",
"description": "Software",
"properties": {
"schema_version": {
"type": "integer"
},
"System": {
"type": "string"
},
"Program": {
"type": "string",
"default": "Game"
},
"Title": {
"type": "object",
"properties": {
"Title": {
"type": "string"
},
"Language": {
"type": "string"
}
},
"required": [
"Title",
"Language"
]
},
"Media": {
"type": "object",
"properties": {
"Type": {
"type": "string"
},
"sha1": {
"type": "string"
},
"filename": {
"type": "string"
},
"mount": {
"type": "string"
},
"name": {
"type": "string"
}
},
"required": [
"Type"
]
}
},
"required": [
"schema_version",
"System",
"Program",
"Title",
"Media"
]
}
Multiple language titles would be allowed, in case the same media is distributed in multiple countries, but the title on the box is different. For instance, software that asks which language before starting (some software will change language automatically depending on the region of the computer or console, which is another problem not currently solved).
Multiple disks are allowed, and can optionally be given a mount location (e.g. A or B, or in the case of a multi-CD game on the PC, D, E, F, etc). Such that the emulator can assign a disk per drive if the game supports it.
Save game disks are a special case. You cannot have a sha1 checksum for them as they will change each time. Hence the filename. Also, some games require the disk to be formatted, while others may not. A difficulty are games that intentionally save on the game disk themselves, as it causes the sha1 to get invalidated (so the filename is again needed for backup). But unless some kind of overlay is used to save those writes separately, there is not much you can do about that.
Obviously this JSON format could be extended to cover all kinds of other special cases where the emulator needs to know a bit more about the game, such as certain extensions that should be present, or perhaps even suggested extensions in case of optional extensions to enhance the gameplay, in the emulated system. It could also include URL’s to grab metadata.
Suggestion: What about instead of having a core for opening images in fullscreen, you could open screenshots while having other cores running. I take screenshots to save passwords for games and It’s kinda weird how you can’t view them fullscreen with Retroarch without running the imageviewer core and killing the core that you are playing the game on.
Hi, for Disk Control, is it possible to add an option to choose which disk is started when running a m3u file (especially from CLI) ? It will definitively help a lot. Thx.
A couple of things must be fixed until this is “nephew safe”. (Linux, ymmv if you’re using another platform)
2.0: If you enable all user can control the GUI then the PS button won’t go back into the game. (If you are playing something, then the PS/Home button will switch to the GUI, but it won’t go back into the game. You have to manually select “resume” in the quick menu).
2.1: If you enable a key button combination to switch to the GUI, the Home button cease to function. I want to enable a button combination whenever I use a SNES type controller without the home button, but I also want to keep using the autoconfig when using a modern controller that has a Home button. Probably related to 2.0
Fix the DS4v2 going crazy in Linux (DS4v1 works fine). See this thread: Dualshock 4 crazy-fast, repeating controls
Some other things, you can’t hide everything from under the settings tab. Accessibility is one thing. I have to check later what other things can’t be hidden. But this is not a big deal, espescially since I just enable the kiosk mode and therefore hide the whole settings tab. But for myself, this is a little irritating, cause I don’t need to access Accessibility options, ever. But it keeps staring at me 
EDIT: Also “File Browser” can’t be hidden.
note: I know Retroarch is free and you all are underpaid These are not demands, just suggestions:smiley:
Proper Z & C support? Is it even POSSIBLE with x-input?
Obviously, and understandably so, controller mapping was designed with a ‘basic’ modern setup in mind.
For a true ‘full’ setup though, that layout needs Z & C. I finally found a full setup controller, and more are FINALLY being made by companies like RetroBit, but I’m having to do some workarounds to make sure I can map this kind of controller for systems like Sega Saturn and N64 with proper physical placement. (pushing Z with your left index, instead of your right thumb is just… wrong lol same with C-buttons on the right-stick.)
I’d love to see proper support for these neglected buttons, but more so I’m wondering if it’s even possible with x-input. Knowing it was designed around the X360 controller, and the near total lack of this in every controller and game software ever, has made me think; maybe it’s just not possible? Maybe it’s only possible via d-input?
I imagine it’s no small task, and probably nowhere near requested enough, to add such a thing.
More than anything though, I’d just love to hear some input (no pun intended) from people who know how x-input/d-input works on the back-end of it all. My curiosity extends far away from RetroArch on the subject, but I haven’t been able to find this information online at all.
Z & C are just buttons. Calling them L3/R3 or charm and strange doesn’t change what they do. That is, the confusion over Z & C is completely cosmetic.
I do understand that part, I’m sorry… I’m so bad at explaining ‘precisely’ what I mean. It really comes into play most commonly when ‘switching’ between these systems. Not necessarily for mapping ‘to’ a system.
For example, let’s say we start with a fresh setup and map an X360 controller to Sega Saturn. In that setup you have to set Z & C to LB & RB, which also means you have to push L & R to LT & RT.
Now, with that same setup, you switch to N64. C-Up & C-Right (Z&C slots) are still on L1 & R1, and L & R are still on LT & RT… so what do you do for Z (LT and/or RT slots)? There wasn’t a corresponding input on Saturn, so it didn’t come up and now there’s no place for it without throwing the mapping out the window.
The idea of adding Z & C means for Saturn, Z & C are on the right buttons, but so are L&R. Then on N64, The C-buttons (YZ/BC slots) are in the right place, and Z is free to be mapped properly to the LT and/or RT slot.
Assuming someone has the controller with the necessary inputs, this means (with the exception of keypad inputs like on Jaguar, Intellivsion, etc), every single system across the board has absolutely no conflicts -none- for mapping with any other system. Everything gets put in it’s proper physical location, and there’s never ever any need to for a button to be ‘moved around’ to make it work.
I hope that explains what I mean a little better, I know it’s hard to follow because of the way I talk, but I promise the concept I’m trying to convey is sound.
You don’t have to have a single controller mapping across all the systems though. You can map each system/core differently.
I know we don’t “have” to, and I know the current system works beautifully with very little configuration. Z will work as Z whether you map it to R3, Select, or D-Pad Down. The remap system we have is fantastic for that sort of thing, and I don’t want to seem like I don’t appreciate it or the work behind it by any means. That’s not my intention.
All I’m trying to argue here is that there is a great deal of positive value in this concept. Not just in the idea of having one unified controller layout/mapping that covers every console, but also in regards to the experience of all these consoles.
The biggest reason I continue to fall in love with emulation, and the community around it, is the innovation that we see thrown at the dual concepts of both preserving, and enhancing, the original console experience. It’s why so many of us pour their heart, soul, time, and money into all of this. It’s why alphanu adding 15 & 31khz support was such a big deal. It’s why the “Show me what CRT shaders can do” thread has 1,106 posts in it - 72 of which are new just since the last time I looked at it. It’s why the visual accuracy of the new RSP/VI updates to ParaLLEl are so exciting. It’s why run-ahead is such a landmark feature - the examples go on and on and on…
In that same vein, I’m sure there are so many of us who remember how big of a deal it was in the 90’s when Sega dropped the 6-button pad for the Genesis. This was despite the fact it had literally the exact same amount of inputs, that did the exact same thing as the SNES controller. The controls presented a uniquely different experience between the two consoles for no other reason than where those buttons were physically located in your hands.
Again - and I feel the need to continually qualify this because I know I’m being misunderstood - I’m not trying to convince anyone into thinking “Oh, he’s right! Well we better change the whole layout system in retroarch now.”.
If I’m trying to convince anyone of anything, it’s that each and every consoles physical controller layout is an experience of it’s own that is well worth preserving, that it would be insanely fucking cool to be able to do exactly that with a single, modern-style controller, and that the only thing that stops us from doing that -not specifically retroarch, but emulation as a whole- is the physical inputs of Z & C.
Now, clearly these whole posts from me have exploded in an entirely other direction - and I’m sorry, I just flat out don’t know of a simple and concise way to communicate my advocacy for the idea without it launching into a whole thing… I honestly wish I did… it would save me a lot of time lol
The whole reason I even brought the concept up in the first place, was because I can’t talk/ask about the possibility of x-input being able to call on 2 more unique inputs without the immediate response being “Why would you even want to do that?”. To which my only response would be “Why WOULDN’T you?”
I’m still not entirely sure what benefit it would bring. I mean, if you buy a Genesis/Saturn-styled controller, it will work with no problems, no matter what ‘virtual X360 gamepad’ these buttons are mapped to.
Well then virtual gamepad mappings is not what we need to change; what we actually need is a physical gamepad with 6 face buttons AND two pairs of triggers. Not really sure if that would work with XInput, but DirectInput definitely allows it. The only thing is, is such a gamepad available on the market?
Yes, this absolutely requires a controller with the Z & C added to the common layout that we often see. To answer your question though, Yes, we finally have some controllers with this setup out there. Not ‘many’ as of yet, but that looks poised to change.
There is the Sabrent-16, which is a d-input controller that in addition to the Z&C slots, also has an additional set of start-select buttons for some reason. Nice for hotkeys, but a bit strange none-the-less. It took me forever to find a controller like this…
There are a number of controllers that ‘appear’ to have this setup - the biggest one that comes to mind is the HyperKin XBOX Duke controller… however the Black/White (Z/C) and LB/RB buttons are duplicated internally. This made sense as it was made FOR Xbox One, but it’s still frustrating none-the-less.
On the horizon we have Retro-Bit’s modernized Sega Saturn controllers. Not the ones that came out recently, but upgraded version that physically feature these inputs. I would be very surprised if we saw button duplication on this pad.
Also, if 8BitDo’s SNES controllers are any indication, we will soon see them announce a pro variant of their absolutely outstanding M30 controller, much like their pro SNES pads.
The problem with mapping a controller like this is evident when you “Bind All” You’re never presented with anything to map the physical Z & C buttons to, which means the remap menu itself via quick menu doesn’t even have options for those physical buttons.
As I mentioned, I’ve been using workarounds to combat this. Namely creating core overrides with keyboard mapped controls that correspond to xpadder profiles launched via rocketlauncher when I start a game.
Which is exactly where I’m at in looking into the subject. I’m hoping the Retro-Bit pad will answer this, as those support both d and x inputs. I can hook it up to my PC and see how it responds. That’s how I discovered the Duke re-release used duplicate buttons. (Though in the context of strictly Xbox, B/W and LB/RB ‘are’ the same inputs, unlike Sega and Nintendo. - - Ooo fun fact, PlayStation had an early 6-button design with + and - making up for the additional slots.)
I know that it’s a very small market right now, which is why I’m trying to always point out I understand that there is no support for it, and there’s not high demand for it, and so on. I know there are lots of reasons not to bother with implementing it. The dev’s time is valuable, and they already pour so much into things that are ‘actually’ priority.
My case is conceptual, not practical. An argument that adding 2 buttons holds far more value than it appears to at first glance. That “no one would ever use this” would be the wrong approach to the idea.
I could go on non-stop about it - obviously lol - but really and truly… I think it takes holding a controller like this, in-hand, and experiencing 40 years of consoles on a single controller without ever needing to stop and think about ‘where’ you put ‘this consoles’ inputs, because every single button/input is exactly where the original game developers expected it to be.
I’m not sure I found the right one, but if we’re talking about this one: https://www.sabrent.com/product/USB-GAMEPAD/twelve-button-usb-2-0-game-controller-pc/ (and it’s really the only controller names Sabrent I was able to find), then there is a caveat: it doesn’t seem to feature any Start/Select buttons, only 3 function buttons, that don’t seem to be progammable at all, so the total number of programmable digital buttons is still 12.
Oh. So that’s what you mean. Basically, the RetroPad abstraction layer doesn’t support more than 12 digital buttons on a pad, that’s the underlying problem. Well, yeah, it would be nice if there was at least a workaround (without using XPadder or whatever, since it would work on Lakka/other standalone OS-like builds).
Ooph - nope it looks like I got my wires crossed there with controller names/brands. I did buy a couple of those Sabrent-12 pads and yeah, start-select (much to my surprise at the time) doesn’t exist on them. It was very upsetting lol
I was talking about this 16-button one, which is from Buffalo (iBuffalo? It’s dual listed everywhere lol) https://www.amazon.com/gp/product/B0031UCGLW/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 (So 16 on this one, instead of 14, because of the additional Start/Select buttons)
YES~! See what I mean? haha I just didn’t know how to explain it properly. lol. So yeah, what I’m talking about is if there’s even the capability of upping that to 14 buttons - which would allow all the stuff I’ve been ranting about XD lol
Having a way to pause/resume recording would be awesome!
Scroll through playlist with maximized thumbnails in all menu drivers.
In rgui you can maximize only one thumbnail by pressing [Y] on retropad (default [a] on keyboard).
In this view you can scroll through the playlist.
In xmb, ozone, glui you can maximize both thumbnails by pressing [start] on retropad (default [space] on keyboard) But soon after you press any key you end back in the playlist view.
Having those feature unified in all menu driver would be neat:
Suggestion regarding DATE/TIME.
For those who use RetroArch on a PlayStation Classic console, DATE and TIME really does not matter at all, since the PSC does not have a internal clock system and is completely unaware of time.
So, my suggestions is:
Whenever you choose to DON’T DISPLAY DATE AND TIME, to also HIDE the “LAST PLAYED” entry in the HISTORY.LPL playlist. It really makes no sense to have a completely wrong date displayed there. Its wonderful to see how many times a game was played, but showing a wrong date, well, its wrong in my opinion.
I think this is something really simple to implement, am I correct?
Thank you sooo much! Cospefogo.
I would love to see the addition of a Confirm/Cancel prompt when selecting items such as “Save Game Override” or “Save Core Override” or “Save Game Core Options File”.
If I had a dollar for every time I accidentally hit one of these options, and destroyed my settings or had to then go manually into the …\config folder to remove the game .opt file… omg I would have enough money to buy the earth and still have enough left over for a down payment on the moon… lol
The XMB, and systematic theme are my favorite because of the variety of console, and content variations. I would like to suggest an upgrade to the XMB to allow you to use more than one icon per playlist, for example, being able to have a Nintendo 64 playlist that contains both the icon for the Nintendo 64 cartridge, and Nintendo 64DD cartridge in the same row.
With this enhancement I could see having a Game Boy playlist with the grey Game Boy cartridge icons in the same row with edited icons to represent the banana yellow cartridge for Donkey Kong Land, and the Red & Blue cartridges for Pokémon Red & Blue, etc.
I would also like to suggest an enhancement to the core options to auto select what settings are the most accurate to the console that you’re trying to emulate. It can be very tricky to look up things such as what Low-Pass Filter % should I use to accurately emulate a Sega Genesis MK-1601 (95), what should the screen gap be for the Nintendo DS NTR-001 (96). The default settings seem to be set up for speed, which is fine, but I think an option to auto select for accuracy would be a great addition.