Savestates in Pokemon Emerald producing inconsistent results

[BafflingAmoeba]

Summary

(Apologies in advanced if anything here isn't clear, I literally had to ask TiKevin how to raise an issue on here because I've never done anything like this before!) Re-producing the same inputs after a soft reset in Pokemon Emerald, and from a savestate made after that soft reset, produces different results (and both results seem inconsistent to real console but I'm not able to verify that for sure). Results seem consistent from the soft-reset (even though I load a savestate before doing the soft-reset), and only inconsistent from the savestate set afterwards. The same savestate can also give different results, though I haven't shown that in the video linked below.

Repro

(see video below for reference)

1. Soft reset after a save, walk/run/menu as per video below
2. Load savestate made towards the end of that movement (savestate made previously) and repeat inputs.

Output

See video: https://www.youtube.com/watch?v=Ustkju4sSxU

Host env.

• BizHawk 2.4 & 2.4.2, Win7, AMD

[nattthebear]

Can you reproduce this on mGBA standalone?

[RetroEdit]

Uh, if it's a variation in how TAS inputs playback, I'm not sure it's directly reproducible in mGBA standalone. That said, it may be possible to export the savestates and open them in mGBA standalone to get closer to diagnosing the problem.

[Liger0]

I tried this and I have totally consistent results on emerald jap, there is nothing wrong with save states. If I save state in the walk in-between 2 grass patches, the save state will always trigger an ancounter which will make the same pokemon appear. Also, if I save state and load it while pressing a direction, I always have the same encounter after the same amount of grass patches.

[BafflingAmoeba]

I could probably do the same inputs on mgba standalone to test this, but it would take a while to do most likely because I'm not familiar with it (and would take a lot of counting frames if there's no on screen frame count etc lol).

Liger, the inconsistency is with the catch result (different number of shakes), not the encounter. I get the same encounter in both attempts in the video, the rng desyncs once in the battle.

[Liger0]

The catch result also is consistent to me if I catch at the same frame when already in the pocket in the ball, launching at the same frame. The result changes entering the bag at a different frame, even launching the ball at the same frame, which I can't explain. Maybe when you enter the bag the seed advances differently? Because it should advance faster when fighting than it would be in the map, so when entering the bag it may advance slower again like it would do in the map, I am unsure. I tested and my theory is confirmed. The capture result depends on both the frame where you hit "bag" to enter it and the frame when you launch the ball. what you do in the bag doesn't influence the result, only those 2 frames matter, to have the same result you must have the same delay from the bag opening and the ball being launched.

[Liger0]

About comparison to real hardware, you can't really compare pokemon to real hardware, because its pokemon encounter rng entirely relies on cycle accuracy, and mgba emulation doesn't have cycle accuracy as its main focus. So the encounter produced via mgba (core), although possible on the real hardware, will have a different percentage of happening, and they will be triggered by different actions than they would be on the real hardware

[BafflingAmoeba]

We have reproduced these manips on real hardware though, and provided I run my macro from a soft reset, the results are consistent with both each other and with console. The only time there's an issue is when I use/load a savestate that then doesn't soft reset. It's not that "I don't get this exact encounter/catch at this exact point", but that "specifically loading a savestate interrupts/breaks/desyncs the rng from what would occur if I played from a reset". "...will have a different percentage of happening, and they will be triggered by different actions than they would be on the real hardware" this is definitely not true at least for this specific scenario, as we can chain together encounters and catches (abra into catch into tailow encounters into catch) and they are reproduceable on bizhawk(mgba core) and console.

I can record some more examples if it helps, but the video linked shows I get different rng values just from the savestate. Are savestates related to the mgba core though, because it could be mgba that's causing the issue in that regard.

[Liger0]

"...will have a different percentage of happening, and they will be triggered by different actions than they would be on the real hardware" this is definitely not true at least for this specific scenario, as we can chain together encounters and catches (abra into catch into tailow encounters into catch) and they are reproduceable on bizhawk(mgba core) and console.

While they use the same encounter, the rng can generate the pokemon by three different methods. Those methods generate the spread the pokemon will have. Normally, the second method is used, but the other 2 can happen. The frequency those 3 methods are used depend on cycle accuracy, which is not the focus of mgba, so the 3 methods will be encountered differently between mgba (core) and a real hardware some unpredictable times, by doing every singular action (ANY action) at every precise frame, with the same save, so with the npc in the exact position in every frame, basically being in the same reality, which is nearly impossible, unless you do it on real hardware and emulator at the same time, with the real hardware having the possibility to pause and frame advance while maintaining the same clock, etc and catching hundreds of pokemon in vastly different conditions. This is why I considered higan, although the results of mgba are not impossible on a real hardware, which makes it hard to see which one is closer to real hardware and of how much, and makes this overall not a practical issue but more of a theorical point.

Anyway, I couldn't replicate your issue as I am interested in this and willing to test, so please make it clearer with some example.

[RetroEdit]

The frequency those 3 methods are used depend on cycle accuracy, which is not the focus of mgba, so the 3 methods will be encountered differently between mgba (core) and a real hardware some unpredictable times, by doing every singular action (ANY action) at every precise frame

I'd like a source for this claim that it requires cycle-accurate emulation. It may be the case that mGBA's timing needs to be more refined, but that doesn't necessarily mean it won't be possible to emulate the timing accurate enough to match the possibilities for real hardware. What is the mechanism here that leads you to say this?

Because mGBA is not just throwing timing to the wind, it's just doing the actions for each CPU instruction in a slightly different order than a real-console would. Actions should occur around the same time as on real-console, unless there's a mid-instruction interrupt in certain cases. If there's an issue, I would first consider that mGBA's timing is just imperfect for some other reason, and it's not a fundamental architectural one.

[Liger0]

I'm unsure, accurate timings may be enough. Over the last 2 decades there were a lot of researches and threads I read that talked about both cycle and timing accuracy. If it's of any help, the function that causes this difference between real hardware and emulator is the vblank, which I guess is well known, and described here generally or there So far I've noticed a good margin of difference in how much each method is generated between my console and mgba 0.8.1, similarly to other old vba emulators.

[YoshiRulz]

Our mGBA is 154 commits ahead of 0.8.1.

[Liger0]

Either way, there is no way to tell if the core is precise enough by bare game testing, this would require someone with the right skills that knows how the pokemon rng works and the emulator to check manually if and how well mgba handles it compared to real hardware.

But this alone is not the topic for this issue, which is an unrelated different one as he said it's not related to the pokemon encounter but rather something that is still not clear.

[endrift]

It's perfectly clear to me what he said the issue is. You can stop bickering, please.

[endrift]

I am unable to reproduce this with interim build https://ci.appveyor.com/api/buildjobs/u416f1bkyfohemfs/artifacts/BizHawk_Developer-2020-06-15-043700-%23a7e2d95676699b37eea1358e0f99f3c4b3bfe2c8.zip

[RetroEdit]

Unfortunately, I don't see any further productive discussion coming out of this; two people (one of them being the developer of mGBA herself) tried and failed to reproduce this issue. There are already a few known problems with mGBA's savestates in 2.4.2 (namely, #1593, though that's probably not the culprit here).

I am closing this with the assumption this issue has probably been fixed since 2.4.2.

If this issue is still present, it would be useful to have a movie and savestate for testing. That would make it much more convenient to investigate the problem.