Emulated local Wi-Fi multiplayer support

[BernardoGomesNegri]

This patch adds support for emulated local (Wi-Fi) multiplayer using libretro's netpacket API, which allows a core to send and receive arbitrary data packets across the network. In RetroArch, this can be done by using the same interface used for netplay.
Unfortunately, due to the DS's tight latency requirements for local networks, it only works for good LAN connections on a few games. I managed to play Pokémon HeartGold between my phone (connected to a WiFi AP very close by) and my PC (wired), for example. On an emulated connection, the same game worked with 8ms ping and 3% packet loss, but it could get rather laggy at times.
Thanks to @JesseTG for helping me with this.

[JesseTG]

Thanks for contributing! I'll review and test this and get back to you as soon as I can.

[BernardoGomesNegri]

I seem to have made a bit of a mess when trying to rebase this to the dev branch. I Will try to fix it.

[BernardoGomesNegri]

Would close issue #225

[JesseTG]

Thanks for your contribution, and for your patience. Broadly speaking this looks okay, but there are some changes I'd like you to make. Some of the proposed changes will reduce the number of copies made of packets, which may help performance.

I also suggest adding Tracy markers at the start of important functions, then running a RelWithDebInfo build through Tracy.

Once you make these changes I'll take another review pass and test it. Keep up the good work!

[BernardoGomesNegri]

Added the tracepoints, will run with Tracy and analyze the result later.

[BernardoGomesNegri]

Ran it with Tracy, it appears that most of the time spent in the multiplayer code is spent waiting blocking for a packet. Sending a packet and receiving one are super quick by comparison.
The biggest improvements I can see are if waiting for a packet did not require busy-looping (which would improve battery usage on mobile devices) and if waiting for a packet could be done asynchronously from actually rendering and processing and everything else that has to be done in a frame.
The only room for improvement in melonDS DS that I see is tweaking the timeout. But even that has little effect: melonDS (or the game) will often call recv again after receiving a timeout.
Maybe improvements could also be made on RetroArch's implementation of netpacket? But I think this is very close to the best that can be done while only touching melonDS DS and with my rather limited knowledge of emulation and networking.

[BernardoGomesNegri]

I've been trying to get Tracy to connect to my Android phone, but no luck so far. Any ideas?
Edit: fixed it.

[BernardoGomesNegri]

After testing more, it seems timeout has little impact on performance. However, too low of a timeout will cause frequent crashes. The value of 25 ms is good.

[JesseTG]

I'll test this today and get back to you with thoughts. I'll also compare this to the upstream implementation, see if there's something we can do about the blocking.

[JesseTG]

Looks like this assertion doesn't hold up; I just triggered it in Mario Kart DS. I created the in-game lobby from one of my devices, but as soon as the second device connected this retro_assert went off.

[BernardoGomesNegri]

Try changing it to len >= HeaderSize. If it works, then zero sized packets are possible.
Interestingly, I was not able to reproduce this.

[BernardoGomesNegri]

Managed to reproduce it, but switching to len >= HeaderSize fixes it.

[JesseTG]

What game did you test it with? I used Mario Kart DS.

[BernardoGomesNegri]

Me too. .nds file format, MD5 hash: 8cbf438d5a7c0d9acbe56a9b627ca6c5
The game indeed crashes if the condition is len > HeaderSize but switching to len >= HeaderSize fixed it for me.

[BernardoGomesNegri]

I initially tested it with Pokémon HeartGold as well.

[JesseTG]

I had a chance to reproduce the lag in the core you described. Notably, standalone melonDS does not have this issue.

Before we can merge this PR, we need to diagnose the lag and see how much of it actually comes from the core. I'll take some traces and get back to you.

[JesseTG]

When you took your trace, what build settings did you use? I built the core (but not RetroArch itself) with optimizations and the lag wasn't as pronounced. I'm still looking over the trace for specifics.

[BernardoGomesNegri]

The traces I took were taken in a RelWithDebInfo build.
The lag might be because right now this PR does not drop stale packets. I did not think it was needed because games often try to get incoming packets more than once per frame.

[JesseTG]

I wonder if upstream melonDS does the same thing? I'll look into it.

[JesseTG]

The lag is far less pronounced when building the core in RelWithDebInfo mode, and RetroArch in Release mode. (For both devices I'm testing with, too.)

Let me see what happens when using a wireless connection.

[JesseTG]

Not too bad over wireless. It looks like on frames where retro_netpacket_poll_receive_t is most responsible for slowdown, it's because it's called more often. Or, rather, Platform::MP_RecvReplies is called more often -- and that leads to retro_netpacket_poll_receive_t being called more.