A gap for achievement processing before loading a ROM about ralibretro HOT 16 CLOSED

The core has complete control over its RAM, we shouldn't write anything to it.

Are you having issues like cheevos being awarded right when the game is loaded? I had to fix a similar issue in RetroArch, but I changed the cheevos code, not the cores. A similar fix to RALibretro would involve changes to RA_Integration.

from ralibretro.

Yeah, that's the exact reason. I will talk with GD about this issue.

from ralibretro.

He told regardless of anything it won't fix this issues in RetroArch. Not sure what to do with this issue now.

from ralibretro.

Sorry, RetroArch? I've fixed this issue there ages ago.

I don't think I can fix this in RALibretro, since all the cheevos checking is done in RA_Integration.

from ralibretro.

@JuliaWolska can you provide examples and how to reproduce them?

from ralibretro.

Having one game loaded and loading another is the same session, epecially between systems.

from ralibretro.

@JuliaWolska can you provide a single and very specific example so I can try to reproduce exactly what happened to you?

from ralibretro.

Is this specific to RALibretro or all emulators?

from ralibretro.

http://retroachievements.org/ticketmanager.php?i=12160 - this ticket could be a good example, it already contained protection for not opening if the game wasn't active, needed to add another for flashing memory, specifically becasue of this issue.

from ralibretro.

http://retroachievements.org/ticketmanager.php?i=12160 - this ticket could be a good example

@JuliaWolska the fix was in the achievement or in the emulator?

In RetroArch I put a guard to only award an achievement when it triggers from false to true. If the achievement is true from the beginning, nothing is awarded. Maybe RA_Integration needs such a guard?

from ralibretro.

Maybe we should move this issue to RAIntegration's issue tracker?

Or maybe tagging some RAIntegration's hackers can be enough: @GameDragon2k (oh, he's already here 😅) and @Jamiras

from ralibretro.

Each system/emulator provides uninitialized memory in different ways. RANes alternates 32-bits of 0x00000000 and 0xFFFFFFFF, RASnes9x initializes everything to 0x55. RAVBA initializes everything to 0. This pre-ROM memory is the leading cause for "triggered at startup" tickets.

Loading a new core should load new memory banks. I have difficulty understanding why changing cores wouldn't provide freshly uninitialized memory (unless the core isn't actually initializing the memory before loading the ROM).

Loading a new ROM within a core might be problematic as the existing memory banks could remain registered. But again, it seems like the core should flush the memory before loading the ROM.

We probably should do something generic in the toolkit - maybe provide a buffer of N frames after a ROM is loaded before achievements start processing?

from ralibretro.

Just like the other emulators, on RALibretro what happens to memory when a game is loaded depends on the core. I call RA_DoAchievementsFrame right after _core.step(), so the core has the chance to do something to its memory, but again what happens in this first emulated frame depends on the particular core.

I can skip the N first calls to RA_DoAchievementsFrame in RALibretro, but if this is also a concern for the other emulators then maybe the fix should be in RA_Integration.

My only concern is that we should not skip frames after a state is loaded, only when the ROM starts being emulated, because if the state was saved right before a cheevo then skipping frames on state load could prevent it from being awarded.

from ralibretro.

My only concern is that we should not skip frames after a state is loaded, only when the ROM starts being emulated, because if the state was saved right before a cheevo then skipping frames on state load could prevent it from being awarded.

This is a good point. I'll implement the required protection for this.

from ralibretro.

@leiradel the fix is in achievement.

from ralibretro.

I believe @GameDragon2k will fix this in RA_integration, so I'm closing this. Feel free to reopen if that's not the case.

from ralibretro.