Retroarch: 3DS: abnormal size of save states

[SpardaXV]

Description

I recently updated retroarch in my 3ds from version 1.3.3 to the latest 1.7.7, mainly motivated by the addition of Boxarts in the rgui menu. All the updates of menu rgui work really well in 3ds, with no impact on the emulation and maintaining the same performance as version 1.3.3 / 1.3.6 (which were said to be the most stable in operation), even with some improvements like the filter support in some cores that did not allow it.

However, there is a problem that wasn't present in version 1.3.3: in version 1.7.7, in all cores the saves states take a long time to be done and loaded, and this happens because the saves states have an abnormal size compared to retroarch in other platforms and in previous versions in 3ds, they are too heavy. In 1.3.3, the savestates of the Snes cores occupied around 500 kb and now in 1.7.7 they occupy about 5 MB, in the cores Picodrive / Genesis plus gx the states were around 150 kb and now 1 MB. In my PC with retroarch 1.7.7, the savestates are much lighter than in 3ds, similar to the one described above of 500 kb for the cores of snes and 150 kb for the cores of genesis, so something goes wrong in the operation of the savestates in 3ds.

Expected behavior

Smallest save states size, equaling it with the use of platforms such as pc or snes classic mini and thus recovering the performance they had in previous versions of 3ds.

Actual behavior

Save states are too heavy in all cores (so it must be a problem with retroarch) and consequently, they take a long time to be made and loaded, even in lighter cores like those of nes or gbc.

Steps to reproduce the bug

1. Launch retroarch 3ds 1.7.7 via cia in the main console menu
2. Load one core (for example, snes9x2002).
3. Launch a game.
4. Open the quick menu of retroarch and take a save state.
5. Observe how a huge save state is created (of 5000 kb in the mentioned core of snes9x2002 and that takes 20 seconds or more to be done).
6. Being such heavy states, they also take a long time to load

Bisect Results

In 1.3.3 and 1.3.6 it did not happen in any core, in the current 1.7.7 it happens and I don't know from what version this has been happening, but looking for the forums it seems that the problems of time in creating and loading save states take reporting since 2017, around the release of versions 1.4.0 and 1.6.0.

In the early days of the hack of snes classic mini it seems that similar problems were reported with retroarch, apparently, cluster solved these problems in its version of retroarch 1.0c, in these commits https://github.com/ClusterM/retroarch-clover/compare/1.0c...master, in the file retroarch.hmod/bin/retroarch-clover-child, but it seems that there is talk about compression of screenshots and I do not know if those changes would help solve the problem in 3ds.

I think the problem may be related to the time when the rewind function was added, but having the rewind turned off and even lowering the buffer to the minimum (in case it could still affect even if it is off) does not change the size of the states.

Version/Commit

• RetroArch: 1.7.7

Environment information

• OS: 3ds in cia format (I think that the version of cfw and firmware of the console is irrelevant for this question)

Thanks to the whole community of retroarch developers, little by little, retroarch has become the most complete platform for lovers of retro. And for 3ds, although it has been said that the development was abandoned, I have observed how the new changes work very well and make the 3ds a good portable emulation machine, with the boxarts and if the states are fixed, the experience in 8 and 16 bits will be almost perfect.

[twinaphex]

Hi there, thanks for the kind words.

3DS has not been abandoned. Instead, it has seen a resurgence in interest thanks to the efforts of @jdgleaver . On that same note, I'll let him respond to the question you have about the 3DS port.

[SpardaXV]

update: I made a partial but important error that may indicate that it is actually a problem related to specific cores. In PC with retroarch 1.7.7, in cores such as snes9x2002 and Genesis plus GX the save states are also very heavy as in 3ds (but of course, in PC is not a problem). However, installing again the retroarch 3ds 1.3.3, I can confirm that the save states of Pocketsnes (later snes9x2002), Genesis plus GX (and all the rest of cores) don't exceed in any case of the 500 kb and were performed and loaded around 1 second, therefore, regression in the states remains a reality

[jdgleaver]

@SpardaXV Thanks for bringing this to our attention! I know snes9x2002 is very slow at saving/loading states, but I never used RetroArch on 3DS back in the v1.3.3 days, and so never realised that this was a regression.

This is definitely a core issue. I've just checked snes9x2002, and there seems to be an obvious bug that sets the save state size to a constant 5MB. I'll try to fix this, then I'll take a look at Genesis Plus GX.

Other cores seem to be OK (Picodrive for example seems to create Genesis save states of ~150kb, which I believe is quite normal)

[jdgleaver]

@SpardaXV This fixes snes9x2002: https://github.com/libretro/snes9x2002/pull/34

I'll have a look at Genesis Plus GX later :)

[jdgleaver]

Ah, just checked Genesis Plus GX, and the save state size has always been 1012kb (this was set 7 years ago!).

This is clearly too large in most cases (e.g. master system/game gear don't need this), but to modify the existing behaviour would require some deep changes to the code. Since Genesis Plus GX is actively developed upstream, I would suggest opening an issue at the official repo: https://github.com/ekeeke/Genesis-Plus-GX

[SpardaXV]

Great job @jdgleaver !!, thanks for the fix and clarifications. It is true, in the rest of cores the operation is normal, what has confused me is that in the old versions of retroach 3ds, when a save state was made or loaded, it closed the menu automatically and returned you to the game.

It's a question of tastes, but if it's easy to add, could a change be made so that when making or loading a state it is returned to the game? I think it's more comfortable because that way you don't have to look at the bottom screen log to see when the operation was done.

[jdgleaver]

I originally changed the save state behaviour on 3DS (i.e. remain in menu) because the device doesn't have thread support - so saving/loading a state while a game is running takes ages and causes significant lag (and sound distortion).

But yes, the way I implemented it was a 'quick fix' just before the 1.7.7 release - it absolutely should be a user-configurable option, and making it such has been on my TODO list for a while now!

A have a few things to finish up first, but I certainly will add the option to automatically close the menu when using save states. Not sure if I'll get around to it this week, but it should get done by Monday/Tuesday next week at the latest :)

[SpardaXV]

I see, you have everything under control, thanks for the effort, @jdgleaver. I think this issue can be closed.

I have found another regression in the FBA 2012 Neo Geo core, but it has nothing to do with this, it is in the load of heavy roms, I will open in the core page the issue when I have done enough tests.

[jdgleaver]

@SpardaXV Just for info, this PR adds the option to automatically close the menu when using save states on 3DS: https://github.com/libretro/RetroArch/pull/9064