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

• Nearly complete core (CPU, video, audio, ...)
• JIT recompiler for fast emulation
• OpenGL renderer, 3D upscaling
• RTC, microphone, lid close/open
• Joystick support
• Savestates
• Various display position/sizing/rotation modes
• (WIP) Wifi: local multiplayer, online connectivity
• (WIP) DSi emulation
• DLDI
• (WIP) GBA slot add-ons
• and more are planned!







Download melonDS

If you're running into trouble: Howto/FAQ
Pages:1···12131415161718192021
Network support: in the works
Jan 24th 2018, by Arisotura
You might have seen this thread.

Network support was achieved, but it was roughly equivalent to that of DeSmuME.

Currently, the network interface used by libpcap is hardcoded, I haven't added a UI for this yet.

There is also a disadvantage to this: it only works if your computer is connected via ethernet. It also requires promiscuous mode, which might be a problem in some situations.

I am working on a workaround to this, that allows networking without promiscuous mode. It will have to be tested extensively, but so far I got promising results.
18 comments (last by not_A_staple) | Post a comment
Slowdown
Jan 16th 2018, by Arisotura
What an original title.


Regardless, it's the case again. Real life is... still a bitch.

I need to change my phone plan, because while it was fine when I mostly used home internet, it sucks big time for more nomad uses. It's one of those plans that completely block internet access once you reach the data cap. So I'm going to switch to a plan with more data and that throttles speed instead of outright blocking. But in the meantime, I'm having trouble getting internet access.


As far as melonDS is concerned, I'm not quite sure what to try.


I have been trying to address the wifi stability issues, without much success. I have been doing a bunch of research on the multiplay communication thing and how it handles errors, thinking that properly handling those would make for a more stable connection (as opposed to always reporting success even when some data didn't make it through).

But so far, it has largely been a failure. At best, my attempts fixed nothing, and they generally made things worse.

I don't understand what it's expecting, so for now I'm putting this on the back burner.


Upscaling is a possibility, but as explained in a previous post, it's not all easy and nice. It'll also require writing a hardware renderer first, which could be a fun challenge.

There are quite a few tricks we can pull with modern OpenGL to emulate the DS GPU as accurately as possible. Obviously it would never get perfect, but we can get close.

... read more
14 comments (last by hyarsan / Flooder) | Post a comment
melonDS 0.6b
Dec 16th 2017, by Arisotura
As promised, the quick fix release is out. There are a few other goodies too.


:)


Windows 64-bit
Linux 64-bit

melonDS Patreon
11 comments (last by AaronIsona) | Post a comment
oops
Dec 8th 2017, by Arisotura
I just realized that there are some bugs with the menu options pertaining to screen layout/etc, esp with how the checkmarks are initially placed. There will be a quick fix release to address this.


Sorry.
3 comments (last by Rin Tohsaka) | Post a comment
melonDS 0.6
Dec 7th 2017, by Arisotura
I'm lazy, and there are little visual changes, so I will reuse those screenshots.





So what's new in melonDS 0.6? Little emulation wise, a bit more UI wise.


First of all, I want to thank the artists who have been (and are still) drawing all sorts of rad icons for melonDS. For 0.7, I will pick the one I like the best (and it won't be easy, heh). Thing is, I want to put the icon in the melonDS windows, and I will need to add support to libui. Which also means embedding the icons in some portable format, because each OS does its own thing when it comes to window icons.


Emulation wise, the big thing is the sound fix I talked about in a previous blog post. I already went in detail over this, but, long story short, surround works now. And sound emulation is more accurate, that can only be good.

There. The rest is meaningless shenanigans.


UI wise, you get fancy display modes now. Those were also discussed in a previous blog post, so no big surprise there.

The only thing that was added is a toggle for linear filtering, for those who like pixels.

The rest is, well, little bug fixes. Under Windows, you can now load ROMs with non-ASCII characters in their paths. As a side note, under Linux and OSX, fopen() can take UTF8 paths, but Windows requires a separate codepath because herpderp. fopen() can only take ASCII, for anything outside of that you need to use the Windows-only _wfopen() which takes wide-char strings. In the end, the code is a bit ugly, but it works.

... read more
8 comments (last by Soralis) | Post a comment
Another of those long-due fixes
Nov 11th 2017, by Arisotura
The sound core is fixed, or mostly.


If you've been playing with melonDS, you may have noticed that effects like surround generally didn't work, and that whenever they worked, they resulted in crappy sound. Resetting or loading different games would also give different results.


So I've been addressing all that junk.


The randomness was easily fixed -- the write position for capture units wasn't being reset properly, so whenever the capture unit was started, it would start writing wherever it was previously left. Not really a good thing.


The rest was trickier though.


The DS sound controller provides 16 channels that can play a few types of audio, and 2 capture units that can capture sound output and write it to memory.

Several games provide different audio modes, typically headphones/stereo/surround. In those games, the audio output isn't directly sent to the speakers, but it is sent to the capture units. The game then alters it as it wishes, and two special channels (1 and 3) are used to send the final output to the speakers.

The mechanism is generally used for the aforementioned audio modes, but some games take it further -- Golden Sun: Dark Dawn goes as far as using it to play its sound effects.

While the mechanism (which we will name "surround setup") may sound simple, getting it to work is actually tricky.

... read more
17 comments (last by random person) | Post a comment
How far we have gone, and where we are going next
Nov 9th 2017, by Arisotura
melonDS has been going for one year now.

Well, the repo was opened in May 2016, but the real work started in November 2016.

I didn't really know what I was in for, but hey, I wanted to have fun making something new. There wasn't much else in terms of goals, other than the famous goal of successfully emulating local wifi.

Of course, getting an emulator project going is initally a gruelling task, as it takes quite a bit of work before you can get interesting results. In the case of the DS, as I went with the goal of emulating the BIOS boot procedure, there was quite a lot to be done before the firmware would try to display things. In the case of melonDS, it took about 2.5 months to get there, but I don't consider it a good idea to look at durations. I was unemployed at the time (or rather, waiting to start that job), I'm a lazy fuck, and a couple vicious CPU bugs got in the way.

The first release of melonDS was a mere curiosity. It was inferior to the existing emulators. But that didn't matter, it was out there for the curious, and I was having fun with that project. The next releases would deliver quality.

The 3D renderer was my first attempt at a polygon rasterizer. I initially fumbled getting things like perspective correction working, but gradually gained more understanding of the process. Conducted tests to try understanding how the actual GPU did things and which shortcuts it took. And it has been an interesting ride.

I guess it turned out okay. This renderer has become the most accurate among all DS emulators. I thought, since the 2D renderer is going to be pixel-perfect, why not make 3D pixel-perfect too? I'm not there yet though, but the renderer is more than good enough for most games. Not good enough for the aging cart tests (which demand perfection to the pixel), but I put that on hold for a while.

On the other hand, the renderer code evolved as I discovered things, and is probably not as clean as it could be. In long term, it could benefit from a rewrite.


And this shit has been going on for one year now. Time flies, it's crazy.

... read more
14 comments (last by hello) | Post a comment
melonDS 0.5, finally!
Oct 5th 2017, by Arisotura
Yup, there it is.





It's a recurrent theme in my projects that UI shenanigans are something I have trouble with. It's not that hard to make a UI, but making it cross-platform is another deal entirely. I want to avoid ending up with a different, separate UI per platform.

In the end, I went with libui, which is small and lightweight. I modified it to fit my needs.

The decision took a while though, and is one of the reasons why the release took so long to happen. Other reasons being, well, real life. My previous job is over, and hello job hunting again.


So this release features a new UI. It's not too new, but it removes the unneeded windows. Menus and video output are in the same window now, and the console window (the black window that spews nonsense) will be absent from release builds.

You can also drag-drop ROMs onto the window to run them. It is also possible to run ROMs via command line, but ATM when doing so melonDS will attempt to look for BIOS/firmware/INI in the directory the ROM is in.

If you play with your keyboard, you will need to remap your input, as different key codes are used (raw scancodes vs SDL scancodes).

Other than that, there are not a whole lot of changes emulation-wise. A few fixes, and the addition of antialiasing, as mentioned in the previous post.

... read more
10 comments (last by Merty) | Post a comment
Antialiasing
Aug 28th 2017, by Arisotura
This is indeed what has been worked on lately, so congrats to those who guessed right :P

As well as finding out that my edge slope functions weren't perfect. I tried, with moderate success, to make them more accurate, but they're still not perfect. So for now, I need to let it cool down. I decided I would make antialiasing 'good enough', then start working on the UI. Considering that there are other areas of the GPU that aren't perfect, like polygon clipping.

So here's a couple screenshots:



I picked cases where the result is quite visible. Antialiasing generally makes things look better, but whether it is that visible depends on what's being rendered.


Antialiasing may look like one of those minor details that are unimportant. But I consider it important to emulate, past the effect of making things look nicer: the way it works on the DS is very different from common antialiasing techniques. If you're into DS homebrew, you can't just turn on antialiasing to magically make things look better.

To begin with, antialiasing is applied to polygon edges based on their slopes, in order to make the edges look smoother. There is no antialiasing applied inside polygons or at intersections between two polygons.

Antialiasing also doesn't apply to translucent polygons. But actually, it's more complex than that -- the polygon fill rules depend on whether the individual pixel being rendered is translucent. So if a polygon has opaque and translucent pixels at its edges, the opaque parts will be antialiased and the translucent parts won't be.

The effect was shown in the following dasShiny screenshot. Note that dasShiny only has partial antialiasing support, it is only applied to Y-major edges.

... read more
6 comments (last by iShagers) | Post a comment
Sneak peek
Aug 18th 2017, by Arisotura
The 3D renderer is being worked on, and for example, this is in the works:



I'll let you guess ;)


Work is also being put into figuring out the exact GPU algorithms. What has been done so far is a double bonus: not only is the renderer more accurate, it's also faster as a result of doing less divisions per pixel. The GPU takes shortcuts, so figuring them out allows for this kind of double-bonus optimization.

For example:



The buttons have dents in their borders, that are also visible on hardware. Those are caused by interpolation quirks. Artificially perfect interpolation will make the buttons look "perfect".

It's a tiny detail that likely doesn't matter to a whole lot of gamers, but as I said, I like figuring out the logic behind what I'm observing :P

Besides, it can't be bad to have an accurate renderer. You never know when a homebrew dev or ROM hacker may run into GPU quirks, but they may find about those more easily if they can reproduce the quirks on an emulator.

... read more
14 comments (last by Ayaya) | Post a comment
Pages:1···12131415161718192021