Transferred .state files do not load on new machine

Manguy888

Hello

I have a working Retropie 4.7.1 on a RPI3B+ that I have been using successfully for a long time. I have modified it so that all of the srm and save state files go to a single folder called SAVES. This has worked great.

I recently built a PI zero-W and loaded it into a Retroflag GPI case. I also set up the SAVES directory and it also works fine as a central location for srm and state files.

I copied all the srm and state files from my older RPI3 to the new Pi0W under the same SAVES directory.

The SRM files work fine- I can open a game on my new Pi-zero and see my "battery backup" saves of games. HOWEVER, the .state files don't work. When I use hotkey+L to load, the game either does nothing, or it restarts.

Note that if I make a new save state with Hot key+R, this new save state stores in the right location and can be loaded. It is only the save states transferred from my older system that do not work.

Can anyone help me with this?

mitu

.state files are not always portable between emulator versions.
Does this issue happen for all emulation cores or just for some of them ?

Manguy888

@mitu thanks for that detail, I didn't know that.
I did some more research which confirms what you said

Sega - both of my Pi's use picodrive and I just noticed that these states DO work on both

NES - the Pi's use different emulators, and when I try to load a save state on the Pi0 nothing happens

SNES - the Pi's use different emulators, and when I try to load a save state on the Pi0 the game restarts

I feel like I understand this pretty well now, but it's too bad since i was going to try to sync my states across devices but it looks like that isn't possible if I'm mixing and matching emulators.

Really appreciate the help

mitu

Hm, save states are not portable also between emulators, so as a starting point you should use the same emulators when testing.

But since you're using a Pi 0, the same emulator from the Pi3 may not be available or perform well enough to be a viable alternative on a lower spec system.