Development Suggestions


#141

Having a manual viewer and being able to attach manuals to games ala box images would be great.


#142

Two small UI suggestions for XMB.

1 Add option to hide the “remove” action from the playlist game submenu. Leave only “run” and “information”. It is too easy to by mistake remove a game, especially since there is no “are you sure?” step.

2 When closing a game from the menu RetroArch returns the user to the closed game’s submenu with the row “information” selected. Change that to instead show the playlist with the closed game selected. Because after choosing “close” (and not “restart”) the user probably wants to play something else, not look up information on the closed game.


#143

Suggestion to develop a UWP app. Specially now that xbox one supports UWP. Let’s get retroarch to xbox one guys!


#144

A while back, you guys said you were thinking of implementing a program for fully customisable overlay touch controls, similar to what mame4droid has. Is this still on the list or…?


#145

No, it never got prioritized and probably never will, tbh. There’s no reason someone else couldn’t produce such a thing, though.


#146

Got it. Thanks and cheers!


#147

I noticed that savestates can take take some space, especially savestates for psx or snes and sega ,regular saves can take quite some space as well, for some reason mupen’s 64 regular save take 69MB but when compressed with 7z only 26kb. I guess with savestates which need to be very fast or core unpacking every time, bellow solution might be tricky to implement but, would it be possible for retroarch to compress saves and savestates on the fly?

Settings to enable compression for particular cores for regular saves or only savestates (since regular saves dont take that much place in most cases). Maybe even compression of other elements that are not used frequently like assets that are not currently selected like shaders bioses, individual cores (in case of those they could be unpacked only when needed and then deleted). Each asset would be compressed individually to make decompression/compression faster.

I imagine this feature wont make priorities list any time soon but something that could be considered at some point in the future.


#148

I did not know there’s thread for this, so I am reposting.

First of all I’m loving this project. I’m making some custom overlays gamepads, so I can play better on my iPhone, and will share with the forum soon, but my objetive here is another.

I ever loved playing emulators, SNES and GBA are my favorites, but losting the save… oh man, it’s very frustating.

I loved the fact that I can play the same save in my Mac that I saved on my iPhone. Currectly I’m syncing them using the icloud, but wanted to use DropBox, unfortunately there’s no way for iPhone… (I can do with icloud because there’s a folder in iphone (/var/mobile/Library/Mobile Documents/com~apple~CloudDocs to be more especific) that allow me to save and auto sync with icloud) . I wanted to use Dropbox so I can play in every device my saves! I mean, I can simply play on the bus, using iPhone or 3DS, get home and continue playing on my… humm… ps3, or even my wii u! I wanted them synchronyzed! More of it, I have the safety that I will not lost my saves, that for me, is a lot important. Well, maybe retroarch could have an automatic backup of saves too, but this is another idea.

There’s any plan to make this happen on retroarch?? I could contribute with this, but I am very ‘beggining’ with programmation and I am afraid I can’t do it… (maybe with help I can colaborate…) So, this is my idea.

I hope someone that is hard contributing to the app read this.

Thanks!


#149

-move “Remove” from playlist/history to somewhere else, like a different menu for “management” related stuffs - it has been so many times that Remove is accidentally clicked - who thought that this was the best location next to the Run button? -allow to modify or run using different core games from playlist - it does not makes sense that you are stuck using the last core you used for that game considering that some system have different cores to choose from. -allow to manually download thumbnails for each game - there is no sense to update entire thumbnails (mame alone is about 6gigs) when you do not have or do not play ALL system and games current retroarch database supports. -allow only to download newer version(and i mean newer version/builds, not a new compiled builbot item but the core is 2 years old) from stuffs in Online updater - again there is no checking here, you can accidentally click the same core for example over and over. -considering retroarch is all-in-one kind of thing, the UI lacks so much as standalones do. game databasing is massively lacking, there is even no roms count-total or per system or hour played. probably the ability to sort list by publisher/developer?(who want to play stuffs released by LJN anyways) -search option for playlist should be optimized-match keyword properly. example you search for Zelda, you will get Zelda II - A Link to the past but not Legend of Zelda. search Contra and you will not see Super Contra or Super C, search for Mario and you will get the classic Mario like the arcade thing but not Super Mario - isnt this suppose to be the basic search behaviour-give result by keyword? -allow support for wav/ogg and other compressed audio format for cdimages - for playback purposes, its better to use compressed audio to save space. -allow to manually add items to playlist, like add hacked or translated roms - again this is for database purposes-incase implemented like rom count, played count etc.

i want to keep using retroarch for convenience but the things above make me use UI from others frontends instead or just use the standalone since some core options are removed(like manually assign turbo key to buttons for PCE/Supergrafx since only a games uses 6buttons)

(more later…)


#150

Make saves actually save when they are natively supposed to,if the game freezes,core freezes,or RetroArch crashes after a long session of progress,the save file never got updated and everything has been lost from that one crash.

It should be simple to keep tabs on when a game was supposed to save by emulating the internal function for it,and many stand-alone emulators do this all the time. I would say we should expect nothing less than that saving quality to the point a speedrunner’s reset trick doesn’t end up losing save file progress.

It really sucks when you would play a frustratingly hard part of a game dozens of times,beat that part and save at a save point,then it crashes a few moments later,and guess what you have to do AGAIN because it didn’t update the save file accordingly. This is just an example of how horrible this problem can be for anyone unfortunate enough to run into it.

Thanks for reading.


#151

@retroben It’s actually extremely hard to determine when a game is saving because some games use SRAM for additional RAM, which means it’s getting written to constantly. Thus, writing to file any time SRAM changes can be very bad for solid-state storage and could also be an issue on I/O-constrained platforms. We could try putting in some heuristics but that will inevitably have edge-cases and so on, particularly in the context of the number of platforms (both physical and virtual) that RetroArch supports.

However, we do have the settings > saving > SaveRAM Autosave Interval option, which will flush the SRAM to file periodically (the default is every 10 seconds). As long as a crash doesn’t happen within that 10-second window just after saving, everything will be kept.


#152

[QUOTE=hunterk;53066]@retroben It’s actually extremely hard to determine when a game is saving because some games use SRAM for additional RAM, which means it’s getting written to constantly. Thus, writing to file any time SRAM changes can be very bad for solid-state storage and could also be an issue on I/O-constrained platforms. We could try putting in some heuristics but that will inevitably have edge-cases and so on, particularly in the context of the number of platforms (both physical and virtual) that RetroArch supports.

However, we do have the settings > saving > SaveRAM Autosave Interval option, which will flush the SRAM to file periodically (the default is every 10 seconds). As long as a crash doesn’t happen within that 10-second window just after saving, everything will be kept.[/QUOTE]

i think the default is never-this is the 1st thing i configure everytime i update using the nightly builds


#153

Yes, the default setting is indeed OFF. When you enable it, there are some different levels, of which the first is 10 seconds. I can see how my statement was confusing :stuck_out_tongue:


#154

As I’ve asked just now on here: https://libretro.com/forums/showthread.php?t=7868, I’d like to request an option to allow updating the SRAM whenever the game asks for it.

I know RetroArch only updates it on proper closing/specific intervals, to save write cycles, but for a few games (like anything that uses a Memory Card), it’s more economical on write cycles to save whenever the game wants, than turning on auto-update of SRAM every 10 seconds (the minimal interval).


#155

There is a reason for it not being done. Some games use SRAM as RAM (yeah really) you would be flushing that data constantly to storage on every frame (that’s 60 times a second)

It’s not just saving write cycles, I/O causes a performance hit.


#156

need help in debugging an crash issue have with retroarch when retroarchievement is activated. leidarel suggested this:

Since we’re having trouble to reproduce the issue, could you put a breakpoint at cheevos_get_description and step until line 2825 (where strlcpy is) and check these variables? [ul] [li]*desc[/li]> [li]cheevos_locals[/li]> [/ul] Thanks

i already found those lines in cheevos.c but i do not have cpp or any object oriented programing (nor debugging skills) to add breakpoints there nor know to check its variables. i only have been using notepad++ to edit and view code.


#157

Then explain to me how come every other emulator i’ve ever used have no trouble saving my games? Once I save, it’s saved. No amount of crashing should EVER make my correctly saved data be lost.

However that’s not the case with RetroArch. And besides, does PS1 constantly writes data such as this? Or any other system that employed a Memory Card?

Because if they did, how come the memory cards didn’t run out of writing cycles in seconds?

And if they didn’t, why force that behaviour on these systems as well?


#158

[QUOTE=Radius;53301]There is a reason for it not being done. Some games use SRAM as RAM (yeah really) you would be flushing that data constantly to storage on every frame (that’s 60 times a second)

It’s not just saving write cycles, I/O causes a performance hit.[/QUOTE]

Then explain to me how come every other emulator i’ve ever used have no trouble saving my games? Once I save, it’s saved. No amount of crashing should EVER make my correctly saved data be lost.

However that’s not the case with RetroArch. And besides, does PS1 constantly writes data such as this? Or any other system that employed a Memory Card?

Because if they did, how come the memory cards didn’t run out of writing cycles in seconds?

And if they didn’t, why force that behaviour on these systems as well?


#159

First of all, the real fix is fixing the crashes, not masking the problem. Second, this is partly an API limitation. The API can’t differentiate reads and writes. I don’t say it’s a problem, it can be done, it’s just a bad practice.

No PS1 doesn’t do that. But libretro doesn’t have specializations depending on the platform. That’s a bad practice too (changing the API for every possible use case that pops up).


#160

What about a button that would do whatever needs to be done, which is I assume tell the emu, its ok to do whatever you need to do do keep the save? Like dedicated “I just saved” button?