Can be added new nes core :
https://github.com/punesemu/puNES
Im like this emulator it can be added ?
Can be added new nes core :
https://github.com/punesemu/puNES
Im like this emulator it can be added ?
I would like a more visual way to set input. I had a hell of a time trying to configure my joystick with the Dreamcast joystick option in Flycast.
Ability to add a new shader anywhere in the chain and not just at the end of it. Shaders behave differently depending on their position in the chain. If you want to add a shader at the top of the chain of a preset that has a lot of shaders already requires a time consuming manual editing of that preset.
Also, the ability to add game titles in an XML and save RA/shader/core XML overrides.
An option on the configuration to auto-load the top item on the āRecentā playlist (both core and content) when opening Retroarch, or at least a cmd-line argument for that behavior. That paired with Auto Load State would make for a great āresume gameplay as quickly as possibleā feature. Doesnāt sound very hard to implement as well. Iām sure itād be popular with the Steam releaseā¦ you just launch Retroarch from Steam and it goes straight to the last thing you were playing instead of having to go through additional menus to select content when you already had to browse through your Steam library to get to Retroarch in the first place.
Adding the possibility to use custom icons for system / content from within the GUI.
Maybe in Settings-Playlists-Playlist Management
the same way as selecting a default core for a playlist.
Settings could be stored in the new playlist file format like this:
{
"version": "1.2",
"default_core_path": "",
"default_core_name": "",
"default_system_icon": "", <- add this
"default_content_icon": "", <- add this
"label_display_mode": 0,
"right_thumbnail_mode": 0,
"left_thumbnail_mode": 0,
"items": [
{
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