[Save State] Rollback optimizations for btoads

[ghost]

I don't actually have or play this game; I am forwarding this on behalf of a streamer that doesn't know how to use GitHub.

• Reported slowdowns with RetroArch's netplay (Windows 11 / 1.10.3 stable).
• Save state size on disk was reported to be 3.6 MBs, quite large for a 1994 2D arcade game.

With libretro now supporting savestate contexts, how viable is it to optimize this game's savestate for rollback use?

[barbudreadmon]

Save state size on disk was reported to be 3.6 MBs, quite large for a 1994 2D arcade game.

3MBs are for the video rams, and i'm not convinced any of them can be optionally saved but i'll investigate.

[barbudreadmon]

Also, are you sure it's about bandwidth ? That machine's emulation is quite demanding.

[ghost]

I cannot provide fully accurate reports because as I've said before, I don't have this game. All information comes from my own observation of his livestream.

By running netplay without connected clients, the game appeared to be running normally; netplay still serializes at every frame, even when there is no client: https://github.com/libretro/RetroArch/blob/a878bd3f957400936702439fa937bf5aed85e76b/network/netplay/netplay_frontend.c#L3568-L3610

At 3 players (host + 2 clients), slowdowns and sound desyncs were observed. These 2 clients played with him before and after btoads without issues.

The following is a list of other possible causes (involves savestates):

• Clients also serialize at every frame; if their emulation becomes too slow, the host stalls in order for all clients to catch up (all 3 players were on Windows, seems unlikely that they wouldn't be able to serialize at every frame).
• The host compresses the savestate before sending; this can be a lengthy process if the size is too big and savestates are requested often (desyncs is a common cause).
• Algorithm can rollback the host often once clients are connected to it (bad input simulations is a common cause).
• Probably some other stuff that I can't remember right now.

Copying 3.6 MB every frame can be quite demanding, even when both source and destination are RAM. Sending this through the network with crappy upload speeds can be a problem too, even when compressed.

If this can't be optimized, perhaps I should start recommending 2-players mode only for this game when netplaying. Either way, I don't have a horse in this race and I am just reporting this as most people can't be bothered to do the same.

[barbudreadmon]

Again that machine's emulation is quite demanding, it'd had been nice to know what their cpus were and/or if the cpu core running the emulator was at 100%.

I'd certainly expect a cpu with a relatively low single thread passmark (let's say below 1800) to struggle if it had to replay the same frame multiple times, which i suppose will happen if it had to rollback (?).

From my investigation, nothing seems very safe to substract from this serialization, i'll ask other devs for their advice.

[ghost]

I don't know the host's CPU, but since he is running on Windows 11 (desktop), which requires TPM, it's unlikely for it to be much old; don't know about the clients themselves other than their OS (Windows, version is unknown). If I see him again, I'll ask him to test it with me on 2-players mode.

Netplay rewind for input is indeed an expensive algorithm as mentioned in point 3. Like runahead, we don't render frames nor play audio samples during this period, but unlike runahead, we don't tell the core that. This is the rewind code: https://github.com/libretro/RetroArch/blob/master/network/netplay/netplay_frontend.c#L3806-L3869 This is how we skip rendering these frames: https://github.com/libretro/RetroArch/blob/master/network/netplay/netplay_frontend.c#L3806-L3869 and https://github.com/libretro/RetroArch/blob/master/network/netplay/netplay_frontend.c#L7874-L7909

If you've any suggestions for optimizations there that could make this game run better, let me know.

EDIT: Host's CPU was an i7-3770.

[ghost]

We did a full run of the game (I am on a i7-4770k oc'ed to 4.3 GHz). We went through about 50% of the game with just 2 players and then a third one joined; even with 3 players, the game remained stable. It did fail to predict input many times through the session, opening the diagnostics menu often (had to set the diagnostics key to None) followed by a rollback at "check frames".

I am curious as to why this game needed such a powerful board back then. 3 MBs of video RAM was quite above average for 1994 (not even the PSX, which released by the end of that year, had that much VRAM). The game is also nothing special when compared to similar games of its time and it's very short too. Any idea why RARE went with it?

EDIT: Host upload speed was ~30 mbps.

[barbudreadmon]

I am curious as to why this game needed such a powerful board back then. 3 MBs of video RAM was quite above average for 1994 (not even the PSX, which released by the end of that year, had that much VRAM). The game is also nothing special when compared to similar games of its time and it's very short too. Any idea why RARE went with it?

That's a good question whose answer i don't know, maybe @dinkc64 know something about it since he worked on this driver ?

[dinkc64]

I can only guess, RARE wanted to make an awesome 2d game, and probably the team working on it were familiar with the tms34020? Battletoads is a 2d game which uses several layers of bitmapped graphics, running at a resolution of 512x224 PSX uses lists of polygons + some(?) mem. for texture to generate it's graphics. I don't know much about the psx, though.

[ghost]

Just some correction on my part; we DO TELL the core that we don't need audio nor video when replaying frames for the real input: https://github.com/libretro/RetroArch/blob/master/runloop.c#L3018-L3021

With that being said, I don't think there is anything that can be optimized on RetroArch's side to make this one game run better other than refactor the whole netplay model, which is not going to happen. If there are possible optimizations that can lower the CPU, RAM (we need 124 savestate size for the host, 62 savestate size for the client, 2 (2 savestate size + 960) for the network buffers of each client connection and 2 * savestate size for the compression/decompression buffer) and bandwidth requirements, it would be really appreciated.

[dinkc64]

Unfortunately there's really nothing we can do for this one that won't end up breaking the game.

[ghost]

Alright, I'll close the issue then.

Thanks for confirming this game won't netplay well on weaker devices and there is nothing else we can do at the frontend and the core.