LAN: almost done!

< Sorry for the downtimeUpdates to the downloads section >

LAN: almost done!
Aug 7th 2024, by Arisotura

Those of you who pay attention to our git repo may have noticed the recent activity in the season3 branch.

The plan was to backport the LAN and netplay features to a recent branch, since the old season2 branch was way outdated. It is over one year old, and a lot of refactoring has happened since then. I figured that backporting them would be easier than trying to get season2 up to date, so that was why season3 was started.

I didn't even realize season2 was that old before I checked. Shows how good my perception of time is, really.

Anyway, the backporting is going smoothly so far. The LAN feature is fully ported, and it seems to be functioning. Also, JesseTG helpfully moved the network interfaces to their own module, so different frontends can reuse them. I based my work on that, and added an interface to switch between multiplayer modes (local, LAN, netplay).

All that is missing is some polish on the UI side. I will take care of the biggest problems, make sure it all works smoothly, and we will merge season3 very quickly.

This will enable you to test LAN multiplayer by simply grabbing our nightly builds (from Github's Actions tab; you need a Github account).

After that, I will tackle netplay in what will be season4. For now, I brought in the netplay related code, but I just commented out a lot of it so melonDS would build. It is nowhere near functional for now, and there is more work with it.

But on the other hand, several of the issues I had encountered during the original implementation are now solved.

For example, my original idea to get multiple instances started with the exact same state was to use the savestate system. Take a snapshot of one instance's state, send it over the network to other instances, which can just apply it and be all set (or so I hope). Sounds easy enough. Except the savestate system was coded to deal with files directly. I had worked around it in a very ugly way, but the issue has since been fixed, the savestate system operates on memory chunks now.

In a similar vein, I had hardcoded the RTC in season2 for testing purposes. Games use the RTC to seed their RNGs, so for netplay to work it is crucial that every side starts with the same RTC time or they will desync. The old RTC would just directly read the system time, so there was no control over it. But the new RTC would let us start with any time just fine. The time counting is also synchronous to the emulator core, so it will not desync during netplay.

And of course, there is the object of the big refactor: multi-instance support. The old netplay system had to deal with multiple separate processes and keep them in sync, which is far from ideal. Say one of the processes crashes, or hangs, how do we deal with such problems? But now, all the required emulator instances can be contained within one process, which makes things a lot easier to deal with.

Now it is mostly matter of reworking the old netplay code to take all this into account. But there are also other things I want to fix. For example, reworking the network protocol to work all on one single port, rather than using several different ports. If port forwarding is required, it would be a net improvement.

There is also some reworking required on the input front, especially touchscreen input. Basically, as of now, melonDS just receives mouse events and feeds them straight to the core. This has the problem that it's not compatible with netplay, because we need to be able to reproduce exactly the same inputs on all sides. A solution would be to set the touchscreen coordinates once per frame, like we do for button input. But this is also not ideal: DS games may sample the touchscreen multiple times per frame for higher precision, and it seems that some games actually need it.

We haven't yet figured out a perfect solution for this. We could have the core query touchscreen inputs whenever the game samples the touchscreen. The problem with this is a timing one: between each frame, melonDS may run way faster than realtime, so this would result in some amount of distortion to touchscreen coordinates over time. An alternative would be to sample touchscreen input during one frame and replay it with the correct timing during the next frame. It would mostly eliminate the distortion problem, but it would add a frame of input lag.

I don't know. It's worth noting that the current touchscreen handling also suffers from the aforementioned time distortion problem. I don't know how much of a problem it actually is, in practice. Touchscreen input just seems to work well enough as far as I know.

Either way, we will keep you informed about all this. Expect a merger of season3 very soon.

5 comments have been posted.

< Sorry for the downtimeUpdates to the downloads section >

Riderman02 says:
Aug 8th 2024

Where is the nightly build

Foxeh says:
Aug 8th 2024

on the subject of the touchscreen inputs, would it be better to have the range of the touch screen already there, so when someone touches an area within the touch screen, all that would be needed is the 2 coordinates of the touch to relay to other people in the network if they need that input?

keisui says:
Aug 9th 2024

momentous

Albanox9 says:
Aug 9th 2024

Gracias por tu trabajo!! Todas estas funciones cuando estarán porteadas en android??

ThiccFurLizzy says:
Aug 9th 2024

Regarding the one frame of delay for touchscreen inputs, it's common for online games to be 1 tick behind, so that the animations and more can be interpolated.

Since games are 60fps, I think having that slight delay is fine, and most people are used to stuff not being instant for online play.