libretro / libretro-cap32

caprice32 4.2.0 libretro
21 stars 34 forks source link

[proposal] achievements #108

Closed DSkywalk closed 2 years ago

DSkywalk commented 2 years ago

I thought it would be nice to have achievements for the CPC, although it's not something that only depends on us, I'm going to try to propose it in RetroAchievements and I'm going to offer myself as developer of the first achievements to see if we can get it also for the CPC!

A few years ago I made a small achievement system and I still have the memory positions to implement those achievements in retroarch. I could use them for a first version. imagen

I think it could be really cool :) Ps. Hello Ryudo! :octopus:

Vweber73 commented 2 years ago

Hi, It could certainly be cool ! But... Could it be after keyboard transparency and visual/haptic feedback ? ;) Many thanks and cheers

DSkywalk commented 2 years ago

@Vweber73 HAHAHAH I'll try, don't worry, I'll keep it in mind ;-)

Vweber73 commented 2 years ago

Many thanks ! :)

Cheers

Le mer. 2 févr. 2022 à 22:02, David Skywalker @.***> a écrit :

@Vweber73 https://github.com/Vweber73 HAHAHAH I'll try, don't worry, I'll keep it in mind ;-)

— Reply to this email directly, view it on GitHub https://github.com/libretro/libretro-cap32/issues/108#issuecomment-1028354640, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWBK3J7ESIBVZXNBY2BDNXLUZGLVVANCNFSM5NMUPCJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

Jamiras commented 2 years ago

There's basically four requirements for a core to support achievements: 1) The memory needs to be exposed in a manner that can be mapped from the RetroAchievements code.

Additionally, the core must work in our development frontend (RALibretro) which has all the tools for developing the achievements. This may require frontend changes if we don't implement one or more of the libretro environment callbacks needed by the core.

Save state support is recommended (but not required) as it makes creating and debugging achievements much easier.

Assuming all of that is in place, RetroAchievements will need to update the rcheevos library to specify the hashing algorithm for identifying the games (whole file hash will probably work for CPC), and to define an expected memory map to best support other possibly compatible cores in the future. That will then need to be incorporated into RetroArch and RAlibretro.

DSkywalk commented 2 years ago

Perfect!! this weekend I'm going to look at the SRAM part, although the core right now doesn't allow to "corrupt" a disk, in the future it would be nice to support save games (although very few programs would use it).

I have a doubt, because being a computer, if you deactivate the autorun you could write a POKE before running the game... Is there any way to know from the core that the achievements are active so you can't disable the autorun?

Thanks a lot! :+1:

DSkywalk commented 2 years ago

To recap your points:

  1. done
  2. Not currently applicable.
  3. Nope cheats in core. My goal has always been to have the original computer as pure as possible.
  4. That can happen as I said, but if I have a way to know if there are active achievements, I can force the autorun to always be active and while the autorun is active you can't write or change anything.

Televandalist has mentioned that he is going to re-test the core, because the info that was there might be outdated. I think it should work without a problem :100:

Save State are perfectly working :+1:

Thanks again @Jamiras :smile:

Jamiras commented 2 years ago

I have a doubt, because being a computer, if you deactivate the autorun you could write a POKE before running the game... Is there any way to know from the core that the achievements are active so you can't disable the autorun?

No. There's no communication from the frontend to the core in this regard.

I don't think a POKE before the game is loaded will cause much damage as the game should override the modified memory as it loads/runs.

DSkywalk commented 2 years ago

Ummmf, in practice it would be very simple to use a loader like they used to use in the 90s to load the game and then poke memory positions to give you an advantage. With a bit of effort you can do it with a couple of lines of basic you could do it...

And if the user disables the autorun function what if ... I call RETRO_ENVIRONMENT_SET_SUPPORT_ACHIEVEMENTS to disable it :?

Or we can implement a new call to environ_cb to collect the current cheevos state. It's not very complicated to do :+1:

Jamiras commented 2 years ago

And if the user disables the autorun function what if ... I call RETRO_ENVIRONMENT_SET_SUPPORT_ACHIEVEMENTS to disable it :?

If it's a setting, we can just disallow hardcore when it's enabled (see #3) above.

...they must be tied to a config setting so we can enforce that they're set to default values for hardcore mode.

DSkywalk commented 2 years ago

Perfect! how should I flag that option in the config so that it has to be enabled if you play on hardcore?

Jamiras commented 2 years ago

RETRO_ENVIRONMENT_SET_SUPPORT_ACHIEVEMENTS is only referenced when the user first loads content. If set to false at that point, we don't try to identify it. It's a way for the core to explicitly say it doesn't support achievements. The default is true, and as far as I know, the only core that explicitly sets it to false is only used for playing music CDs.

Jamiras commented 2 years ago

Perfect! how should I flag that option in the config so that it has to be enabled if you play on hardcore?

Just document the setting and the required (or disallowed) values and we'll add them to the white/black lists in rcheevos.

DSkywalk commented 2 years ago

@Jamiras reported:

A couple of issues that will need to be corrected.
1) Resetting the core does not auto-run the game, even with cap32_autorun enabled.
2) Loading a state "detaches" the registered memory (it no longer updates, and sometimes crashes the emulator). I suspect the load state code is allocating a new block of memory. If that cannot be avoided, you may need to call RETRO_ENVIRONMENT_SET_MEMORY_MAPS to tell the emulator to refresh the memory map.

fixed after https://github.com/libretro/libretro-cap32/commit/46a77ab30bde04a3555731878dfa68733f7d3040