https://melonds.kuribo64.net The latest news on melonDS. https://melonds.kuribo64.net/comments.php?id=217 Mon, 09 Dec 2024 12:47:57 +0000
I also wanted to open up the nightly builds section, but I ran into a little issue. Basically, I made the database field for artifact IDs a regular integer, but Github's artifact IDs eventually became greater than 2147483647, which is the highest value a 32-bit signed integer can represent. Due to this, the commits since November were stored without their associated artifacts (the nightly builds).

I fixed the database structure. Now I will see if I can run a script to download the missing artifacts. Otherwise, further commits should have their artifacts downloaded correctly.

Once all that is sorted out, I will open up the nightly builds section.]]> https://melonds.kuribo64.net/comments.php?id=217 https://melonds.kuribo64.net/comments.php?id=216 Thu, 21 Nov 2024 00:47:39 +0000
A bit of a disclaimer about this unusual version number: due to the large number of changes since 0.9.5, this version is a Release Candidate. We have done a thorough round of testing and bugfixing, but there is always the chance that further issues went unnoticed. This release will be the occasion to catch them and fix them for the actual, proper 1.0 release.

Now, the biggest changes this release brings:


Core refactor

This is the biggest change by far. We have undertaken a large and ambitious refactor of the melonDS core, in order to make it possible to run multiple instances of the emulator within one single process.

What does this change mean for end users? It means that local multiplayer is easier to deal with, since we no longer have to deal with inter-process communication. It also means that depending on your platform, local multiplayer may be more performant now.

However, much like in 0.9.5, this multiplayer mode only works when running multiple instances on the same computer. But we have another ace up our sleeve, which we'll see next.

It's also worth noting that this refactor was partly motivated by the idea of adding netplay support. While I haven't been able to get netplay working yet, the refactor has laid a very important foundation for it. We'll get there, eventually!


LAN support

You might remember LAN multiplayer and the associated betas. This feature has been backported and brought to you proper in this new melonDS release.

This means that you can play local multiplayer games with family or friends over the local network.

Do note, however, that due to the tight timing requirements of the local multiplayer protocol, it requires a pretty good ethernet network to work. Do not expect it to work well over wifi. And, most importantly, do not expect it to work at all over VPN, Hamachi, or any sort of tunnel that goes through the internet. We will not accept issue reports about LAN connection failures that involve tunneling.


OpenGL compute shader renderer

Until now, we had the software renderer and the OpenGL renderer. The software renderer produces very accurate graphics but can't be upscaled. On the other hand, the OpenGL renderer supports upscaling, but it is prone to all sorts of problems and glitches.

So Generic brought us this new OpenGL renderer, which uses compute shaders to closely reproduce the DS GPU's rasterization algorithms on your computer's GPU.

This renderer brings together the best of both worlds: a graphical output that is very accurate, but at the same time, support for upscaling and other improvements.

The old OpenGL renderer will still be around, along with this new one. You can select them in the 3D settings dialog.


Software renderer improvements

Speaking of renderers, Jakly has been at work researching the intricacies of the DS GPU far more in depth than I have. She has committed several accuracy fixes and improvements to the software renderer, some of which might make a big difference depending on the game.

Jakly is also currently fighting our worst enemy, the Horseman of Timings. Compared to this, fighting the Horseman of Wifi was a walk in the park. But she's been doing some impressive work figuring out the intricacies of the DS's timing model, and might finally deal with a lot of the old timing issues. So stay tuned!


Multi-window support

This has been a long requested feature: the ability to split melonDS across two windows, or more. And it is finally here.

The way this feature works is quite similar to DeSmuME: you can open a new emulator window (View -> Open new window), which will function like the initial window. Then the layout settings can be set per window, allowing you to have one screen per window, but also many other possibilities. melonDS also remembers how many windows you had open and how they were configured.

We have also moved the layout settings to a separate View menu to make things clearer.

This is a first iteration of this feature, so it may get refined based on user feedback.


R4 Revolution and M3 Simply support

Until now, the way DLDI support was done in melonDS was pretty high-level. It was implemented through a custom DLDI driver that melonDS patches in, and a special cart class (CartHomebrew) is used, which can interface with melonDS's DLDI driver. While it isn't too far off reality, and works just fine, it is an entirely custom solution not based on any existing hardware.

asiekierka has been working on emulating specific flashcart models: the R4 Revolution and the M3 Simply. This makes it possible to, say, run these flashcarts' original menus. Can be a nice touch!

It's also pretty nice to have a reference as to how that hardware works.


Many other fixes

There are way too many fixes, changes, and general improvements to list here. You can find them in the changelog, for the most part.


Nightly builds

I plan to open up the section for nightly builds on the download page soon. I will keep you informed.



You will find this release on our downloads page, as usual. Enjoy!]]> https://melonds.kuribo64.net/comments.php?id=216 https://melonds.kuribo64.net/comments.php?id=215 Fri, 08 Nov 2024 14:22:40 +0000


We have to a point where, well... You guess it, it's been two years since the last proper release.

melonDS has become quite a large and complex project, with many moving parts. I compare an emulator project to a tree: when you're done with the trunk, it branches off in a billion directions. That's pretty much it.

We have been through a pretty big refactor of the codebase, and that comes with its lot of issues, doubts, and so on. Was the refactor a mistake? What could we do better?

One of the major selling points was the development of netplay. Unfortunately, that's not the first time I have big ideas, big ambitions, but fail to concretize them. That's ADHD for you.

In a way, I'm also afraid of netplay. It feels like a bit of a Pandora box. I mean, it has potential for being a very cool feature, but also for being an endless source of issues. Dealing with the wifi connection issues for so long has given me a glimpse of it already. As a matter of fact, solving interesting problems is something I'm good at, but user support is not. I've had a bit of a similar experience at my last job, too.

Regardless, I still consider melonDS to be a great success.

I might try netplay later if I feel like it, but for now, I'm burnt out on that stuff.

However!

We are getting pretty close to the release.

Our plan is to first release a RC of 1.0. Given the amount of changes and the scope of them, there may be more bugs and other issues than we can notice through our testing. The RC will be the occasion to catch them before the proper 1.0 release.

I also plan to open up the nightly builds section around that time. Given the slower development cycle of melonDS these days, it makes sense to provide nightly builds to the public.

But for now, I'm going to have surgery in two weeks, so I want to get the RC release out before that date. Hopefully very soon!]]> https://melonds.kuribo64.net/comments.php?id=215 https://melonds.kuribo64.net/comments.php?id=214 Thu, 31 Oct 2024 15:03:27 +0000 .org, so I feel compelled to write a post to clarify the situation.

That site is a fake site.

It is part of a larger network of fake emulator sites (like desmume.com) that only exist to leech SEO traffic and confuse users.

The only real melonDS website is the one you are currently looking at: melonds.kuribo64.net.


What can we do?

I intend to add a splashscreen to melonDS with the URL to this site, to make things clear. The URL is also printed in the console, but since melonDS release builds don't really come with a console window anymore, well...

Other than that, spread the word, so people don't get confused.

Also: it appears that Bing (and by extension DuckDuckGo) has decided that melonds.org is the legitimate site, and has removed our site from their search listings.

So, if you can, help us fix that. Report the fake site to Bing or DuckDuckGo.

You can also directly report them to their registrar: abuse-contact@sav.com

Thank you.]]> https://melonds.kuribo64.net/comments.php?id=214 https://melonds.kuribo64.net/comments.php?id=213 Sat, 12 Oct 2024 14:59:23 +0000
I've been completely caught in a different, but fun project. If you have seen my Github lately, you might have an idea what it's all about. It's actually an idea I've had since 2016: hacking the WiiU gamepad to run custom code on it, and trying to figure out what kind of cool things are possible. I made attempts back in 2016 and 2022, but never really got anywhere. However, 3 months ago I felt like making a more serious attempt (namely involving a FPGA board) and actually managed to get things done. I kinda want to make a non-melonDS blog to talk about that kind of projects, too -- there would be a lot to say. This project is really challenging and intellectually stimulating, which is all I love!

Anyway, I digress.

melonDS.

I still need to finish fixing the bugs before we can release 1.0. I hope I'll manage to get myself to get there, given the way my focus and motivation works.

First, thank you all for your kind comments! It means a lot.

Next, the plans. As I mentioned before, I want to take a big break from melonDS after releasing 1.0. melonDS will be 8 years old, and that's a lot, especially for a project of mine. It has been a very good project and I've had a lot of fun, but I think I need to do other things for a while.

However, melonDS isn't going to go dead.

You might have noticed that Jakly has been contributing a lot of accuracy improvements to melonDS. The amount of research she has been putting into things like the 3D rasterizer, or lately the ARM CPUs themselves, researching all the weirdest quirks and trying to emulate them, has been astounding. Better than even I have done years ago.

Not everything has been merged yet, because for some things it boils down to the cost vs benefits -- some can be included in melonDS without really hurting performance, but some would be more suited towards a 'developer' build.

Regardless, it would make sense for Jakly to be my successor, in a way. I don't want to completely abandon melonDS, but you get the idea. I'll give her access to this blog so she can make juicy technical posts too.

And of course, the rest of the team is still around too. While their contributions will largely depend on whether they feel as burnt-out as me, you can be sure melonDS isn't going dead anytime soon.

I also want to finally finish the nightly builds section. My concern there was about versioning, but we have an idea for that. We'll add an About dialog to melonDS, with the full versioning information, so nightlies can be distinguished from release builds. Then I'll be able to open this up.

That's all folks! See you in November for the 1.0 release.]]> https://melonds.kuribo64.net/comments.php?id=213 https://melonds.kuribo64.net/comments.php?id=212 Fri, 30 Aug 2024 08:44:21 +0000
Anyway, thank you all for your kind comments, it means a lot!

I haven't been working much on melonDS lately, mostly been relaxing by working on another personal project.

As far as melonDS is concerned, my plan is to release version 1.0 by November, ideally around the project's birthday. It is going to be 8 years old, by the way. I am amazed that it has been going this far.


So here's a quick list of the things that need to be done until then:

Implementing the multi-window feature. It shouldn't be very difficult, I had already coded the required support a while ago. It's mostly matter of integrating it into the UI and ensuring everything works correctly.

Fixing up the JIT to work with multiple instances. Generic is the JIT expert over here, so that'll be for him to deal with.

Maybe fixing up LAN, if I ever manage (and if I feel more motivated to work on it).

Fixing all the issues that have cropped up during the big refactor. There's also still a bunch of code cleanup to do. We will also need a bunch of testing and QA to make sure the 1.0 release works as intended.

Trying to remember all the changes we have made since 0.9.5, because there's a lot.


After the release, I will take a break from melonDS. I don't want to abandon the project, but I also have a lot of other things I want to do. Things indirectly related to melonDS (like updating this site, maybe things like a better, not outdated screenshot gallery). Other personal projects. Real life changes and stuff.]]> https://melonds.kuribo64.net/comments.php?id=212 https://melonds.kuribo64.net/comments.php?id=211 Sat, 17 Aug 2024 08:45:49 +0000
The scope of this feature means it requires more development and testing time than I would be able to do before November.

You can tell I was in a really active period. I'm trying ADHD meds, again. They work, but I overestimated things, and I burnt out.

The recent wifi stuff was the straw that broke the camel's back, I guess. I mean, why did I spend so long implementing the powersaving stuff, channels, etc, in the first place? That's right, I was trying to fix games that had trouble connecting. I thought I had figured it out, I had a fix that worked well for me, but then I kept getting reports that it wasn't working. I did more of the same a few days ago, once again thinking I had a decent fix, and nope. Only makes things slightly better, or doesn't make any change. This feels utterly defeating. Like nothing I do will ever fix it.

It's kinda like when I make posts about my difficulties and all I get in the comments is "can you add feature X" "can you fix Y". I'm not a programming robot, you know.

I'm burnt out, I guess. I want to put out melonDS 1.0, but I need a big break from melonDS.]]> https://melonds.kuribo64.net/comments.php?id=211 https://melonds.kuribo64.net/comments.php?id=210 Wed, 14 Aug 2024 22:24:27 +0000
I didn't quite know where to look. The LAN interface itself functions the same way as its season2 counterpart. The only thing I could think of was the improvements that we'd done to wifi emulation since season2.

I fired up my other computer and gave LAN a test. I had to do a bit of setup to get both computers connected over ethernet, since wifi has too much latency. But then I observed the same thing that had been reported to me: I could sometimes get a connection going, but it had a high failure rate.

To further confirm it, I even happened to get a connection failure over local multiplayer. It was just a lot less likely there.

When logging the wifi traffic, I observed something peculiar: the client would send a 802.11 authentication frame and receive another authentication frame from the host, then it would send an association frame, but at that point the host had entered power saving mode. It would only leave power saving mode a lot later, and that was too late.

The LAN interface does something a bit particular: due to how it functions, it may receive frames at any time, and these are added to a receive queue to be consumed where needed. To avoid clogging up that queue, frames that are more than 16 milliseconds old are considered stale and are deleted. This should normally be more than enough: when the wifi system is active, it checks for incoming frames fairly often, that is atleast every 0.5 milliseconds.

I could see how this was a problem in the aforementioned case, but raising the 'stale frame' threshold as far as 500ms did not fix the problem. So I had to approach it differently, namely, by considering how things work in wifi land.

The host sends beacon frames every ~200 milliseconds, to advertise its presence to potential clients. A client that wants to connect will then initiate the process by sending the host an authentication frame after receiving a beacon, and so on. The authentication+association exchange is aligned to beacon frames, and that is important.

The host uses power saving mode between beacons. The basic process is as follows: send beacon frame, wait for a while to see if any clients want to connect, then enter power saving mode until next beacon. There is a timer (W_POST_BEACON) that determines how long to wait before entering power saving mode. It is typically set to 10 milliseconds or so, which is more than enough for an authentication+association exchange.

But what happens when we try to emulate wifi communication over different protocols with different constraints? We have a synchronization mechanism that ensures everything is received on time, but it only kicks in after a client has connected. Before that, things are much less reliable, and the authentication/association frames may lag behind and arrive too late (like when the host has already entered power saving mode). This is exactly what is happening with LAN here. Sometimes the frames may be delivered the next time the host leaves power saving mode, sometimes it works but sometimes not.

And why was this not a problem before? Because power saving mode wasn't emulated correctly. It's all part of this post: I implemented channels, but things broke precisely because of the power saving bugs, and you know how this goes. Either way, we were kinda just receiving things at all times, which made things work.

So, how do we fix this bug, anyway? I could think of two possible ways.

First way, extending the synchronization mechanism to kick in earlier, during the auth+assoc process or even earlier. It could be worth exploring, but it is also likely to cause more problems than it would fix. The sync mechanism was designed around the multiplayer protocol especially, so I don't know how well it would perform outside of that use case, or if it could cause problems when connecting more than two players.

Second way, extending the post-beacon interval when receiving authentication or association frames. It is simply done by increasing W_POST_BEACON by 10 or so, making sure there will be enough time for the auth+assoc process to complete. However, it's a hack. It deviates from hardware behavior, and if anything is coded to expect a specific post-beacon interval (instead of just waiting for the post-beacon IRQ), it will cause problems.

I decided to experiment with the second way. It is less invasive, considering how heavy-handed the sync mechanism is. I also doubt that it will ever cause problems, since the post-beacon interval stuff is mostly used for power saving purposes. But if it ever does cause problems, we can always change it back (and we get to write another juicy tech blog post about it, heh).

It's a bit anticlimactic given our standards, but remember, emulation is a bunch of compromises. Especially when we have to emulate low-level wifi communication with its peculiar timing requirements.

In the meantime, this hack seems to have fixed the problems I had observed with getting connections going over LAN. It seems to work pretty smoothly now.]]> https://melonds.kuribo64.net/comments.php?id=210 https://melonds.kuribo64.net/comments.php?id=209 Sat, 10 Aug 2024 21:34:09 +0000
You may now grab it over at Github, in the Actions tab (you will need a Github account).

The way this works is the same, so I will simply copy-paste from that old post:


How to get a LAN game going:

1. On the host machine: open melonDS, then System -> Multiplayer -> Host LAN game. You enter a player name and you're good to go.

2. On client machines: open melonDS, then System -> Multiplayer -> Join LAN game. Enter your player name there, then it should list any existing LAN games. If not, you can always try using the direct connect button.

3. Once all sides are connected to the LAN game, you can open a ROM on each machine and try getting a game going. Do note that you will need a good local network for this to work. Ethernet should work, but anything else may fail if the latency can get too high. In my experience, wifi has too much latency.


This marks the end of season 3, and the beginning of season 4: netplay. Ironically, netplay was the original goal of season 2 -- LAN happened more or less as an experimental side project, and it happened to work out rather well, so it stuck around.

So, stay tuned for the netplay adventures!


Also, we are working out how to properly label melonDS builds from the CI, releases and nightlies alike. When we figure it out, I will probably add the download section for nightlies.]]> https://melonds.kuribo64.net/comments.php?id=209 https://melonds.kuribo64.net/comments.php?id=208 Fri, 09 Aug 2024 19:13:14 +0000
Namely, the downloads page didn't do our project justice. It was just a very plain listing of all the melonDS releases since 0.1. Technically, it was a static page that I manually updated after each release.

But this is no more! Go check out the new downloads page.

Now it shows just the last melonDS release. However, if you go down, there is an extra page that will list all the older releases, just like the old download page. Except it's not a static page, so new releases can be added without having to modify everything by hand. I am even thinking of adding a Github hook to post releases automatically when they are posted there, but one thing at a time.

There is also another section named 'Misc. tools'. For now, there's nothing in it, but I plan to add all sorts of tools that are relevant to melonDS or DS emulation in general. For example the DSi dumper comes to mind -- there would be a stable place to get it rather than having to dig into the blog. I will probably add that in real quick.

(edit- I did; after 3 years, about time)

And there's a last section, that isn't finished yet: nightly builds.

The idea was to provide access to builds from the Github CI without requiring users to have a Github account. I coded a Github hook and a backend for it, which downloads the builds from Github onto the server, and keeps the last 100 commits. However, this raises a few questions.

We need to make sure nightly builds don't spread and cause confusion. Right now, any melonDS build just uses the same version number as the last release, which isn't ideal. We would need a way to properly identify builds to avoid confusion.

I also hope that releasing nightly builds doesn't end up killing the incentive to do proper releases.

So we need to plan this out a bit, but hopefully we will take care of it all soon.


Have fun!]]> https://melonds.kuribo64.net/comments.php?id=208