Retroachievements rcheevos integration

[LillyJadeKatrin]

This is the first portion of an integration with the RetroAchievements tools and libraries for connecting to the website, downloading data, unlocking achievements and submitting to leaderboards for games running in Dolphin. In this PR, a connection is created to RetroAchievements and the player is logged in, though nothing else, for the sake of keeping this PR manageable. The new functionality is turned on via the USE_RETRO_ACHIEVEMENTS compile-time parameter (-DUSE_RETRO_ACHIEVEMENTS).

Logins are performed with a username and an API token as stored in the new Achievements.ini in the Dolphin config folder. RetroAchievements advises against storing passwords in plaintext config files so an API token is generated upon first login; this token is safe to store in configurations for later use. In its current state, this API token must be generated elsewhere, as there is not yet any user interface for providing a password, though the token should remain constant for a player no matter which emulator is used until the player resets it on the RetroAchievements website.

[shuffle2]

Personally, I'd rather if this did not add another compile-time feature macro (what is the reason?).

[AdmiralCurtiss]

Personally, I'd rather if this did not add another compile-time feature macro (what is the reason?).

Why, for the record? I get that having mode configuration combinations makes it harder to ensure all of them work as expected, but this kinda feature seems like a prime thing you want to have the core emulator buildable without; similar to say the Discord integration, where you're relying on an external service that may stop working at any time. At the very least, having a compile-time flag enforces that the feature doesn't end up closely coupled with the emulator itself.

[LillyJadeKatrin]

Personally, I'd rather if this did not add another compile-time feature macro (what is the reason?).

At bare minimum I need this to exist for the first several PRs until I have enough of RetroAchievements' integration merged in to be properly functional - as long as it's incomplete, it should be able to be turned off. Past that, I'm inclined to agree with Curtiss on this one, but that's up to Dolphin's staff.

[shuffle2]

Personally, I'd rather if this did not add another compile-time feature macro (what is the reason?).

Why, for the record? I get that having mode configuration combinations makes it harder to ensure all of them work as expected, but this kinda feature seems like a prime thing you want to have the core emulator buildable without; similar to say the Discord integration, where you're relying on an external service that may stop working at any time. At the very least, having a compile-time flag enforces that the feature doesn't end up closely coupled with the emulator itself.

I think discord also shouldn't be a compile-time option. Both should be optional at runtime. I don't really see why you'd want to deal with having different flavors of builds which may or may not support the feature.

[Pokechu22]

Both discord and rcheevos have external libraries that you might want to exclude from the build. IMO it's reasonable to have a compile-time flag to exclude them. If it were entirely within dolphin code then forgoing a compile-time flag for only a runtime flag would make sense, but with an external library I think it makes more sense to have both.

[shuffle2]

In practice, discord is always compile-time enabled. In fact, disabling discord at compile time was broken for a while until recently and no one had noticed.

IMO having compile-time AND runtime enablement does not make sense for a feature. The only reason something should be compile-time optional is if certain platforms cannot support the feature at all (i.e. can not even link against some dynamic library or whatever).

[JosJuice]

The only reason something should be compile-time optional is if certain platforms cannot support the feature at all (i.e. can not even link against some dynamic library or whatever).

For what it's worth, this is the case for Discord on Android.

[shuffle2]

The only reason something should be compile-time optional is if certain platforms cannot support the feature at all (i.e. can not even link against some dynamic library or whatever).

For what it's worth, this is the case for Discord on Android.

OK, I guess that's a decent enough reason ( :( ). It would be nice if #ifdefs could be limited if possible, though.

fwiw if Android was compiling OK all that time...it means Android build was silently accepting this undefined behavior?
Although in practice it wouldn't have been called...just an example of over-use of #ifdefs...

[LillyJadeKatrin]

Memo: Make sure the rcheevos submodule is pointing at the most recent version in master.

[delroth]

I'm still not particularly convinced about the internals design of the AchievementsManager but we can iterate on that if problems arise. LGTM.

[Danyelalejandro]

You don't know how much we love you in the RA community @LillyJadeKatrin. Infinite thanks!!!