|Home | Downloads | Screenshots | Forums | Source code | RSS|
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, ...)
• OpenGL renderer, 3D upscaling
• RTC, microphone, lid close/open
• Joystick support
• Various display position/sizing/rotation modes
• (WIP) Wifi: local multiplayer, online connectivity
• and more are planned!
If you're running into trouble: Howto/FAQ
If you're feeling generous: melonDS Patreon
Sneak peek of melonDS 0.9
May 21st 2020, by Arisotura
There's not going to be any fancy screenshot here, simply because there isn't much that is worth a screenshot. However, I figured I'd give a little status update, because it's been a while. There's been a lot of work done so far, and we're not done yet.
So, first of all, the whole 'new UI' adventure.
At this point, it's been what, four total UIs melonDS has had, counting the one being made.
The very first one didn't even see an actual release. Can't even really call it an UI, it was nothing more than a bare window using the Win32 API directly, along with some hardcoded input mappings, that just served to help me get the emulator core going.
Obviously, it was specific to Windows, and I wanted melonDS to be cross-platform, so it was thrown away. I didn't want to have to maintain separate frontends for each OS, so using a cross-platform UI toolkit was a must. I wanted something that was relatively lightweight, and if possible, used native widgets instead of reimplementing them.
Thus, the 0.1 release came with a wxWidgets UI. Due to not being able to make wxWidgets and SDL interoperate smoothly, the UI was a clunky mess that came in separate windows. But atleast it was more user-friendly, and worked under Linux.
The wxWidgets UI was eventually retired with the 0.5 release. I went with libui, which was small enough that I was able to modify it to meet my needs. The new UI even had several improvements over the previous one. libui's design was not optimal, but it was good enough for what we wanted, so we built upon it for the next releases.
Fast forward to now. As you might have read in the previous posts, we've been wanting to add new features to melonDS, but found that libui lacks support for what we need. We didn't want to spend forever building upon libui, so we decided it was time, after more than two years of service, to retire the good ol' libui UI.
... read more
|44 comments (last by MelonMan) | Post a comment|
Apr 11th 2020, by Arisotura
I know things are slow lately, but there's still some shit getting done! Mostly taking care of low hanging fruit.
For example, I felt like dealing with issue #598. Which was the same problem as the older #379, by the way.
The base issue was that some polygons ended up sliiiightly offscreen (getting a lower Y coordinate of -0x1001 when the view volume bound is at -0x1000, for example). Not an issue with how coordinates are calculated, mind you. On the DS, polygons can be slightly offscreen like that and be clipped without any issues. But in the case of melonDS, due to how clipping was done, the texture coordinates of the vertices that stuck out would end up altered, resulting in a misaligned texture.
Ironically, using OpenGL appeared to fix the issue, but only because the way OpenGL applies textures is inaccurate to the DS hardware (which in itself causes a bunch of other texture alignment issues). So in the end, the two issues compensated eachother for a visually perfect result.
The software renderer, on the other hand, aims at replicating the original DS renderer as closely as possible, which in the end makes it more sensitive to little details like this.
Regardless, looking at the formula melonDS uses to clip polygons that are partly offscreen, it appeared that swapping the inner and outer vertices gave results closer to what the DS produced, so I did exactly that, and it ended up fixing the aforementioned issues.
So, one step closer to pixel perfection, I guess. Even though we aren't quite there yet; you might notice that the screenshot from Brain Puzzles are exhibiting another glitch that wasn't fixed.
Also, I finally took care of properly handling ROMs with encrypted secure areas (which is the case of the Virtual Console dumps, for example). Before, those could only be run by doing a full firmware boot, now they can be run via direct boot without issues.
... read more
|27 comments (last by Marck) | Post a comment|
Mar 16th 2020, by Arisotura
I guess that within the current situation, I owe you a post to keep you informed on things.
We're envisioning FLTK for a new UI, but I have yet to give it a try and see whether it would be a good fit for melonDS given how it works.
Motivation is at a low here though.
But, to give you an idea what to expect: given the scope of what we are developing, we're aiming straight for a 0.9 release.
The IRL situation isn't helping things. You might be aware of the coronavirus. We at the Melon Factory of Kuribo64 are fine for now, but the pandemic is growing, and with it, a set of heavy consequences.
After underestimating the virus for a while, France is finally taking confinment measures.
That may slow things down regarding the plans I have IRL, like, my attempts at getting a decent job.
What worries me more than the coronavirus, though, is the ongoing economical crisis. Markets are crashing and I guess it's not a good thing. It all seems abstract for now, but sure enough, in a while we will begin seeing concrete effects to this. Like, I don't think this is the best time for getting a job, but it's also going to be a mediocre time in general for the smallest and most vulnerable.
So, I'm keeping a close eye on all that. Worst case would mean I'd have to take immediate action to avoid going bankrupt and ending up homeless. Probably ending up in some squat.
|22 comments (last by Arisotura) | Post a comment|
Feb 25th 2020, by Arisotura
As I decided to continue working on the new cheat system for melonDS, I devised a simple binary file format that melonDS will use to store cheat codes and associated metadata. Nothing terribly difficult.
Except then I need to properly design my basic blocks (AR code list parser thing, AR engine, etc) so that they can be interconnected nicely.
Which is where I began thinking about the kind of interface I would need for entering cheat codes.
libui doesn't support the kind of controls I want to use.
Generic has been thinking of a kickass debugger UI and running into the same issue.
So... it's time to take a decision here.
We haven't taken a decision yet. Basically we need a good UI toolkit, that, ideally, is lightweight yet well-featured, modular (so you don't need to embed a complete behemoth if you aren't using everything), uses native UI controls, supports drawing areas and OpenGL...
... read more
|27 comments (last by Fif) | Post a comment|
By popular request
Feb 15th 2020, by Arisotura
I'm not forgetting about the OpenGL work that was started, either, but I really needed to work on something new to get some motivation back and not let melonDS die.
Also, our comrades RSDuck/Generic and Chagall have been working on some pretty rad shit too. We're coordinating to unite all that nicely for an epic release eventually.
|7 comments (last by adinsx) | Post a comment|
New melonDS feature: GBA connectivity
Jan 28th 2020, by Chagall
Hi everyone, I'm a new contributor to melonDS, Chagall on IRC and rzumer on GitHub. Being a fan of the melonDS project, I wanted to contribute something to it, and my most wanted missing feature being GBA connectivity, I spent a few weeks on and off implementing it.
This feature is mostly used in DS games to grant bonuses to players who own specific GBA titles. For example, inserting a GBA Ace Attorney game and launching the DS version will unlock all cases in the remake. Some games go further and read/write save data from/to the GBA cartridge (as in Pokémon games), or in one case polls its I/O port (Lunar Knights/Boktai DS).
All these features are now integrated in the master branch of the melonDS git repository. As far as I'm aware, this makes melonDS the first emulator to support solar sensor emulation in Lunar Knights. The video below demonstrates using the Solar Sensor item in Boktai DS with Bokura no Taiyou in the GBA slot.
Of course, you can also send your pocket monsters from GBA to DS, as demonstrated in this video:
As on real hardware, the GBA save file is modified during migration as the Pokémon are moved to the DS game:
Thanks to endrift of mGBA for the solar sensor emulation code that I used as a primary reference, and to DeSmuME authors for the GBA cartridge Flash save read/write logic that helped a lot with supporting the Pokémon games. Martin Korth's GBATEK document was also a great general reference.
... read more
|31 comments (last by chuckthetekkie) | Post a comment|
Sorry for the silence lately
Jan 17th 2020, by Arisotura
Shit's happening IRL.
Well, if you know me, you know that:
* I tend to only be able to focus on one big thing at once
* I am a trans girl
About the second point, I'm wanting to 'finish' my transition. There isn't a specific point where a gender transition can be considered finished; when your transition is finished depends on your criteria.
For me, that means I'm currently putting together the paperwork to get my name changed. Not the most difficult part, but anything involving paperwork tends to drain my energy, so you guess how that goes.
And it's not over, next comes getting my gender marker changed, and that one is more difficult (surprise).
Finishing my transition also means a few other things, like finally working on my voice or taking some time to figure out my style and build a better wardrobe.
There's also the whole bit where my job ends in about one month, and for now I don't quite know what I'll do next.
Sorry for the lack of activity wrt melonDS, but hopefully that will pick up again soon.
I began adapting the 4xBRZ filter shader to the OpenGL renderer a while ago, which is giving decent results, but I need to finish it (namely adding the 3D layer to it). I'm experimenting with ways to filter the 2D elements when the 3D layer is being upscaled.
|16 comments (last by V13Loca) | Post a comment|
melonDS wishes you a merry Christmas!
Dec 22nd 2019, by Arisotura
Not quite Christmas yet, but whatever. Soon enough time itself will stop existing, so these considerations are futile.
We're also past melonDS's third birthday. Time flies, it's crazy.
So what's new on that front? Well, not a lot, alas. I want to improve the OpenGL renderer, but for now, I started working on things, hit a roadblock as to how to do certain things, and, surprise, lost motivation. So until I get that back, there won't be a whole lot happening.
Also, Christmas might be more or less of a shitshow, as I'm trying to make it to my hometown to see my family whom I haven't seen in ages. I'm eagerly waiting for that, but it's not going to be that simple. Remember the general strike from Dec 5? Lo and behold, it's still going, and the train I had booked was cancelled due to it. I booked a bus instead, which is going to be a lot of fun (11-hour trip during the night, in conditions where I can hardly sleep). Besides, the crazy Macron government is indirectly pushing these bus drivers to drive as long as possible without rest (mostly to make up for the strike), by passing a bill to remove the requirement for breaks every 2h, thus completely disregarding security for the sake of profit. So, if I happen to die in a bus crash, you know who to blame.
Anyway, back to OpenGL. So, what I wanted to do:
1. Taking care of dual-screen 3D, and more generally any case where display capture is used. Currently, 3D frames that go through display capture end up downscaled back to 256x192, obviously because they need to fit in VRAM, and anything that uses them expects them to be that resolution.
There are ways to address that for the common use cases, though. As long as a captured frame isn't accessed by the CPU, it is possible to bypass VRAM entirely and instead use something like an OpenGL texture, without causing any visible problems. Sure, it's not too accurate to how the DS works, but neither is the general idea of upscaling. I am fine with this as long as we keep the accurate pathway (basically, the software renderer).
Anyway, the issue there is that I have to envision all the possible use cases. And for example, one possibility is to capture to a VRAM bank, with capture blending set to blend between the frame being rendered and a previous frame sitting in a VRAM bank (which may be the same bank we are capturing to).
I could always start with a simple use case (like dual-screen 3D). The issue is that I always feel the need to envision the whole scope of the project, all the use cases etc, because I fear that if I start building something for one use case, it may later prove unsuitable for other uses cases, and cause me to have to start again from scratch.
... read more
|21 comments (last by kevincrans) | Post a comment|
JIT beta builds and introducing myself
Dec 7th 2019, by Generic aka RSDuck
After all so much time has passed, it's finally time to do a release of JIT beta builds!
As Arisotura has stated in her last post, there's now another head working on melonDS. I'm Generic on IRC and RSDuck on Github.
For some reason I started messing with DeSmuME a bit more than a year ago, trying to write a JIT recompiler targetting ARM64, to improve performance on the Switch. After many struggles something working came to be, but it missed it's original goal of being fast for several reasons (see the link if you're interested).
After recovering from the disappointment I put my hopes into melonDS, but since it lacked any JIT compiler (besides the abandoned attempt by Arisotura herself) I wanted to start with a x64 recompiler. Skip forward a bit and the JIT started take on form. After taking everything apart and putting things more cleanly back together around the beginning of last summer things only got better, with most instructions being recompiled and the opening of the pull request on Github, which later got merged.
At this time the ARM64 backend was started this time avoiding my previous mistakes. With autumn it reached a similar level of completion as the x64 backend while both backends received some optimisations. Until this point we were catching up to DeSmuME but at this point started to surpass it. Here is where I want to thank all developers of open source emlulators whose dynarec I was eable to look into and especially the developers of the JIT of Dolphin. We're not only using their code emitter but they also gave me some great advice on IRC!
With some further optimisations of the 2D GPU emulation using ARM NEON instructions, most 2D games already run at fullspeed on the Switch, while most 3D games run at fullspeed with overclocking. The ARM64 JIT and the GPU optimisations are currently located in my own fork and are distributed by me in binary form on Gbatemp in an admittedly chaotic way.
I am very grateful to Arisotura for creating the emulator in the first place, as well as trusting in me and my work. For the future the already mentioned GPU optimisations are my current focus. I'm currently rewriting the old ARM NEON optimisations to be more clean and adding some additional ones which hopefully increase the performance a bit more. The logical step following would be a NEON 3D GPU backend. I have some more plans lying around, e.g. there is still one major JIT optimisation we're missing out on (fastmem).
So but now enough storytelling, here are the builds:
... read more
|45 comments (last by poudink) | Post a comment|
Status update II
Dec 5th 2019, by Arisotura
First of all, things have been a bit shitshow-y, and involved a few bursts of depression, but, finally, it's there, I have my apartment now. I'm not quite finished settling here, but that's a big relief for now. Plus, the place is fairly nice! Except for the wall sockets being upside-down, but, eh.
Next, I'm being sucky at delivering a JIT beta. Thing is, unlike the DSi branch which was hacked together by me, the JIT branch is Generic's work, so I will need to take a while and get familiar with it.
In the meantime, I figured I would let Generic handle things himself. I gave him access to this blog and all, so he will be able to post a beta build, which he said he would do tomorrow.
I figure the best way to work with this long-term is to work as a duo. I'm less skilled on things like fast CPU emulation, and more skilled on other parts of emulation, so other people like Generic can complement me nicely there and together we can deliver an excellent product.
And, holy fucking shit, reconciling the JIT and DSi branches is something I'm totally looking forward to. At this point, the DSi branch already has several conflicts with the master branch (it's based off 0.8.1, so yeah), and, no idea about the JIT branch.
Immediately tho, I'm going to improve the OpenGL renderer. This means reorganizing some of the code so it's easier to work with, fixing some longstanding issues like the case of dual-screen 3D, and adding some filtering.
You can follow the progress in the appropriately named blackmagic_II branch.
Hell, even writing this post is taking me forever.
Also, today's Dec 5, and it's the general strike day. Seeing how successful it was, if they manage to keep going at this rate (and they totally intend to keep going), president Macron is going to have a hard time. But, this also means that certain things may be delayed, or whatever, so we'll see.
|8 comments (last by Arisotura) | Post a comment|