Bug: Achievements triggering at the startup of 3-D Battles of World Runner (NES) about ralibretro HOT 15 CLOSED

RetroArch resets the cheevos' condition sets as long as it's expression is true. Then only when it becomes true after being false the cheevo is awarded.

https://github.com/libretro/RetroArch/blob/master/cheevos/cheevos.c#L1630

from ralibretro.

It must be implemented by the code that uses rcheevos. In the case of the RetroAchievements emulators it must be implemented in RA_Integration.

rcheevos has rc_reset_trigger which can be used to accomplish this.

from ralibretro.

Seems like World Runner doesn't initialize the memory. The default memory initialization pattern in RANes is alternating four byte groups of 00000000 and FFFFFFFF. At (roughly) the same point in RALibretro, everything is FFFFFFFF except for those bytes which World Runner has populated.

RANes:

RALibretro (at roughly the same point):

The trigger is relying on a "ResetIf(0x0079) == 0" to prevent false triggers. It seems like that value (stage id) is not yet initialized. Recommend replacing the ResetIf with "> 0 and < 255" (or whatever max stage is) unless a better in-game indicator can be found.

Also note that RALibRetro seems to be doing something funny with the intro:

In RANes, the title scrolls in the from the left. In RALibRetro is scrolls in from the left while scrolling out to the right.

from ralibretro.

I'll make a note of your recommended fix in the tickets

from ralibretro.

Guessing this can be closed, in fact NES memory on real hardware should initialize to all 1s with some random noise, though emulators differ in their initialization behavior, so if a title does not initialize memory in the first few frames developers should take that into account.

from ralibretro.

It would be preferable if we could get consistent behavior across all emulators. Also ff in every address could cause emulation problems with the scrolling title screen as an example above. I'd recommend mirroring what other emulators use or use 55 as it's less like to cause emulation bugs.

from ralibretro.

It's not going to happen; many emulators have configurable boot time behavior, and again, all 1s matches real hardware most closely. It's not an emulation issue.

See https://forums.nesdev.com/viewtopic.php?f=3&t=13199.

If you want FCEUmm to have different RAM initialization behavior, then you should post an issue in the relevant repository (most likely https://github.com/libretro/libretro-fceumm); it is not something that should be changed unilaterally from RALibretro's end anyway, considering doing so would likely cause compatibility issues with most RetroArch cores.

from ralibretro.

@rzumer

NES memory on real hardware should initialize to all 1s with some random noise

I couldn't find a really "trustworthy" post on that thread to confirm this statement. But assuming this is true, it seems that the RALibretro/FCEUmm behavior is the "most correct" one.

Then I wonder if it's a case for a change on RANes (rather than fceumm libretro core).

What do you think?

from ralibretro.

or use 55

This is just what the Snes9x developers picked. There's no rhyme or reason to it. Visual Studio uses 0xCD for uninitialized memory - it's just an easy way to see when some chunk of memory hasn't been written to.

I wonder if it's a case for a change on RANes

We can't assume the uninitialized memory is set to any specific value. That's what "uninitialized" means. I suspect RANes's "00000000 FFFFFFFF" pattern is there for the same reason as the 0x55 and 0xCD described above - to make it more obvious what's not been initialized.

We added the 100 frames delay to get around having to deal with unassigned memory because a lot of people weren't even trying, and there are sometimes subtle differences between emulators (like this) that were causing problems for those that were.

If the game chooses not to initialize a value until a certain point in execution, we can't use that value until then. It's just something to be aware of, and unfortunately, something to deal with.

As the scrolling issue also occurs in RetroArch, it can't be directly associated to RALibRetro.

Since we don't have toolkit integration in RetroArch, I can't confirm the state of the uninitialized memory there, but the initial description above suggests it's not an issue there. The only reason I'd leave this open is if we wanted to make RALibRetro behave the same as RetroArch.

from ralibretro.

@Jamiras

We can't assume the uninitialized memory is set to any specific value. That's what "uninitialized" means.

Yeah, totally agreed here.

Then I guess the "most acceptable" solution is to put this info in the docs (for example in the Tips and Tricks) and then link the tip where it fits.

What do you think?

If it's agreed, this issue should be closed.

from ralibretro.

RetroArch implements an edge trigger for achievements, i.e. it only awards a cheevo when its expression changes from false to true. I believe we didn't have any issues with insta-awards after implementing this.

from ralibretro.

[RetroArch] only awards a cheevo when its expression changes from false to true.

That's an interesting idea, and might be better solution to the 100 frames issue. I'll think about it some more.

Then I guess the "most acceptable" solution is to put this info in the docs (for example in the Tips and Tricks) and then link the tip where it fits.

I'm surprised we don't already have a note somewhere about testing achievements when initially loading the game or when resetting the emulator. That would be the ideal place to put it.

from ralibretro.

The edge trigger would prevent achievements from immediately firing on loading a game, but still might set some HitCounts unexpectedly. I think having the delay is still desirable.

from ralibretro.

RetroArch resets the cheevos' condition sets as long as it's expression is true. Then only when it becomes true after being false the cheevo is awarded.

is this behavior, by chance, reproducible in rcheevos?

from ralibretro.

I'm going to open an issue in RAIntegration with this request and summarizing our discussion here.

Thanks for you input! 👌

from ralibretro.