Development Suggestions

General Development
#76

RA is great.

I am new here but I have come across 2 little problems.

  1. per system configs. Guessing this is hard to impliment but having different sets of configs for cores that emulate more than one system would be great.
  2. Having to rename override config files in android is a small pain

ps. alot of the development requests i read were trying to turn retroarch into a full on frontend. Im not sure but could going that way take time away from keeping retroarch an amazing emulator. Saying that an all in one frontend/emulator would be the nuts!

#77

  1. RetroArch doesn’t have any idea what a system is, only cores. The way to do it would be to compile a second copy of the core with the internal name changed (e.g., change ‘gambatte’ to ‘gambatte-gbc’ in the libretro.cpp file). I compiled some for Windows and posted them in the Windows subforum but I don’t have a Android toolchain set up.

  2. That sounds more like an Android problem than a RetroArch problem :wink:

#78

  1. Cool I did see a thread about that somewhere. Maybe in the future I will make a project of mine. Where is the place to find the android core files? :slight_smile:

  2. Ok just to confirm so I can trouble shoot. This is the only way I can get overrides to work:- (With overrides on, per cores off, save on exit off also, I have changed the config path director to the com.retroarch/files/configs, so I can access it in android)

1.Retroarch.cfg auto loaded 2.Load content/core 3.Changes settings 4.Hit save new config 5.Rename the output .cfg to the 6.core name (Nestopia.cfg for example) 7.Create core name (Nestopia) folder within config folder 8.Place renamed .cfg in that folder.

(Overrides now load fine for that core)

Info from http://blog.andressm.org/new-retroarch-features-2/

amongst other places

Is that all correct or should retroarch be creating those .cfg and folders automatically?

#79

That works, yeah, but the override system was really designed around the idea that you wouldn’t be creating entirely self-sufficient cfgs as overrides and would instead just change the handful of options you needed to have different (e.g., input binds or a different shader). We would like to have it compare the existing cfg against what’s in memory and save an override with just the options that are different but that’s surprisingly difficult to implement.

#80

Yeah I can only imagine how hard this stuff is to implement!

So I am actually saving a whole .cfg that is being loaded as an override is see now.

Is there a specific step to just tell it to save the changes? From your reply it sounded like this should be all automatic but still a work in progress.

#82

Thank you for clearing that up, taken me ages to figure out.

#83

i’ve been thinking of a way to better handle saving per-game config files. at the moment it’s easiest for me to create them by hand, with a file template of:

setting_whatever = foo
# Never save-on-exit after an override config# or the override will make into the core config.
config_save_on_exit = false

(the config_save_on_exit part is key!)

and then dump them in my content directory, with a name of gamename.zip.cfg (for example)

i think this could be automated, and put under a RA option ‘save per-game config’ or something like that? what i would expect it to do is save the file as described (complete with config_save_on_exit = false), but only containing entries for options which have been set up DIFFERENTLY from the loaded config file. essentially making the per-game-config a diff of the normal configuration, which is how i use it.

i might be able to do a PR for this myself but thought i’d check to see if it’s sensible/useful for others first!

#88

Perhaps we could have a playlist config override to resolve this problem of different machines using the same core? It would take priority over a core override when launching from a playlist.

#89

I would like to see a screenshot/thumbnail system implemented for save states. Currently picking a state to load by number is a bit of a guessing game if you have several. It would be awesome if you could see a little thumbnail of the save state before loading it.

#90

Instead of having multiple thumbnails that are the same, could we make it so retroarch can read a text file pointing to the image.

Like: “Batman - The Video Game (USA) (Beta 1).txt” with “Batman - The Video Game (USA).png” inside of it.

#91

How about fixing the timing of the Prosystem core when playing One on One…it is way to fast. I came acrosProSystem.dat.zip (3.52 KB)s a prosystem.dat file that does just that. It is attached to this message.

#93

As I continue to download the new versions, and think they are great, I cant help but wonder why there isn’t an “Update All” capability within the online updaters. I think that it would be great if when I am in the new Thumbnails Updater, or Cores Updater, etc… if I couldn’t have an update ALL so that I can hit that, and leave it for 10 minutes until it is completed rather than having to do it one-by-one. I think on-by-one still needs to be there, but I think it is really missing an All capability.

Thanks Much for listening.

#94

The biggest issue with ‘update all’ is that we host everything ourselves and bandwidth costs money. If everyone were thrashing our servers constantly updating everything, it would cost a fortune in hosting.

In addition to that, though, we would need a way to do version tracking and checking to know what people have vs what’s new and then pick and choose the things that need updating.

#95

So I too am a software developer, and from your response, I have to admit, this might solve your bandwidth issue. When I get a new version, the interface doesn’t give me any feedback as to what versions I have, nor if there is indeed an update for the core, so I invariably download ALL cores anyway. If the updater list gave current version, and showed if there was an updated version available, then I would only update the ones for which there was an update available. This too, with an update all, it could automatically check the versioning, and only download the files that have updated versions. This would mean integrating a version querying ability into the core libraries, and now somehow into the thumbnails updating, but I think it would actually SAVE you having to serve out as much. Internally, if a user tries to download something that already exists you could check for it, then not download!!!

#96

As much as I love RetroArch, I have a problem with the game saving and save state system. My problem is that I don’t like the idea of having to re-beat all of these games that I completed as a kid because I can’t convert my save files to SRM in a working fashion. For example, I had to beat Super Smash Bros. on N64 again because the save file won’t convert to SRM (by the way, I’ve tried the software program p64tosrm and it didn’t work in this case). Since RetroArch categorizes all saves in SRM format, I have three suggestions:

  1. Create an online database within this site, similar to Gamefaqs, where RetroArch users can share their game save files and save states that are written in the compatible SRM and STATE extension formats.
  2. Create software that converts all save files and save states for all consoles to SRM and STATE
  3. Support different save file extensions within RetroArch that are compatible with all other cores (i.e. N64, PSX, Dreamcast, Saturn etc.)

Do any of these suggestions sound realistic? I’ll admit, I’m completely a tech noob so I might not know what I’m talking about :stuck_out_tongue: As much as I love RetroArch, this is the one hindrance that’s holding it back imho. I also believe some of these problems could be remedied if more consoles supported cheats. For example, I know N64, Dreamcast etc. have Gameshark support. If we can use Gameshark codes, we could just use the “unlock everything” code in each game and save to alleviate this problem.

#97

It would be great a “centralized” way to choose the input for player1, player2, playerN. I mean a menu to let the user see what input devices are available and choose what one to use for player1, player2, playerN.

I know that currently we have the “Settings -> Input -> Input User N Binds -> User N Device Index” to do that, but it has a little weird behavior: it changes the input instantaneously!

OK, changing the configs instantaneously is the expected behavior, but with the input device it can bring weird situations. I have examples.

Example 1: I was using RetroArch on my Android phone with an ipega bluetooth controller. And went to the “Input User 1 Binds” to change some buttons, while navigating through the menu I accidentaly pressed Right while in “User 1 Device Index” and lost the control of RetroArch through the ipega controller.

And this field can’t be changed with the touch screen. Hours later I had the idea to enable “Display Overlay” and disable “Hide Overlay in Menu” and used the touch-screen joystick to change back the “User 1 Device Index” to my ipega.

Example 2: I have a Raspberry Pi with the following scenario:

  • RetroPie installed (linux Raspbian)
  • 1 USB adapter for two playstation controllers
  • 1 PlayStation 2 controller (only one controller!)
  • 1 8Bitdo Zero bluetooth controller (properly configured in the system)

RetroArch recognizes the adapter as two joysticks (Twin USB Joystick #1 and Twin USB Joystick #2) even if there is no joysticks plugged into it. Well, I was using my PlayStation 2 controller as “Twin USB Joystick #1”, and wanted to change the “User 1 Device Index” to my 8Bitdo controller. I pressed Right, it changed to “Twin USB Joystick #2” and I lost control of RetroArch.

I had to exit RetroArch and manually change the input_player1_joypad_index in retroarch.cfg file to get the control back.

So… That’s why I think it would be great a centralized way to choose the input for the players.

Thanks!

#98

I second a way stop stop instantaneous input binding. I had monumental troubles setting up inputs in the first week of using retroarch.

Maybe something like you save the profile then you can review it and activate it. Including the device index. I don’t understand the complexity but activating a profile doesn’t sound to complicated, with it being similar to the remaps system already implemented

#101

I started an issue in RetroArch github talking about this problem:

#102

I just started using RetroArch and i love it! The only thing i am unhappy with is the lack of consistent cheat support across cores, such as for Mednafen-PSX, MGBA, DesMuMe, and a few others;

Suggestion: Cheat support for more cores.

#103

I second more cheat support for all the cores :slight_smile: