Since there isn't one yet if possible I would like to contribute with the project by taking care of that. I have an extensive knowledge in WordPress customization and my goal is to complete the task ASAP.

Let me know.

@Paul-C-F
This would be nice. There's the forum, but that isn't easily searchable something like this.
Sadly the latter is horribly outdated, but I've found it very useful for researching certain problems in some games. It would be great to have one for developers, that lists possible problematic HLE calls, stacktraces, log files, etc. And possibly another for normal users, that simply states the status of games and the problems, settings, etc.

Also is WordPress the best tool for the job? But since you say to have extensive experience with WordPress, you might be able to make it work.

Hi Tambry, WordPress will be perfect for the task since it is fully extensible.

For the programmers what I would do is to create a custom Wordpress plugin that accommodates the data structure defined on the spreadsheet you've specified (test_comp). This allows us to enter data using standard forms, search it, filter it and display it in the website in any shape of form that we want.

For the regular users I would create a simplified plugin to display a table on the website that can be filtered or sorted.

We could also integrate it with Pastie and GitHub using its API so there will be no need to jump back and forth copying and pasting data.

@Paul-C-F
That would be great!
Here are a few ideas I came up with.
It would also be nice to have a filtering option for different modules, so you could see different games that use the given module.
Maybe parsing of the log files for settings (they are printed at the start of the log file along with LLE modules and other info), maybe also include the vertex/fragment program(s) along with the error(s), if one occurs.
Maybe even add an ability for users to report problems with a certain game?
I'm sure other developers also have other great ideas for integration.

That should be no problem, since I'll store this on a database I'll collect all the requirements with you and the other folks and then I'll work on a diagram for normalization and other tasks which then I'll run by you one more time before any coding is done.

As of the log files as long as they are standardized string parsing will do the trick. An option to upload attachments should assist the users and developer in the process of including helpful debug information.

We can certainly limit some of the options if we need for non-developers (or non-logged in users) to report their own issues with certain games.

I'm just going to setup something based on that spreadsheet on a temporary site within the next 2 weeks and then I'll ask you to try it.

Well, for starters something that would parse current forum and build compatibility list from there would be nice.

@danilaml But the forum 'compatibility' list is quite bad. Quite many of them likely are in the wrong category. I'd prefer a fresh start.

@tambry It'be better to export forum list as a table though. It'd be much easier to work with and move them to the right category. We already have quite big collection of games reported.

@danilaml Exporting it as a table makes sense, but I still think that the compatibility list should be started from scratch, so we can have all the info from all games.

I need to put together the data structure for the title list before any importing or scrapping is done, I'll need some help with this:

Game Title Structure

• Title
• Title Code
• Status -> Choose from enumeration (Playable, Half Playable, Intro, Loaded, Unknown, etc)
• Comments -> Paste or edit text (One to many)
• Log -> Upload text file or paste text in the form (One to many)
• Screen Captures -> Upload, JPEG (One to many)
• Screen Recordings -> Paste YouTube link (One to many)
• Emulator Settings -> User input (Key Value Pair structure)

Let me know about the following approach:

A nice emulator compability frontend: http://xenia.jp/compatibility/

As you can see in this case they link the compability table to a GitHub project setup just to store compatibility updates (https://github.com/xenia-project/game-compatibility).

When using GitHub to achieve that they can then 'tag' each issue with 'playable, menus, etc', which then can be read back by the front end that gets displayed on the website.

Log files can be attached to the issue by dragging and dropping a txt file onto the comment editor. (https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/).

Gameplay screenshots also can be dragged and dropped onto the issue (JPEG, PNG, GIF).

If everyone agrees I can create a wordpress plugin that does the same thing:

• Creates a compatibility table that can be filtered, etc
• Syncs from a GitHub project that we setup just to store game compatibility.

While Xenia compatibility frontend for normal users seems OK, I'm not sure if Github issue tracker is a good choice for a backend.
How would you keep track of exactly when the status changed? And what were general comments? How would we keep track of used imported functions and called HLE functions and different errors and the shader files? I think it might be best to simply have a custom backend, where we can store all kinds of information like we'd want. But that's my opinion

If you want a Github project set up for committing code or whatever, let me know.

Gotcha. The user front-end is very simple I agree, but perhaps it should be that way for 'normal' visitors that just want to quickly check the compat for a certain game.

Could you please provide me with a *_complete *_game compatibility *_sample *_so I can come up at least with the initial version of the custom backend? After I get that done we'll see what can be improved. If you already know of something that should be implemented or not in the current way that you guys are doing it then please send to me the sample in the way it should be like so I don't waste time later deleting stuff that shouldn't really be there.

Looking forward

For me, something like in https://docs.google.com/spreadsheets/d/1DJHDYrBKz9ligX5WmWCXkealUNhW_mbE-FevrJC6_nQ/edit#gid=0 seems OK (simplified of course). I think there should at least be revision and log columns.

Ok so here we go, I created a diagram using draw.io, if someone would like to edit it as well let me know and i'll share the google drive file with you.

By looking at the forum and the spreadsheet I came up with this diagram, please revise and get back to me with suggestions, questions and corrections.

@Paul-C-F I don't think a klic is really needed for a game, as user never really has to worry about it, and it would be only useful for decrypting EDAT files, but which we nowadays do automatically.

Excellent, klic will be removed.

I'll wait for more suggestions like this until we almost perfect that diagram, then I'll jump into the plugin creation.

One more thing, keep in mind that we can hide developer only data from regular users but we still need to store them.

Small update, keep coming the comments.

@Paul-C-F
It would be nice to require the user to upload their configuration file, so we have a track of exact settings.
Maybe have the ability to assign different flags to the game like:

• DX12 issue
• OpenGL shader issue
• HLE problem
• cellGifDec bug/unimplemented function
• Audio problems
• Requires LLE
  etc

Also if we require the user to upload the config file, we could simply parse it for all the info, and notify the user, if he used some possibly problematic settings (using a recompiler, different filesystem paths, etc). Would be lovely to have all settings like that displayed in a more human-readable format.

Here we go, 'Game Settings' now can take an attachment which happens to be the an user config file. In this case it servers both ways, either the user enters some specific Key Value pair settings, eg: Renderer = DX12 and/or he uploads the config file.

Visitors can opt to manually change their config based on the suggested settings or download the provided ini file which happens to be stored under Attachments under the 'Config' category.

And the 'Tags' will hold the necessary tags/flags which can be assigned to a Game.

One last thing, the INI attached by the uploader can than be parsed by the system and we could allow the visitor to upload his INI config and compare side by side the settings flagging different and missing values among them.

the question is how can we control if all setting in the ini ar used in the currend version. because in the ner furture stable versions of the emulator and ther will be test versions with test settings that exist jast in one build.

@annahana There have never been 'test options' on the master branch for past 2 years. There may be non-master builds shared to more trusted testers before they're merged into master, though. But those shouldn't ever be used to determine statuses of games, and the status of games should only be tested on master branch with no modifications.

I've added 'MinAppVersion' to the game title to denote the minimum emulator version required to run the title.

The same column is available under Game Settings and individual Setting Values. if this column is set to let's say '1.1' then we can have a simple combo box on the UI that will allow the user to filter the settings that was certified to work with the minimum app version that he selected. If no min app version is set then the setting is always visible.

Perhaps it should log out the binaries SHA1 in the log so you can check where it came from.

@paulsapps That would be useful, but it would be best to have it simply log as 'official' or 'unofficial', but I'm not sure how useful that would be.

@tambry I thought it already did: ·! RPCS3 v0.0.0.6-4112-39bc897 in my rpcs3.log.

@danilaml That's the tag, the commit number and some of the first characters of the commit hash(?), AFAIK.

@tambry do you want the full hash? 39bc897 is enough to identify commit most of the time.

@danilaml It will help identify commit, but it won't help us identify, whether the build was an official build or not.

@tambry there is no official builds though. And all builds built from the same commit should function the same. And you want be able to identify if the build was 'official' if we don't start providing signed builds.

If you meant official build as if 'built from main branch of RPCS3 repo' when commit SHA is enough for that.

.TIP: The sails of the sunken ships hide polyps and sharks. Press Button Batter the map. But the movie characters and basic gameplay are oriented to give younger players a good gaming experience. Use the map to find the polyps so you don't wander around and become shark food.TIP: Fishfriends can be selected from the screen. The little mermaid font free download. Ariel Disney's The Little Mermaid will have you humming 'Under the Sea' in no time.

Well, I guess commit SHA is actually enough.

Maybe it would be enough to have the user check a checkbox, that they used an official build from here or AppVeyor artifacts.

@tambry I don't see the point of doing that though. What if they built RPCS3 themselves? What if it's from emunewz? There's been no problems with any builds that are built from master branch. (correction: there was problem with Bigpet builds when openal dll was renamed and his build script didn't account for that but that had no impact on game emulation).

@danilaml I guess it would be best to then have the script check the current commit hash and the log's commit hash. That would probably make most sense then.

Since people could build with diff compiler options etc I think it would make sense for people to only test with 'official' builds so dev time isn't wasted on hacked or bugged builds. If the log had the SHA1 of the executing binary it could be tagged against the build server build? I guess that could still be faked if someone really wanted to sabotage.

@paulsapps what compiler options? You just clone and then build. Wrong compiler options - the game won't start. If a person is familiar enough that it can tweak different settings then it most likely will think to include it in the report. If people wan't to sabotage they can easily do it with any build - just post bogus info.
WTF? don't over-engineer stuff. Maybe we should use some kind of DRM with our emulator too? So that only approved builds can be used?

Well the likes of zangetsu changes optimization settings which can expose compiler bugs. Printing the binary hash in the log isn't that extreme.

@paulsapps it will be tagged with different commit sha.

@danilaml It won't, if he doesn't commit.

@Paul-C-F Did you manage to get the list up and running somewhere?

I was actually waiting to see if someone had something to
add/remove/adjust to
my diagram plus there was a long discussion above between the devs.

On 3/5/2016 6:29 AM, Haapavuo wrote:

@Paul-C-F https://github.com/Paul-C-F Did you manage to get the list
up and running somewhere?

—
Reply to this email directly or view it on GitHub
#1449 (comment).

Any news?
It would be nice to have a compatibility list like the ones PCS2X and Dolphin have
http://pcsx2.net/compatibility-list.html
https://dolphin-emu.org/compat/

Alright then, since the discussion here has ended and nobody made any comments or suggestions I will get started this weekend and as soon as I have it ready for testing will upload on a temporary hosting so you guys can check it out and get back to me.

I think it should be a good idea that under each game's status there was an entry for each renderer (openGL, dx12, vulkan) because they still have differences between them

Any news on it?

it's in the works, estimate time for testing: 2 weeks

On 4/16/2016 5:55 PM, AnnieL wrote:

Any news on it?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1449 (comment)

I made this change to accommodate your request, based on this game status changes can have specific setting values tied to them:

I have a few suggestions that (in my opinion) would improve design:

• Tags should be global, for easier filtering/grouping. This means relationship Tags -> Game has n.m cardinality, so modified version should be Tags <- GameTag -> Game.
• (Min)AppVersion is used extensively. It should be a separate class, and possible attributes include ShaCommit and href to build download or GitHub commit reference. This provides normalization and better support for 'official' versions.
• [Maybe?]Game/GameVariant separation. Game would act just as a container for game variants (i.e. 'God of War 3'), and variants (i.e. 'God of War 3', region 'PAL') will have all information (of course, GameVariant corresponds to Game class in current design!). It provides better frontend organization and dramatically reduces game list length (Variants nested inside game, instead of God of War 3 (NTSC), God of War 3 (PAL), God of War 3 (JAP)..).

Thanks for the input. Please see bellow an updated version of the diagram.
In order to simplify the diagram so everyone can understand it I'm still omitting a few data structures that tie objects together, but I've added Games2Tags to better demonstrate the relationship between them.
I'll wait two more days to see if there will more changes.

Sorry for the delay.
I think all relations on Games should be changed to GameVariants, so Games it's just a container of variants.

The reason is that, for example, a game could be 'Playable' (Status) on NTSC variant, but 'No boot' on PAL version! The same applies to StatusChange, MinAppVersion (NTSC='1.0.4', PAL=no one because it's broken), Links, Attachments, Game2Tags (NTSC='playable' tag, PAL='hle-bug'?), Comments, GameSettingCollection..

I think Games should be used as a container for frontend purposes!

Good point.

Any updates on this?

Closing since it hasn't been updated for 8 months and we now have a compatibility list on our website