Update RetroAchievements page to point towards official docs for supported cores

[Hexadigital]

There's been quite a bit of confusion from RetroAchievements players who find the libretro documentation, use the list of supported cores, and then discover that they're using a core that isn't actually supported.

If it's fine with all of you, we'd like to adjust the libretro documentation to point towards our documentation, as the libretro documentation keeps falling out of date and has had core developers marking their cores as supported when they're not.

For example, Geargrafx (for PC Engine), DeSmuME 2015 (for Nintendo DS), and ClownMDEmu (for Master System and Mega Drive) have never been supported - and cores like QUASI88 (for PC-80/88) are supported.

Additionally, this updates the note about hardcore mode giving double points and instead clarifies that it places players on a separate leaderboard and allows participation in site events, as hardcore mode has not given double points since 2021.

[hizzlekizzle]

Cores that are not listed as supported are likely to have issues with achievement logic

Is this true? Are you guys getting a lot of tickets about this?

[wescopeland]

Happens all the time. It's probable we'll start force dropping problematic cores to softcore mode via our server APIs at some point.

[hizzlekizzle]

Any chance we could get a list of cores/problems to try and do something about them?

In the meantime, while I'm happy to link to the official documentation and explain the difference between "supported by RetroAchievements" vs "supports retroachievements," and how that may affect accessibility of hardcore mode, I don't think deleting the list of cores that "supports retroachievements" is the right move.

[Hexadigital]

We do try to support every core that we can - anything that we consider unsupported is strictly due to technical differences that cause achievement logic to fail, such as less accurate emulation, unexposed memory, or memory that otherwise doesn't line up with what we support.

The reason we would want to block unsupported cores in hardcore is because it's a large pain point for players, achievement developers, and staff - new players get confused as to why achievements aren't working and end up leaving the site, achievement developers constantly get tickets from players using them for which there is no solution other than closing the ticket and telling the player to use a supported core, and staff have to handle manual unlock requests from players who ran into issues and need the achievement manually unlocked (with proof that needs to be verified) as a result.

Wes might be able to give a more detailed list, but for a few examples of cores that I've seen players trying to use and why we can't support them:
ClownMDEmu - stores memory with a different endianness, causing 16-bit values to be byte swapped compared to what logic checks for.
DeSmuME 2015 - less accurate emulation, memory can be shifted a few bytes for some games which breaks achievement logic.
DoubleCherryGB - doesn't expose all memory, includes features for Pokemon that would be considered cheating under hardcore's rules.
MAME - exposes memory completely differently from FBNeo, differs per-driver rather than following a standard mapping.
Nestopia - one of the more infamous ticket creators on our end, doesn't map SRAM and mapped RAM is often wildly different.
PCSX ReARMed - less accurate emulation, also zeroes out kernel RAM without a BIOS, which some achievement logic requires.
Snes9x 2010 - one of the more infamous ticket creators on our end, doesn't map SRAM and mapped RAM is often wildly different.

[hizzlekizzle]

Nice, thanks! I think some of those we can probably do something about, some not. For the ones we can't do anything about, excluding them from hardcore mode seems like a reasonable thing to do--especially DoubleCherryGB, with its cheat-style features.

How about we add a link to you guys' "supported by RetroAchievements" list at the top, and we can explain that the rest of the list on our site can at least fetch and display achievements, but if they're not on you guys' official list, they may be excluded from hardcore and regardless shouldn't have an expectation of tickets/unlocks if there's a problem?

I suspect some of those, like PCSX ReARMed and snes9x2010, are probably mostly coming from chinese handhelds, where they can't use more accurate cores due to the weak hardware :/

I think we can probably use the 'notes' field there to include some of the information/context you mentioned to steer people to other cores, if/when possible. Can you think of any other word we could use on our matrix than "supported" to help disambiguate "supports retroachievements" vs "supported by RetroAchievements"?

[Hexadigital]

To approach this from a different angle - is there a reason why you'd want a list of cores on that page that "support RetroAchievements" versus those that are "supported by RetroAchievements"?

Technically, any core that emulates a system we support and exposes memory has the ability to fetch and display achievements (including most of those marked as unsupported in the documentation currently), but if it's not one that is supported by RetroAchievements, then it is either very new / untested or has been found to have issues that are guaranteed to prevent players from earning achievements. (or worse, it causes players to unlock achievements that they didn't actually get)

Our goal/hope is to help prevent players from using cores for RetroAchievements that have known differences from the ones we support, and by extension, provide a better experience for players who find (or are pointed towards) libretro's documentation rather than ours, as well as reducing our manual workload and the number of frustrated players caused by achievements failing to unlock. We're definitely open to alternative approaches so long as that goal is accomplished.

If the concern is just moving the list of cores outside of libretro's documentation, are there other ways we could approach this via a joint effort - such as limiting changes to docs/guides/retroachievements.md to ensure it stays in sync with our documentation, by limiting the users allowed to edit it or by requiring that any PR changing that page be reviewed by a staff member of RetroAchievements?

I did update this list of cores back in May 2024 to match what we had, but it seems like some core developers updated the list afterwards and marked their cores as supported even when they were not - which likely stems from the same confusion over "supports RetroAchievements" vs "supported by RetroAchievements", where they could see that the achievement list would load with their cores.

[hizzlekizzle]

it seems like some core developers updated the list afterwards and marked their cores as supported even when they were not - which likely stems from the same confusion over "supports RetroAchievements" vs "supported by RetroAchievements", where they could see that the achievement list would load with their cores.

Yeah, it's exactly that from my/our perspective. That is, the memory exposure that enables monitoring for RetroAchievements could be used for other things, like hooking in speedrun-streaming monitor/timer programs, etc., so I feel like that's important information from a libretro/developer perspective even if it's not adequate for end-user RetroAchievements support.

Perhaps on our end, we need to move away from talking about RetroAchievements, specifically, on this PRed page (and potentially elsewhere where this memory exposure vs RetroAchievements support is concerned, like the "libretro features" matrices on the core pages) beyond just linking to you guys' documentation for that aspect of it, and talk more about cores exposing memory "for activities such as monitoring and awarding (generic) achievements" on our end.

Does that sound more sustainable for you guys? I certainly recognize and respect you guys' concerns about not confusing users and not making more support work for you all.

[Hexadigital]

That would definitely be fine! We don't want to interfere with documenting core features such as exposed memory - but we don't want players getting confused by a difference in what the libretro documentation says supports RetroAchievements versus what we actually support.

How would you like to handle the documentation change? I think that this page should still exist in some format (as it tells players how to enable RetroAchievements), but I wouldn't want to commit a removal of that list if you'd like to reuse it elsewhere. (although you may need to update it significantly, due to the number of cores marked as unsupported that do expose memory)

[hizzlekizzle]

What do you guys think about this? #1088

There are a couple of rogue rewrites in there of unrelated files that you can ignore.

[Hexadigital]

That looks perfect to me, thank you! My only minor nitpick would be on the core pages, maybe changing "Memory Monitoring (achievements)" to "Memory Monitoring (addons and external tools)" or similar?

I'm not sure if they use the same memory exposure that RetroAchievements does, but it might make it clearer that those cores also work with things like star/exit trackers for Mario hacks, speedrun autosplitters, and the Archipelago randomizer (if that is how those interface with libretro cores).

If you'd prefer to leave it as achievements though, we're fine with that - that PR addresses the bulk of the issue and we really appreciate it!

[hizzlekizzle]

np!

I had originally left it as just "memory monitoring" but then changed it to include "achievements" simply because I thought that name might be too obtuse to be helpful, but I did try to de-brand it by making it plain ol' lower-case "achievements" (to make it more of an umbrella term to include trackers/autosplitters, etc.) vs the original "RetroAchievements" and hotlinking the explanatory page.

If that doesn't move the needle, though, we can definitely consider generalizing/distancing it further in the future.

[hizzlekizzle]

Alright, #1092 was merged, so I think we're good to close this one out.

Thanks for the input and good discussion, gang.