RPCS3 Game Settings Database

[James-Coding]

I'm thinking that with the enormous amount of games that exist for PS3 we could mantein a game configuration database online and make the emulator check for the games installed on the system and then head to the online database for the best configuration availeable for each game synce by example ane game needs SRM while another needs scaling the screen to 125%.

[Mhmmm]

Not sure about a database, but there will be wiki for recommended settings to use in playable games.

[James-Coding]

Yeah, its a good start but i'm sure that a database will emprove game compat and emulator use since the emulator itself is the one that loads the most accurate settings for aech individual game.

[AniLeo]

I don't think we'll do a database, the idea is for games to work mostly out of the box. There will be a wiki though.

[JohnHolmesII]

I like the out of the box principle, but the reality of the situation, I feel, is that for the foreseeable future most games will need slight tweaks here and there. Especially when considering things like upscaling and having glitches not appear, as those may never go away. It would clean up #help a lot having the emu pull in good settings.

[andOlga]

Having it be pulled in automatically would mean said database needs to be of good quality. This will add more difficulty to the already complex process of game testing, and that's not to mention that good settings will vary from build to build, and even moreso from one hardware configuration to another. This will also mean spending a lot of time filling in this database for the already existing and tested games. Honestly seems like a massive waste of resources that could be better spent optimising the actual emulator and making games run better even with default settings.

I, for one, am against this, and support the wiki approach far more, since it doesn't push the settings down the users' throats and, if a wiki entry doesn't actually contain settings that help most users, well at least it won't automatically make the experience worse for everyone. A wiki will also allow much more freeform descriptions of settings, including conditionals like "on processors of the i5 lineup, use...", "on older builds, it might be necessary to enable this setting" or "If you have an AMD GPU, then enable...". Conditionals like this aren't impossible to code into the emulator/database, but again it's a massive waste of time and, even if this is coded in, it won't be perfect and with some more specific instructions will likely fail.

My opinion is the most we should do on the emulator side is simply add a link to this wiki in the emulator's "help" menu and not waste more time on this than necessary. Maybe make the emulator look up if a wiki article for a game exists and if it does, place the link to it in the game list UI. But not more than that, automatically pulling settings in can cause a variety of problems as described above.

[JohnHolmesII]

Lot of good points. But

Honestly seems like a massive waste of resources that could be better spent optimising the actual emulator and making games run better even with default settings.

Everything you just said applies to making a wiki as well. Everything takes work, that isn't news.

since it doesn't push the settings down the users' throats

This is a non-point. Users come into the discord all the time and say "hey whats the best settings for game x?". They're begging for more, not less.

even if this is coded in, it won't be perfect and with some more specific instructions will likely fail.

Nothing will be perfect. Weak point.

Broadly speaking, having an online database that feeds the emu AND the wiki doesn't take much more work than just making a wiki, which is already being done. And more than that, it's important to understand that no solution will ever replace the helpers in #help, so saying that some settings won't always be "databasable", if you will, doesn't fit the circumstance. I think your point about "freeform" descriptions is also rather weak, as the more "fine grained" settings and description details are, be they on a wiki or a db pull, the more likely they are to be invalidated by a new build. And old builds shouldn't be supported, especially at this stag in development.

Ultimately, I think the pros and cons of the two routes come out to about neutral. Therefore, I think it should really come down to @AniLeo 's decision, as bani is likely the one who will be implementing the system. If it seems like something that devs don't feel like maintaining, then the database would certainly be more of a burden than a boon.

[JohnHolmesII]

It's also worth noting the people working on the web stuff and the people working on the emu are not the same set of people, so resources won't really be taxed.

[andOlga]

Everything takes work, that isn't news.

The wiki can be filled in by both developers and users who are confident enough in their settings being correct. If the settings just happen to be wrong, well, no big deal, the users can just revert to default (or indeed come to #help, where we'll help them figure out what's best). In other words, the wiki can work on a post-moderation basis. If something incorrect is added to it, it can be fixed up by whoever is responsible for moderating the wiki later. If something incorrect is added to an automatic database, it will immediately affect every user with a new installation of the game, including the games for which the defaults would work just fine. This means that such a database will have to operate on a pre-moderation basis, and someone will have to review every new entry before it gets pushed out to avoid absolute chaos. This is more complex, as they will have to manually sift through every entry, instead of simply being notified of an incorrect entry on a wiki (or, hell, instead of that wiki article simply being edited by a user who knows better). What's more, it will complicate the job of helpers in Discord, who instead of simply specifying something like "change SPU threads to 2, and for the rest, defaults are fine" will have to provide the value for every setting just in case something from the database happened to change what the "default" is.

And old builds shouldn't be supported, especially at this stag in development

You'd wish that was the case, but sometimes old builds are a necessity to run specific games, due to regressions. Instead of making the user wait until some mysterious new bug is fixed, you can simply provide them with an older build that happens to run their game just fine. It's not ideal -- I agree -- but it's better than games being broken for weeks, or maybe even months, on end because of some recent change. There's also the matter of some games only working (or working better) on PR builds, etc.

the people working on the web stuff and the people working on the emu are not the same set of people

Yet this suggestion essentially brings us to merging the two together, at least for this feature. The settings change and the database access will have to be coded into the emulator itself for this to work.

There's also one final issue involved in this, the same issue that affects the existing compatibility database and thwarts the attempts at making an auto-updater for RPCS3: OpenSSL cannot be distributed together with the emulator due to some licensing complications I don't entirely understand, and it is required for the emulator to make API calls to the RPCS3 website. That means that we'll either need to ship this database offline together with emulator builds, which is a lot more troublesome because it can't be updated live and not everyone updates the emulator itself often, or keep making users download OpenSSL to access the database, which nobody's going to do and everyone will keep coming to #help to ask for help anyway. I completely agree, of course, that the final decision should come down to the devs: likely Ani, as you said, and also probably Megamouse who will probably be dealing with the Qt parts of this, should the decision to implement this be taken.

[al0xf]

Regardless of someone maintaining such a massive database it assumes there are best settings for every game which is never the case. Different CPUs will prefer different number of concurrent SPU threads in different games and so on. A wiki can with nuance discuss things like this at least (potentially, someone still has to write everything).

[dio-gh]

Since the original post, the wiki became a thing and is now more or less filled with settings and other infos. Unless this request ticket also vouches for automatic game configuration as well, it should be closed. Otherwise, it misses the longterm label.

[Asinin3]

Now that we have an api for downloading patches from the wiki I feel like some of the ground-work is in place to make this more of a possibility, and it's a good suggestion if it can be done as tri-state configs.

Some restrictions should be in place with which settings would be changed. The database should only change the required settings that work well for everyone or are required to run the game without issues. So things like turning on Write Color Buffers for Demon's Souls, Turning on Disable Vertex Cache for Scott Pilgrim... You get the idea.

Then we could potentially make it turn off settings that hurt performance and are used to fix graphical issues if they are not listed as being required. E.g Write Color Buffers... well maybe when the wiki is more mature.

Settings that depend on hardware/user preference should never be touched unless absolutely required to run the game without issue for instance: Preferred SPU Threads Additional CPU Checkboxes, e.g Lower SPU Thread Priority Resolution Scaling Multithreaded RSX Anisotropic Filtering SPU Block size

But this is already how the settings on the WiKi are being formatted, so its not an issue.

[magiruuvelvet]

Just some suggestion, but I think there should be a global kill switch option to completely disable downloading stuff from the wiki for power users who prefer to do things manually and don't like getting random settings shoved down their throat. Even better a build-time option to not even compile in the settings downloader.