Sorry for the silence lately
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.
KostaSaizo7 says:
Oct 11th 2020
So glad you are tackling local multiplayer emulation. A quote from the 2nd ever post on this blog, dated Jan 17th 2017: "The holy grail would be wifi emulation, especially local multiplayer, which I could never get working in DeSmuME. Time will tell if that goal is achievable." So I can't think of a better feature for the 1.0 release.
Masky says:
Oct 11th 2020
༼ つ ◕_◕ ༽つ Arisotura TAKE MY ENERGY ༼ つ ◕_◕ ༽つ
Tina says:
Oct 11th 2020
Love you girl, you are the best! Take care of yourself and don't let the bad energy put you down.
You have a badass emulator and I like it very much.

Pink love and good health to you <3
Generic aka RSDuck says:
Oct 11th 2020
I want to add my thoughts on this because I recently made some experiments on this topic. The basic setup was this: there was some kind of coordinator program to which melonDS instances (for my tests it was hardcoded to exactly two melonDS instances) connect to. The coordinator would make sure the emulation advances in both instances somewhat uniformly.

I tried a few different variations (both instances are allowed to run at the same time, they explicitly change turns, ...). In the end the results where a bit underwhelming. While running with a framelimiter enabled gave better results than before, they still fell behind disabling the framelimiter and the lock stepping entirely. Surprisingly making the synchronisation tighter lead to even worse results.

Then I noticed Arisotura set the socket receive with a timeout in some situations. Of course this timout wouldn't work well with this technique, I thought! Though neither removing it nor my attempts at replacing it through something integrated into the lock step mechanism (e.g. making sure the other instance caught up) yielded any fruits.

My guess is that I must have forgot to take something into consideration. I have some ideas for improvements, so we'll see!

Also I doubt sockets will be the bottleneck of this. Still I want to try shared process memory because I think it could make some things easier to implement.
kevincrans says:
Oct 12th 2020
I'm 19 and last week was a peek in depression for me as well, hope you feel a lot better soon, hugs!

I found 2 Nvidia specific powerpoint pdfs recalling quadrilateral patches/meshes:
Opengl 4.0:
Directx11 Tesselation:

I hope this may help you (not that everyone has a Opengl 4.0 capable Nvidia)

U didn't mean pixel scanline right?
Khyze says:
Oct 12th 2020
Wow, I used No$Gba to play coop with friends and it was hella fun (it would be "it is" but GBA doesn't have great coop games as the NDS)

I know some people wouldn't mind both instances running together (I bet some of them just want to trade some Pokemon?, in my case, Digimon World Dawn, Didn't worked last time, not sure how to load my save again)

It would be cool to play games like those, Phantasy Star and Final Fantasy Crystal Chronicles are great choices too! From the Abyss, hell I was looking for that game quite a while, I just remembered right now, thanks :P

I don't usually test games because No$Gba saves sucks, and most games require few minutes of gameplay before allowing local modes, I know for sure Ben 10 doesn't work (You can play as soon as the game loads, but after few seconds, connection error)
AsPika2219 says:
Oct 13th 2020
DSI Camera! I hope SYSTEM CLAW are working with this feature! 👍
pokemon says:
Oct 13th 2020
boot games from dsi menu
A dragon says:
Oct 13th 2020
I'm wondering what the command line options for MelonDS are. I'm considering using it to add games through the Steam client, which is why I asked.
WaluigiWare64 says:
Oct 13th 2020
>boot games from dsi menu
You already can. However, DSiWare need to be preinstalled onto the NAND.

>command line options for MelonDS
I think the only command line option is to launch ROMS ("./melonDS game.ds").
Geo64 says:
Oct 13th 2020
A debugger would be really awesome.
A dragon says:
Oct 13th 2020
That's one thing I'm thinking of, but trying that didn't work, WaluigiWare64.
Anon says:
Oct 14th 2020
This emulator needs a fullscreen mode
Jun says:
Oct 14th 2020
A suggestion for the section of cheats, is that in the section of this, could be added the cheats based on the data or databse of the rom, something similar to what made desmume, instead of looking for them by Internet
poudink says:
Oct 14th 2020
full screen was added recently I think
Post a comment