Of course, as melonDS evolved, other concerns arose.įor example, archive support was added. So the original NDSCart::LoadROM() function did just that. When I first built the melonDS core, it was pretty simple, and all it had to do was load a ROM from a given file, load the associated save file, and start emulating. I mean, it certainly could be worse, but some parts could definitely use a refactor. The state of the melonDS codebase doesn't help, either, sometimes. I had tried to make plans of what I wanted for the custom paths feature, but, surprise, the actual implementation is going to be different. This is also why it can be difficult for me to get things done: I will try to envision the scope of the task at hand, then begin seeing related things that need to be done, more or less drifting away from the original task, and at the end I have too many ideas and I don't know where to start. As of now, melonDS takes the easy route and dumps these files alongside the current ROM, but not everybody wants that.Īnd, well, implementing this whole thing raises a bunch of issues.

It's been a popular request for a while: customizable paths for things like save files, savestates.

You might have seen that pic I posted on Twitter a while back: If you're running into trouble: Howto/FAQ

(WIP) Wifi: local multiplayer, online connectivity.

Various display position/sizing/rotation modes.

Nearly complete core (CPU, video, audio.

While it is still a work in progress, it has a pretty solid set of features: MelonDS aims at providing fast and accurate Nintendo DS emulation.

Source code for delta emulator