About melonDS
Jun. 7th, 2025 01:40 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
arisoturaI feel like writing a bit more about melonDS and how I feel about it... if you don't know, melonDS is my DS emulator project. Well, now it's maintained by a small team, but it was originally my project.
melonDS is what I consider my most successful project to this day. It is 8 years old. I can't say as much about any of my other projects, as most of them have either died after a couple years or been taken over by different people after I lost interest, when they didn't just die in the early phases. That's ADHD for you.
This explores some more personal aspects of this project, that I don't post about on the melonDS site.
https://melonds.kuribo64.net/ by the way. It has a lot of juicy technical posts, if you like that. I really should organize it better, make it easier to find certain types of posts, ...
Anyway.
My original idea, back in 2016, was to fork DeSmuME and do my own wifi-related work, away from the team's attitude towards wifi. There's more to be said about this all, but I won't get into it in this post. I'll just say that my goal was to try and get local multiplayer working. Online connectivity (for example, connecting to WFC servers, or using an IRC client) was a mostly solved problem, but local multiplayer (basically any multiplayer mode that doesn't use WFC) relied on more specific hardware functionality, and stubbornly refused to work.
So that was my original idea. Then I looked at DeSmuME's codebase and went, ... nah, I'll make my own, that will be easier to deal with.
At the time, I was also approached by someone else for a joint DS emulator project, but for several reasons (including me moving out at that time), it didn't pan out.
In the end, I was going to have to wait a couple months before starting my first job. Writing a DS emulator seemed like a perfect way to pass time.
There is always a steep curve to starting that kind of project, because the initial phase is mostly about getting some form of CPU interpreter going, implementing various instructions, and there isn't a whole lot of exciting output. But, quickly enough, I got to the point where the DS firmware was attempting to display graphics, so that was exciting.
Some fumbling later, I had a mostly accurate rendition of the DS menu, and could even boot games... I started posting about melonDS and releasing it. At the time, it was nothing but a mere curiosity; the first release didn't even emulate sound. But I didn't care, I was making it because I was having fun. There were other DS emulator projects cropping up, too, so all this helped revitalize the stale DS emulation scene.
Eventually, I felt confident enough in melonDS's emulation capabilities to try going for the wifi quest. I got to the point where two melonDS instances could see eachother when looking for multiplayer games, but couldn't actually connect. But I had some basic infrastructure in place for this.
And after much research, reverse-engineering, hardware testing, implementing various functionality, status bits, etc...
DS local multiplayer was emulated for the first time.
Of course, it was still very crude, and slowdowns and spurious disconnects were not atypical. But it was something.
What I didn't expect was that this would boost melonDS's popularity. From being a mere curiosity, melonDS became "the wifi emulator". I think it was one of the things that helped make melonDS's success, and helped me keep it going, too.
But it also raised very real questions about the design and structure of the project. If I had to make a DS emulator from scratch, I would do things differently, but I had no real idea what to expect or how to make things work when it came to multiplayer. I knew that the protocol used required pretty low latency, but had no idea which conditions it could work under. melonDS was designed in such a way that one melonDS process would emulate one console. When I first added multiplayer, I used UDP sockets, this way it could theoretically work over the network but also with multiple instances running on a same PC.
Wifi support didn't see much progress then, as I was focusing on other areas of the emulator, and also dealing with bad mental health. I was beginning my transition and dealing with a bad living situation, not exactly ideal. There was also another issue: I had no real idea why local multiplayer connections didn't work well. I knew my system for communication was just tossing frames over the network with no synchronization. I didn't know how much this was responsible for the issues, vs. for example, emulation problems. I didn't know how to approach this, as it seemed gargantuan. There had been some experiments, but everything that was tried seemed to make the problems worse or not fix anything.
In 2022 I decided to dive into it and fix it once and for good. It was the local multiplayer saga. I designed a synchronization mechanism to ensure every packet was arriving on time. The first approach was heavy-handed, but the point was to find what works, and optimize later. There were still issues, which suggested there were emulation issues playing into this again. And my research did indeed uncover some issues, fixing them finally resulted in butter smooth multiplayer. No slowdowns, no disconnects.
The new synchronization mechanism was based on a different system for communication: melonDS instances used shared memory and semaphores instead of UDP sockets. Later, the melonDS codebase underwent a great refactor in order to make it possible to emulate multiple consoles within a single melonDS process. Then local multiplayer could just use a regular memory buffer and regular semaphores to communicate, instead of requiring costly IPC primitives. A separate system was built for LAN multiplayer, to replicate the old "play over network" functionality in a more reliable way. It does actually function decently well over a wired network, but tends to fail to work over wifi networks. It may seem ironic, but it makes sense given wifi networks tend to add more latency in a not-so-predictable way.
Regardless, the refactor was a long and arduous task. It goes to show, it's hard work to maintain a codebase and keep it simple and readable, even moreso when multiple people are involved. It would be ironic if melonDS ended up reproducing the flaws that I observed in DeSmuME's codebase that pushed me to start melonDS in the first place. But at the same time, maybe such is the life of a programming project, as it evolves and more stuff is added...
Now, I'm at a point where I don't really know what to do with melonDS... It has given me no shortage of intellectual stimulation and challenge: local multiplayer, online multiplayer, DSi emulation, OpenGL renderer... I could name the JIT recompiler, but it was written by Generic/RDSuck, and I haven't really touched it much.
Maybe I'm just at a point where I need to work on other things. At the same time, I don't want to abandon melonDS. Even if I'm not the only person working on it, people tend to associate it to me, because I'm the creator and also because most of the posts on the melonDS site are from me.
I feel that it's a lot to carry, at this point. We are a small team, but having a somewhat bigger team would make sense at this point. But it's not something we get to decide, either. It's an open-source hobby project.
For example, an idea I've had for a while was to add netplay: basically, make those local multiplayer games playable over the internet, as some other emulators do. I even had a very janky proof of concept at one point. On one hand, I can see the potential this would have: it could be immensely popular. On the other hand, it's also scary for this reason. It means doing more user support, something I'm not exactly good at. It means a complex system in which things could go wrong in many ways. I don't know how well it would even run.
There is also still work on the emulation front. DSi hardware that is still unemulated or poorly supported. A JIT for the Teak DSP would be nice, as anything that uses that DSP causes melonDS to run at 4 FPS. GBA slot addons that aren't emulated. There are also ideas to revamp the emulator's UI, features that could be nice to add, etc.
There is also much cleanup work to do on the codebase still, especially the frontend part. It doesn't help that I hate dealing with this code, and it tends to be difficult to get the team's input on those things...
Atleast I can be proud of melonDS, I guess.
melonDS is what I consider my most successful project to this day. It is 8 years old. I can't say as much about any of my other projects, as most of them have either died after a couple years or been taken over by different people after I lost interest, when they didn't just die in the early phases. That's ADHD for you.
This explores some more personal aspects of this project, that I don't post about on the melonDS site.
https://melonds.kuribo64.net/ by the way. It has a lot of juicy technical posts, if you like that. I really should organize it better, make it easier to find certain types of posts, ...
Anyway.
My original idea, back in 2016, was to fork DeSmuME and do my own wifi-related work, away from the team's attitude towards wifi. There's more to be said about this all, but I won't get into it in this post. I'll just say that my goal was to try and get local multiplayer working. Online connectivity (for example, connecting to WFC servers, or using an IRC client) was a mostly solved problem, but local multiplayer (basically any multiplayer mode that doesn't use WFC) relied on more specific hardware functionality, and stubbornly refused to work.
So that was my original idea. Then I looked at DeSmuME's codebase and went, ... nah, I'll make my own, that will be easier to deal with.
At the time, I was also approached by someone else for a joint DS emulator project, but for several reasons (including me moving out at that time), it didn't pan out.
In the end, I was going to have to wait a couple months before starting my first job. Writing a DS emulator seemed like a perfect way to pass time.
There is always a steep curve to starting that kind of project, because the initial phase is mostly about getting some form of CPU interpreter going, implementing various instructions, and there isn't a whole lot of exciting output. But, quickly enough, I got to the point where the DS firmware was attempting to display graphics, so that was exciting.
Some fumbling later, I had a mostly accurate rendition of the DS menu, and could even boot games... I started posting about melonDS and releasing it. At the time, it was nothing but a mere curiosity; the first release didn't even emulate sound. But I didn't care, I was making it because I was having fun. There were other DS emulator projects cropping up, too, so all this helped revitalize the stale DS emulation scene.
Eventually, I felt confident enough in melonDS's emulation capabilities to try going for the wifi quest. I got to the point where two melonDS instances could see eachother when looking for multiplayer games, but couldn't actually connect. But I had some basic infrastructure in place for this.
And after much research, reverse-engineering, hardware testing, implementing various functionality, status bits, etc...
DS local multiplayer was emulated for the first time.
Of course, it was still very crude, and slowdowns and spurious disconnects were not atypical. But it was something.
What I didn't expect was that this would boost melonDS's popularity. From being a mere curiosity, melonDS became "the wifi emulator". I think it was one of the things that helped make melonDS's success, and helped me keep it going, too.
But it also raised very real questions about the design and structure of the project. If I had to make a DS emulator from scratch, I would do things differently, but I had no real idea what to expect or how to make things work when it came to multiplayer. I knew that the protocol used required pretty low latency, but had no idea which conditions it could work under. melonDS was designed in such a way that one melonDS process would emulate one console. When I first added multiplayer, I used UDP sockets, this way it could theoretically work over the network but also with multiple instances running on a same PC.
Wifi support didn't see much progress then, as I was focusing on other areas of the emulator, and also dealing with bad mental health. I was beginning my transition and dealing with a bad living situation, not exactly ideal. There was also another issue: I had no real idea why local multiplayer connections didn't work well. I knew my system for communication was just tossing frames over the network with no synchronization. I didn't know how much this was responsible for the issues, vs. for example, emulation problems. I didn't know how to approach this, as it seemed gargantuan. There had been some experiments, but everything that was tried seemed to make the problems worse or not fix anything.
In 2022 I decided to dive into it and fix it once and for good. It was the local multiplayer saga. I designed a synchronization mechanism to ensure every packet was arriving on time. The first approach was heavy-handed, but the point was to find what works, and optimize later. There were still issues, which suggested there were emulation issues playing into this again. And my research did indeed uncover some issues, fixing them finally resulted in butter smooth multiplayer. No slowdowns, no disconnects.
The new synchronization mechanism was based on a different system for communication: melonDS instances used shared memory and semaphores instead of UDP sockets. Later, the melonDS codebase underwent a great refactor in order to make it possible to emulate multiple consoles within a single melonDS process. Then local multiplayer could just use a regular memory buffer and regular semaphores to communicate, instead of requiring costly IPC primitives. A separate system was built for LAN multiplayer, to replicate the old "play over network" functionality in a more reliable way. It does actually function decently well over a wired network, but tends to fail to work over wifi networks. It may seem ironic, but it makes sense given wifi networks tend to add more latency in a not-so-predictable way.
Regardless, the refactor was a long and arduous task. It goes to show, it's hard work to maintain a codebase and keep it simple and readable, even moreso when multiple people are involved. It would be ironic if melonDS ended up reproducing the flaws that I observed in DeSmuME's codebase that pushed me to start melonDS in the first place. But at the same time, maybe such is the life of a programming project, as it evolves and more stuff is added...
Now, I'm at a point where I don't really know what to do with melonDS... It has given me no shortage of intellectual stimulation and challenge: local multiplayer, online multiplayer, DSi emulation, OpenGL renderer... I could name the JIT recompiler, but it was written by Generic/RDSuck, and I haven't really touched it much.
Maybe I'm just at a point where I need to work on other things. At the same time, I don't want to abandon melonDS. Even if I'm not the only person working on it, people tend to associate it to me, because I'm the creator and also because most of the posts on the melonDS site are from me.
I feel that it's a lot to carry, at this point. We are a small team, but having a somewhat bigger team would make sense at this point. But it's not something we get to decide, either. It's an open-source hobby project.
For example, an idea I've had for a while was to add netplay: basically, make those local multiplayer games playable over the internet, as some other emulators do. I even had a very janky proof of concept at one point. On one hand, I can see the potential this would have: it could be immensely popular. On the other hand, it's also scary for this reason. It means doing more user support, something I'm not exactly good at. It means a complex system in which things could go wrong in many ways. I don't know how well it would even run.
There is also still work on the emulation front. DSi hardware that is still unemulated or poorly supported. A JIT for the Teak DSP would be nice, as anything that uses that DSP causes melonDS to run at 4 FPS. GBA slot addons that aren't emulated. There are also ideas to revamp the emulator's UI, features that could be nice to add, etc.
There is also much cleanup work to do on the codebase still, especially the frontend part. It doesn't help that I hate dealing with this code, and it tends to be difficult to get the team's input on those things...
Atleast I can be proud of melonDS, I guess.
