Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retro Achievements support #2

Open
SRC267 opened this issue Mar 11, 2024 · 5 comments
Open

Retro Achievements support #2

SRC267 opened this issue Mar 11, 2024 · 5 comments

Comments

@SRC267
Copy link

SRC267 commented Mar 11, 2024

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
Copy link
Collaborator

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
Copy link
Author

SRC267 commented Mar 11, 2024

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
Copy link
Member

gouchi commented Mar 16, 2024

@Jamiras might give you some input.

@Jamiras
Copy link

Jamiras commented Mar 17, 2024

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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants