Retro Achievements support

[SRC267]

Nice to see the Neo Geo being separated away from Arcade MAME and using the .NEO game format. I understand the aim for the JGE emus is simplicity and stability. The only enhancement I feel that would be valid for this core is RetroAchievements support. It's early days for this port, hopefully it's something we'll see at some point.

[carmiker]

I included functions in the core to access any raw memory block, so it is already possible, theoretically. I just don't know anything about RetroAchievements, so I don't know how to hook it all up.

[SRC267]

I had a quick look at the RA website and their repo and found the documents page it contains a RAwiki + RAdocs. It contains all the information. Might be worth looking into when you have any spare time.

Developer docs

[gouchi]

@Jamiras might give you some input.

[Jamiras]

Most of the information is here: https://docs.retroachievements.org/libretro-core-support/
We've recently added a clause about reset support as we assumed all cores already implemented it, but were wrong.

The "arcade" system is a unique beast as we only use the filename for identification, assuming the core will have it's own internal checksum logic for the individual files in the zip. Additionally, since it's not a single system, we rely on the core exposing the memory in a consistent manner between versions. Because of that limitation, many sets have been developed using memory layout as exposed by the FBNeo (previously FBAlpha) core. For compatibility with existing sets, you should look at their implementation.

[spaceage64]

@Jamiras why the decision to put this under “Arcade”? NeoGeo CD has its own entry on RA. Geolith takes .neo files, the contents of which could easily be hashed for identification. Why sticking with this burdensome filename system? There are nice standardized sets to be found that would cause little confusion for people. And besides, you’d actually know you’re working with the proper files regardless of what someone might have named them. Worst case hashes could be translated to “file names” so that both would work in a way. Though, again, should such a system of working with file names not be abandoned at some point anyway?

Would this not seem a great opportunity to for proper NeoGeo implementation on RA’s side? Forgive me if you’re not the right person to address this with but I found this page wanting to request RA support myself and thought I should share some ideas.

[carmiker]

Achievements are in a semi-working state now. There are some challenges:

• Geolith uses emulated system byte order for the memory blocks in question, so the solution was to create a shadow of the main RAM, byteswapped, which gets updated every frame. It would be better if we could instruct frontends to ^1 the address for these blocks, but that is another rabbit hole.
• Neo Geo is both an arcade platform and a console platform. Existing achievements are under "arcade". The frontend needs to know .neo is "arcade", so for now, only https://github.com/codingncaffeine/Emutastic works. There is a PR to resolve this: hash: content-hash .neo (Geolith Neo Geo cart) files RetroAchievements/rcheevos#517
• CD systems need a bit more research to do properly.

[carmiker]

I am pretty confident that CD achievements work now. I've managed to get a few achievements after using RETRO_MEMDESC_BIGENDIAN in the retro_memory_descriptors. The same solution might be useful for the cartridge system achievements once the filename vs hash thing is figured out.

[carmiker]

There has been some work done on the RetroAchievements side to add .neo hashes to their database, and the previously mentioned PR with support for hashing .neo files has also been merged. Once the latest commits from rcheevos land in RetroArch, achievements for cartridge-based games should work.