< melonDS 0.9 is out!The DSi camera adventure >
Sorry for the silence lately
Oct 11th 2020, by Arisotura
I know that since the 0.9 release, there hasn't been a lot of progress. On my side, things have been pretty rough, especially regarding depression. Under these circumstances, it's good to take a break.

Anyway, what can we attempt doing, at this point?

Besides dealing with the pull requests and issue reports?

One thing I was working on lately was DSi camera support, but I didn't get too far. I'm going to need hardware tests to figure out how the camera hardware works. Considering the lenghty initialization procedure for those, it's not quite something I look forward to. So I'll post more about this when I get further into it.

I have ideas for the OpenGL renderer, namely, a better method for rendering quads. It would need more work for an implementation though, but might be worth it.

But, one of my main concerns is about wifi, especially local multiplayer.

At this point, melonDS is mainly known as 'the wifi emulator'. It's a bit sad that, 3 years after we got it working, we're still telling people to disable their framerate limiter and pray. We can probably do better.

It's not like we haven't tried, though. You might have seen that branch named 'betterer_wifi' in the repo. I was hoping to run the wifi with more stable timing, but it was a trainwreck, it performed even worse than our current method.

The main issue with local multiplayer is that it requires tight synchronization to function. You might remember how finicky it was back in the old days, you would start lagging and disconnecting as soon as your friend was more than 10m away from you. Long story short, the protocol works by having the host repeatedly poll its clients, multiple times per frame, and each client is given a narrow window to respond (the time given is barely greater than what it takes to transfer the response frame).

On melonDS, things are even worse as it's difficult to tell whether wifi issues arise from bad emulation of the wifi hardware, or from transmit errors, or both. We use BSD sockets as a means of transmitting frames, which inherently adds some lag. The way melonDS runs is also problematic in that it's just running as fast as possible, which can result in the wifi system running faster than it should. The throttling mechanisms, be it audio sync or framerate limiter, only kick in every once in a while, so they only make things worse at the scale of wifi operation.

So, for local multiplayer to function correctly, we would need to overhaul it. Basically, synchronize things tightly based on multiplayer frame exchanges. How to do so without ruining performance, good question.

One possibility I thought of would be running multiple DSes inside one melonDS instance, akin to NO$GBA. However this would require quite some refactoring, as the melonDS codebase was built around the assumption that it would only ever emulate one system per instance.

The other possibility is, well, reworking how we do the whole IPC. Figuring out a fast way to do IPC (we're talking about microsecond-order timings). Synchronizing melonDS instances tightly. And so on.

Welp. Time will tell how this goes, I guess.
48 comments have been posted.
< melonDS 0.9 is out!The DSi camera adventure >
AshleyGee says:
Nov 29th 2020
Please add fullscreen support for this wonderful emulator :)
gaker19 says:
Feb 29th 2024
I've noticed the game dropping frames when connected to another melonDS client. Is this due to mentioned synchronization?
Arisotura says:
Mar 2nd 2024
yup, local multiplayer needs pretty tight sync
Pages:1234
Post a comment
Name:
DO NOT TOUCH