melonDS RSS

melonDS RSS https://melonds.kuribo64.net The latest news on melonDS. A couple notes about the Delta release -- by Arisotura https://melonds.kuribo64.net/comments.php?id=199 Wed, 24 Apr 2024 21:06:08 +0000

First, we the melonDS team are not responsible for third-party ports (with the exception of Generic supporting the Switch port, since he made it). Our scope is limited to the melonDS core and the desktop frontend (ie. the Windows, Linux and macOS versions).

If you are running into issues with Delta, or with any port of melonDS: you should contact the authors of that port. Members of our community may also be able to help you, but contacting the port authors directly may be quicker.

It is also worth noting that port authors are responsible for keeping their port up-to-date.

At the time of writing this, Delta is using melonDS 0.9.1 as its core, which is quite outdated by now. If you're running into emulation issues with Delta, chances are that the bugs have long been fixed, but you will need to bug the Delta authors to update their port. We have tried to contact them about this, but haven't received a response yet.

tl;dr: if you are running into any issue with Delta, or any melonDS port, please ask the authors of that port first.

Second point, emulation frontends like Delta, RetroArch or BizHawk (to name a few) are definitely impressive pieces of work, but it is worth keeping in mind that they wouldn't be possible without the work from the emulator authors who provide the cores these frontends use. So if you're considering donating towards these frontend projects, try to keep the underlying emulator core projects in mind too.

That being said, we have already seen an influx of new patrons, so thank you folks!

Third point, not related to Delta per se, but this is prompted by the situation: I'm planning a bunch of updates to the site.

Among the first updates, I added some extra measures against spam on the blog. Nothing very fancy.

Next update to come will be attachment support for the board. It has come to my attention that some of the old threads link images and assets from Discord, and Discord has been cracking down against hotlinking lately. So we will provide some space for people to attach images and stuff to their posts, that way it will stay on our server and not disappear on the whims of some external entity.

We're also open to your feedback regarding the site, the content, melonDS itself, ...

I do kinda want to post more content on my Patreon page, but I don't really know what to post there that wouldn't just mirror this blog. Regardless, in a move of transparency, I've made the earnings public.]]> https://melonds.kuribo64.net/comments.php?id=199 News of the great refactoring -- by Arisotura https://melonds.kuribo64.net/comments.php?id=198 Fri, 19 Apr 2024 09:09:07 +0000 this post I showed an attempt at running two melonDS windows at the same time. Just a silly test, but groundwork for more.

What became apparent during this is the fact that our current configuration system won't do.

The current config system was born out of simple needs: at the time we just needed to store a few configuration values. The keyboard and joystick input mappings, and misc settings like direct boot or 3D renderer threading. For this, a simple pseudo-INI format was deemed enough. The config file is named melonDS.ini, but it is just a simple key-value pair format with a custom parser, not an actual INI format.

The configuration data in melonDS is just a bunch of global variables in the Config namespace exposed to the entire program. The parser simply goes through all the lines in melonDS.ini, checks the key against a list of possible keys, and when a match is found, the corresponding variable is filled with the value that was read. The same list also serves to initialize the config data with default values (for example, if melonDS.ini wasn't created yet). All fine and dandy.

This system, however, doesn't shine in its flexibility. This started becoming apparent in 0.9.5 when the new local multiplayer system was added. I realized we needed a way to allow each melonDS instance to have different settings for things like input mappings. Prior, the only way to do that was to run the different instances from different folders.

The solution I had come up with, was to create other melonDS.ini files: melonDS.2.ini for instance 2, melonDS.3.ini for instance 3, and so on. melonDS.ini would contain the bulk of the settings: the settings that are common across all instances, and the settings for instance 0. Then, when opening a new instance, it will get the global settings from the main melonDS.ini, and its instance-specific settings from its specific config file. If said specific file doesn't exist, it is initialized from the main melonDS.ini.

It's nice and colorful, but a bit unwieldy...

When I started working on that proof-of-concept multiple window thing, I had a realization in the same vein. Basically, the config file also serves to store settings related to the window: size, layout settings, etc. For a multi-window feature to be useful, we want each window to have its own settings (say, having one window display the top screen, and another the bottom screen). Clearly, the current config system won't do here.

So what can we do? Find other creative ways to get around the lack of flexibility of the pseudo-INI system?

Nah.

Instead, we are going for a radical approach: replacing the pseudo-INI system entirely. We decided to go with TOML for a flexible config system. With a TOML file, we can store arbitrary amounts of entries, sub-tables, arrays, and so on.

For example:

RecentROM_0=/home/arisotura/ndsrom/sm64ds.nds
RecentROM_1=/home/arisotura/ndsrom/mkds.nds
RecentROM_2=/home/arisotura/ndsrom/sonic.nds
RecentROM_3=/home/arisotura/ndsrom/nsmb.nds
RecentROM_4=/home/arisotura/ndsrom/2d_latch.nds
RecentROM_5=/home/arisotura/ndsrom/a_blarg.nds
RecentROM_6=/home/arisotura/ndsrom/libfatdir.nds
RecentROM_7=/home/arisotura/ndsrom/pokeplat.nds
RecentROM_8=/home/arisotura/ndsrom/party.nds
RecentROM_9=/home/arisotura/ndsrom/httpget.nds

The recent ROM list in the current pseudo-INI format is basically 10 separate variables. If you want more than 10 entries in the recent files menu? You would have to add more variables.

In TOML, it can be stored like this:

RecentROM = [
"/home/arisotura/ndsrom/sm64ds.nds",
"/home/arisotura/ndsrom/mkds.nds",
"/home/arisotura/ndsrom/sonic.nds",
"/home/arisotura/ndsrom/nsmb.nds",
"/home/arisotura/ndsrom/2d_latch.nds",
"/home/arisotura/ndsrom/a_blarg.nds",
"/home/arisotura/ndsrom/libfatdir.nds",
"/home/arisotura/ndsrom/pokeplat.nds",
"/home/arisotura/ndsrom/party.nds",
"/home/arisotura/ndsrom/httpget.nds",
]

Then the RecentROM item is accessed as an array. The only limit on its length is decided by the UI code.

In a similar vein, multiple instances and windows can simply be handled by adding more data tables for them in the config file. It is possible to store them as an array of tables, but I chose to explicitly name them 'Instance0', 'Instance1', 'Instance2', and so on, to make the file more readable.

Obviously, this requires reworking the way melonDS accesses the settings. Just exposing a bunch of global variables won't do here.

So far, I added a simple wrapper class for TOML tables. Besides keeping the TOML library code in one place, it also allows me to handle default values and allowable ranges for integer values transparently. Then any given emulator instance can keep track of its own config table, as well as the global table. The current format isn't set in stone, but it gives me an idea how things should be laid out.

Of course, there is also code in place to convert pseudo-INI files to the new format if needed, so you won't lose your settings.

I am now in the process of adapting the frontend code to use the new config system. Easier said than done, because this is intertwined with the rest of the refactoring: basically encapsulating everything so that multiple melonDS instances can be run within the same process, without them sharing global state.

So, yeah. Slowly but steadily, we're getting there.]]> https://melonds.kuribo64.net/comments.php?id=198 Wifi fixes: channels and power -- by Arisotura https://melonds.kuribo64.net/comments.php?id=197 Wed, 10 Apr 2024 19:56:03 +0000
Anyway, I recently felt like getting back into melonDS dev. I figured that trying to fix some wifi bugs could help me build up momentum and motivation I'll need to finish the big refactor.

The point of the big refactor is to lay groundwork for turning netplay from a clunky proof of concept into an actual finished product. But netplay or LAN won't be very useful if the underlying wifi implementation is malfunctioning...

The first bug I looked at was that weird bug in Meteos: when starting a download play game, if you're using a DSPhat firmware, you will instantly get a connection error, but everything will work fine if you're using a DSLite firmware.

So I researched the bug, but the outcome was a bit disappointing. Long story short, it's a timing issue. The ARM9 starts wifi initialization and allows it about 44 milliseconds before deciding it has failed. The wifi initialization doesn't actually take this long, but on a DSPhat (or any console equipped with a type 2 RF module) the RF initialization includes an extra delay of 40 milliseconds. Changing the ARM9 cache timings fixes the bug.

Cache emulation is something we're looking at for the next release, as it may fix quite a bunch of these timing issues -- there have been preliminary tests and it's looking promising. But in the meantime, that particular bug goes beyond my scope.

No biggie, we have a plethora of other problematic games. In particular, I had gen4 Pokémon games in mind. In these games, players can meet into the Union room where they can decide to chat, battle, etc... but the Union room was said to be malfunctioning in melonDS if more than two players were in it.

I first ran into some 'easy' bugs. For example, melonDS would not generate different MAC addresses for extra instances when using an external firmware. I also had to obtain different savefiles -- the game will get confused if multiple players using the same save file try to connect.

Past that, I figured that the issue might be caused by the lack of wifi channel support in melonDS. You probably know about wifi channels: the 802.11 standard specifies a set of 14 channels, which correspond to specific frequencies.

The tricky part is that on the DS, you don't have an explicit, clear register to tell it to "tune in to channel 6". Tuning to a channel is done by changing a bunch of RF and BB registers with values that are stored in the console firmware. Some of these values seem consistent across units, some of them are different. The way they are structured also depends on the RF type used in the console.

So the way melonDS dealt with this was to... just ignore channels entirely. We're just receiving everything at all times. Which I figured might cause problems...

I decided to base myself on RF registers to detect the current channel, as it seemed to be the most reliable way. I was thinking of how to implement it all. I eventually thought, we already read the firmware to determine which RF type to emulate, might as well pull the required register indices and values for each channel from there. Then, whenever the corresponding RF registers are modified, we check them against the values from the firmware to determine which channel we are tuning in to.

Next it's a simple matter of adding the current channel number to the frames that we send out. When receiving frames, we check their channel number against our current channel, and discard them if they're on the wrong channel. Simple.

In the end, I don't think the lack of channel support was the problem, but implementing them gave me useful insight.

To make sure I wasn't breaking anything basic, I tested the WFC config utility in Mario Kart, and started an AP scan. It did not find melonAP. Oops.

The AP scan basically cycles through all 14 channels, sending a bunch of probe requests, listening for responses, then moving to the next channel, and so on. When I looked at my logs, I saw that it was only actually sending frames on channel 1, and melonAP is set to channel 6, so you guess how that goes.

Upon closer inspection, it was failing to send frames on channels 2 and up because it was stuck in power-down mode. When changing the channel, there is a sequence to power down the transceiver, change the channel, then power it back up.

In this case, melonDS wasn't recognizing the instruction to turn the power back on. The power system of the wifi hardware is kind of complex and there is a bunch of different registers affecting it, and the support in melonDS was incomplete.

The issues other games had when trying to connect more than 2 players came from the same problem. Transceiver staying powered down for too long, causing starvation -- when trying to listen to beacons, the game would just see nothing for extended periods of time, then be receiving a ton of frames at once, which doesn't bode well. In some cases this would happen while other instances were already engaging in a MP data exchange, and the game would be completely overwhelmed from receiving an absolute ton of MP frames at once.

You guess how that goes.

The wifi power system is a bit complex, I've done a bunch of research but there's a lot to be said and there are still some unknowns. But I have a better view of how it all works and how the various registers interact.

I am still reworking the implementation in melonDS. It's unfinished, but the results so far are promising.

Mario & Sonic at the Olympic Games, one of the problematic games. Now connecting 4 players, smooth as butter.

I may write another post about the details of the wifi power system when I'm done with the implementation. Stay tuned!]]> https://melonds.kuribo64.net/comments.php?id=197 Quick news -- by Arisotura https://melonds.kuribo64.net/comments.php?id=196 Mon, 19 Feb 2024 23:39:17 +0000

This is just a quick attempt at supporting multiple windows. There's still a whole pile of issues to fix, but it's looking promising so far.

This is not only part of the ongoing refactor, but would also pave the way for separate windows, a feature that has long been requested.

I'm having a bit of a question there: if we got multiple windows, which one should have the OSD? The main window? The currently active one? All of them?

Other than that, sorry for the lack of updates lately. January has been rough for me, but things are getting better. I've also been caught in a fun side project that involves reverse-engineering (and emulating, heh) ancient FPGAs. Maybe I could have a sort of personal blog for non-melonDS projects of that kind, or just personal stuff in general.]]> https://melonds.kuribo64.net/comments.php?id=196 Merry belated Christmas -- by Arisotura https://melonds.kuribo64.net/comments.php?id=195 Thu, 28 Dec 2023 14:51:23 +0000

As I have received and set up my new laptop, I've been able to work on melonDS some. The goal is still the same: to adapt melonDS for supporting multiple instances within one process.

The frontend is proving to be tricky, because it was largely built without many regards for code quality. Originally, the frontend was just quickly built around the program entry point in main.cpp, as it just needed to provide a means to use the emulator. We had a simple window, a dedicated thread to run the actual emulation, and that was it.

Obviously, over time we added various features to the emulator, rebuilt the frontend around different UI toolkits, piled on more features, and so on. Basically, the frontend code became a mess, and everything was more or less just dumped in the global namespace -- there are some modules which live in their own namespaces, but it's all not very modular, and doesn't lend itself to running multiple instances of melonDS.

I started by splitting main.cpp into separate files. We are far from done with the cleanup, so there's a lot of cruft around, but the basic idea is the following:

* main.cpp just holds the entry point (main()) and global application-related stuff.

* Window.cpp holds the MainWindow code, for managing the emulator window. We may also add support for multiple windows.

* Screen.cpp holds the ScreenPanel code, that is, the panel widget that goes inside the emulator window and handles display and touchscreen input. There are two kinds of ScreenPanel: one that relies on Qt's graphics API, and one that uses OpenGL.

* EmuThread.cpp holds the emulation thread.

From there, each EmuThread would hold its own instance of the emulator core (which we mostly finished porting), and optionally point to one or two windows to display to (or none, in the case of a headless instance).

After laying out this basic separation, I figured it would make sense to integrate the OSD feature into ScreenPanel. The OSD module was a bit of a mess, with having to maintain different code paths for Qt or OpenGL drawing. Now things are a lot cleaner.

There's still quite a bunch of global state and stuff that we need to adapt before the dream of emulating multiple DS's within the same process can come true. But we're getting there, slowly but steadily. This is the perfect occasion to finally clean up and improve our frontend code.]]> https://melonds.kuribo64.net/comments.php?id=195 Long-due status update -- by Arisotura https://melonds.kuribo64.net/comments.php?id=194 Sun, 17 Dec 2023 13:33:22 +0000
What's new since the last post? I had started working on refactoring the melonDS codebase for the ambitious changes to come. JesseTG mostly finished the work on the core, so that's one big thing out of the way.

The frontend code is now going to need adequate refactoring too. That's, well, more work. We'll get there over the coming days.

On my side, I (finally) ordered a new laptop, so I'm waiting to receive it and set it up before I do more big work on melonDS.

I will need a while to adjust to the new changes that have been done to the melonDS core. It's also likely not perfect, we will likely have to do more work to clean up and harmonize the codebase. But atleast, the biggest part of the work is done.

On the frontend side, we need to add support for multiple different emulator windows. Historically, the frontend was structured around one emu thread and one emu window. The latter provides a means to display the emulator's video output and lets the user interact with the emulator, the former feeds the inputs into the melonDS core, runs it and manages it.

It wouldn't be difficult to spawn multiple emu threads, one per emulated DS. Window management is another deal. We thought we might want to support attaching multiple windows to one emu thread, for example to support displaying each DS screen on a separate window. For netplay purposes, we might also want to support headless instances, that is, running an emu thread with no window attached, no sound output, and inputs received from the network.

This also poses the question of OpenGL context management, all things we will need to look into.

We'll get there. It just... takes time.]]> https://melonds.kuribo64.net/comments.php?id=194 Happy birthday melonDS! -- by Arisotura https://melonds.kuribo64.net/comments.php?id=193 Fri, 03 Nov 2023 23:31:32 +0000

(if you're wondering about these colors: I have synesthesia, that's all)

I'm sorry for the lack of new releases since 0.9.5. It's been one year. That being said, we have big plans for the next release. I'm not going to go in length about these, the previous posts detail the plans well enough.

Just bear in mind that we're currently refactoring the melonDS codebase, so things may get a tad unstable while this is ongoing.

Other than that, it is a bit of a miracle that melonDS has been going for so long, and that after so long we're still around and coming up with ambitious plans. I've had several other personal projects, and none of them made it far past the one-year mark (or I only still work on them in a much more sporadic manner, like blargSNES). So, long live melonDS.

On my side, I quit my antidepressant in September, which went much more smoothly than I imagined. I've had a few bouts of depression since then, but nothing really bad, it's completely incomparable to what it was last year, and it's progressively getting better. I'm hopeful.

I tried Ritalin again, but it seemed to make me depressed after a while, so that's a bummer. I have a few ideas for other possibilities, but in the meantime I'm back to being unmedicated. Since this is how it's been for most of my life, I have coping strategies already, but the low energy part of it kinda sucks.

May 2024 be filled with success.]]> https://melonds.kuribo64.net/comments.php?id=193 The RTC rework is done -- by Arisotura https://melonds.kuribo64.net/comments.php?id=192 Tue, 31 Oct 2023 10:17:42 +0000

melonDS has got a fun little dialog for changing the date and time now.

Basically what it does is show you the current date and time of the emulated DS. You can change it to any date and time, or you can reset it back to your computer's date and time.

What you set is saved as an offset in seconds from your computer's time. Every time you launch a game, the computer's time is used as a reference to calculate the emulated DS's time, and then melonDS does its own time counting from this point.

This also means that, unlike the previous behavior, if melonDS runs too slow or too fast, it will affect the passage of time for the emulated game from your perspective. The point is to keep melonDS's time counting accurate from the perspective of the game.

This was also the occasion to rework the RTC emulation itself, because it was quite lacking.

For example, when returning the current time, it would simply return the current hour from 0 to 23, ignoring the AM/PM flag that is also encoded in the hour register. It gets a bit weird, because the way this register works depends on the 12/24-hour setting in status register 1. In 24-hour mode, the register goes from 0 to 23, and the AM/PM flag is automatically based on that. In 12-hour mode, the register goes from 0 to 11, and the AM/PM flag needs to be set properly for things to function.

I was also able to add support for writing to the date/time registers. This means that for example, you can boot the DS firmware and change the time from there, and melonDS's date and time setting will reflect that. Perhaps not very useful, but a nice touch regardless.

There is also the part where, in the DS, the RTC is powered by the battery. This means the RTC state isn't reset unless the battery runs out or is removed. I made melonDS save the RTC state between runs to mirror this: if you notice a new rtc.bin file, that's what it is.

Then there's the fun part: the RTC IRQ. Basically, the RTC has several alarm modes that will trigger an IRQ based on different conditions. The alarm interrupt mode will trigger the IRQ based on day of week, hour and/or minute, much like an alarm clock. Then there are other modes for simple per-minute interrupts or for firing at specific frequencies. All fine and dandy.

A prime example is libnds, or atleast the older versions of it, where they used the RTC IRQ to keep track of time. In more recent versions, they moved away from it, mainly because the RTC IRQ doesn't work on the 3DS in DS/DSi mode.

Regardless, this use case isn't difficult: they use the selected frequence steady interrupt mode to fire an IRQ every second. With support for this, these older libnds homebrews are no longer stuck in time.

I also looked into the DS firmware's alarm clock feature. The alarm clock screen does its own counting, the RTC IRQ is only really used when the DS is closed: while most of the DS hardware is turned off, the RTC still functions, and its interrupt can wake up the rest of the hardware (much like the 'lid open' interrupt that fires when you open your DS).

I had to rework melonDS's implementation of sleep mode to get this to work (and also, you know, to get the RTC to count while in sleep mode in general). Kind of a pointless detail, I doubt anybody out there will be using melonDS as their alarm clock, but still a nice touch. Also helps make for more accurate emulation in general, so hey, I'll take it.]]> https://melonds.kuribo64.net/comments.php?id=192 RTC and ambitious plans -- by Arisotura https://melonds.kuribo64.net/comments.php?id=191 Thu, 26 Oct 2023 10:06:25 +0000

The RTC, aka Real-Time Clock. The DS uses a RTC chip to keep track of the current date and time. melonDS has had some RTC emulation since the early days, because it was a requirement to get the firmware to boot, but since then, that RTC emulation has been pretty much barebones. Basically, all it does is return the current system time from the host. While it's good enough for the most basic purposes, it comes with a number of downsides.

For example, we've had several requests from end users about changing the time inside melonDS. Currently, the only way to do that is to change your computer's time. melonDS offers no UI for setting its own time. It is possible to boot into the firmware and use the settings menu there, but melonDS ignores writes to the RTC date/time registers, so it just reverts back to the host system time. Less than ideal.

This is also a problem for netplay. The basic idea behind netplay is that all players run the same emulation, and inputs are synced across them. For this to work, you need to ensure that for all players the emulation starts from the exact same state, and that the inputs are the exact same for everybody. Since games use the RTC to initialize their random number generators, all sides need to start from the exact same time, or they will desync. So the basic, "let's just return the system time" RTC won't do here.

Then there's also the fact that this RTC emulation we have is incomplete. The RTC does more than just keep the current time: it features several 'alarm' settings that can trigger interrupts, for example. libnds uses that feature to do its time counting, so if you run any libnds homebrew in melonDS, it will seem stuck at the same time.

The DS firmware also has an alarm clock feature. While I doubt anybody out there is going to use melonDS as their alarm clock, emulating it would be a nice touch.

Regardless, I started working on the RTC yesterday. The first part is to have the RTC in melonDS do its own time counting. The RTC in the DS is likely controlled by a 32768 Hz clock, as is typical for these things, so I did something similar in melonDS, as it will be a requirement for emulating the alarm interrupt features.

I used the system event scheduler in melonDS for this purpose. It is technically inaccurate, because the scheduler runs on the DS system clock (33.51 MHz), but it provides a reliable way to keep the emulated RTC in sync with the rest of the system. I had to get a bit fancy to correct for the inaccuracy from using the system clock as a base, but nothing bad.

From there, I laid down the basic idea of a clock. Have a bunch of registers for the current date and time, count one second every 32768 RTC ticks, count one minute whenever the second register reaches 60, count one hour whenever the minute register reaches 60, etc... You get the idea. As there's currently no way to tell the melonDS core which time to use on startup, it starts at 01/01/2000 00:00:00, but it does count up properly so far.

Next step will be to do some hardware tests to figure out some details. For example, the date/time registers are BCD, which means that for example a value of 24 is represented as 0x24 (decimal 36, 2*16+4). Since they are writable, I need to determine what happens if invalid BCD values are written. For example, say the register's value is 0x29, when it will be incremented, the next value will be 0x30 and not 0x2A.

0x2A wouldn't be a valid BCD value, so what happens if I try to write that to the register? It could be rounded down to 0x29, or rounded up to 0x30, or the write could be ignored entirely, or it could actually accept a value of 0x2A and behave weirdly because of it, so I need to figure this out. This is an off-the-shelf RTC chip, so chances are it's well-behaved, but it's not exactly like there are no precedents of DS hardware accepting whatever garbage inputs and doing weird shit.

Then I will have to implement all the alarm interrupt features and all, and provide a way to set the time in melonDS, and this should be good.

Then the ambitious plans.

This was an idea that we put off before due to the amount of work required, but JesseTG is giving us a much welcome boost in ambition. Basically, he is making a Retroarch port of melonDS, and a lot of the work he's putting into it is going to be very useful for netplay.

For example: when starting a netplay game, we want each side to start from the exact same state. I figured that using the existing savestate system for this purpose would be adequate: just save the initial state on the host, then broadcast that to the clients and they just have to load it, and boom, most of the work is magically done.

The problem I originally ran into was that said savestate system was designed to interact with files directly, so getting around it was hacky. JesseTG modified it to work on memory buffers, which is exactly what we need here. This change will also be welcome for Generic's Switch port, where savestates turn out to be slow due to the sheer amount of file I/O calls.

Anyway. The plans.

In its current state, melonDS is designed to run exactly one DS per instance. This proved to be a bit of an issue for local multiplayer. In the early days, the strategy was to just run multiple melonDS instances, have them toss around packets over UDP, and pray that it would work. But we do things in a more refined way now.

The ideal way to do local multiplayer on one machine would be to run multiple DS's inside the same melonDS instance. Thus, there would be little to no losses in the multiplayer data exchange. But the main issue with this is that, well, the melonDS codebase doesn't lend itself well to this. At all.

So instead, we went for the technically easier way. We just run multiple instances of melonDS and sync them via IPC mechanisms. Essentially, they use shared memory buffers for data exchange and shared semaphores for synchronization.

There are multiple issues with this design, though. First, it is not ideal from a performance standpoint. Inter-thread communication from within the same process is easier and faster than inter-process communication. The shared semaphores we need to use are named semaphores, which are a special type of semaphore and aren't really optimal for performance.

Another issue is making this work in netplay. With having to deal with multiple processes across multiple machines and keep all of it in sync, there are many moving parts and many ways things can go wrong. If we only had to deal with one melonDS instance per machine, it would make things a lot simpler.

So you can see where this is headed.

Adapting melonDS to support multiple DS's per instance.

In the current state of things, the melonDS core is largely a collection of namespaces that roughly represent the DS hardware components. Certain of the components are already classes, because they need to be instanced multiple times: the ARM CPUs, the 2D GPUs, the SD/MMC controllers for the DSi... But for the rest, it can only be instanced once, because it's just a namespace.

For what we want, all of these components need to be converted to classes. Which you guess isn't going to be a walk in the park. This is the kind of change that will conflict with every existing branch, pull request, etc. Existing ports of melonDS will need to be updated accordingly. And so on.

We're going to plan this out and take it easy. I'm realizing that after nearly 7 years of ongoing development, melonDS has become quite a big and complex project.

Stay tuned!]]> https://melonds.kuribo64.net/comments.php?id=191 LAN multiplayer: getting there! -- by Arisotura https://melonds.kuribo64.net/comments.php?id=190 Sat, 07 Oct 2023 15:17:51 +0000

LAN gameplay between the two computers I have at hand over here.

LAN is actually fairly close to a finished product, now. It's obviously still a bit rough around the edges, may be a tad unstable, but from my testing it has shown to be pretty smooth.

From this point, I encourage anybody who is interested to grab the experimental builds from our Github CI. It's the runs labelled 'season2 test PR'; note that you will need a Github account to download them.

But if you're motivated, please give them some deep testing, abuse them in whatever ways you can think of, and report anything that seems odd to you, in our IRC or Discord or in this thread. We'd like these features to be rock-solid for the 1.0 release.

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.

That should be about it. There are also options pertaining to netplay, but for now, it doesn't work. I had managed to get it working as a very crude proof of concept, but due to changes in the melonDS codebase since then, it's broken. I will let you know when I can get it working again.

Have fun!

EDIT- clarification on the terminology:

LAN is for playing local multiplayer games over a local network (ie. multiple computers in the same house for example).

Netplay is for playing local multiplayer games over the internet.

Neither of these apply to online multiplayer (aka WFC).]]> https://melonds.kuribo64.net/comments.php?id=190