Home / Games / MelonDS updated to 0.4, Fixes several Bugs & adds Wireless emulation

MelonDS updated to 0.4, Fixes several Bugs & adds Wireless emulation

Developer StapleButter updated his DS Emulator MelonDS again to address and fix several graphic bugs and with more impact to include Wireless emulation in this build.

Sure wireless emulation was already available in the nightlies but with this, it is now officially in the stable builds of MelonDS. It still doesn’t work too well and has occasional connection issues and doesn’t support too many games just yet but it’s a start. It can already do more wireless than any other DS Emulator that is available until now.


Here is Staplebutter’s summary of things that have been changed in version 0.4:

The infamous boxtest bug that plagued several games has finally been fixed. The bug generally resulted in missing graphics.

The boxtest feature of the DS lets you determine whether a given box is within the view volume. Several games use it to avoid submitting geometry that would end up completely offscreen. A prime example would be Nanostray, which uses it for everything, including 2D menu elements that are always visible.

Technically, you send XYZ coordinates and sizes to the GPU, which calculates the box vertices from that. The box faces are then transformed and clipped like regular geometry, and the test returns true if any geometry makes it through the process (which would mean that it appears onscreen). This also means that the result will be false if the view volume is entirely contained within the box.

I had no idea where the bug was, as melonDS did all that correctly, and some tests with the libnds BoxTest sample revealed nothing. It turned out that the issue lied within the initial calculation of the box coordinates. When melonDS calculated, say, “X + width”, it did so with 32-bit precision. However, the hardware calculates it with 16-bit precision, so if the result overflows, it just gets truncated. And, surprise, games tend to rely on that behavior. Getting it wrong means you end up testing a different box, and getting different results. Hence the bug.

There have been various other improvements to the 3D renderer. Things have been revised to be closer to the hardware.

As a result, the Pokémon games look nicer, they don’t have those random black dots/lines all over the place anymore. The horrendous Z-fighting observed in Black/White is also gone.

Other games that suffered from random dots/lines around things, should be fixed too.

As well as things like wrong layering in UI screens rendered with 3D polygons.

The 2D renderer got its share of fixes too. Mainly related to bitmap BGs, but also a silly copypaste bug where rotscaled bitmap sprites didn’t show up.

But there have also been improvements to an obscure feature: the main memory display FIFO. If you happen to remember:

The display FIFO is another obscure feature — I don’t know of any retail game that uses it, but I have yet to be surprised.

And, when debugging rendering issues in Splinter Cell, I have been surprised — that game does use the display FIFO when using the thermal/night vision modes.The issue in that game was unrelated to that feature (it was bad ordering of rendering and capture that caused flickering), but it was a good occasion to improve display FIFO emulation. It atleast allowed me to finally axe the last DMA hack as the associated DMA now works like on hardware. The FIFO is also sampled to a scanline-sized buffer with the same level of accuracy.

This doesn’t matter when the FIFO is fed via DMA, but it enables some creative use of the feature — for example, you can write 16 pixels to the FIFO to render a vertical stripe pattern on the whole screen. Or you will get bad results should you try to use it the wrong way. All of which is similar to what happens on hardware.

Pushing for accuracy, the last few big things that magically happened instantly now have their proper delays emulated, namely SPI transfers (including backup memory SPI) and hardware division/sqrt.

Firmware write was implemented, meaning you can change the firmware settings from the firmware itself (to run the firmware with no game: System -> Run). A backup of your firmware image will be made should anything go wrong.And, last but not least: working wifi multiplayer. It was already spoiled, but regardless, it’s the first time DS emulation gets this far. And it doesn’t require an unofficial build! It’s there and ready to use.

It’s not perfect though. But it’s a start. Pictochat, NSMB and Pokémon are known to be working, but you might encounter spurious disconnects (or, more likely, lag). Mario Kart and Rayman RR2 refuse to work.

I added a setting (“Wifi: bind socket to any address”) which you can play with to try making wifi work better. It can make things better or worse. Try it out if needed. Leaving it unchecked should be optimal, but I was told that it doesn’t work under Linux.With all this, no work was done on the UI, despite what I had stated. My apologies for this. But the UI will be worked on, I promise!

It’s great seeing this Emulator progress so that we will hopefully have it surpass DeSmuMe in features and compatibility. It is already making great progress at that and if you have a somewhat nice PC you can run many games.
Source: MelonDS

About Darthsternie

Interested in everything Technical. Loves self-repairing Tech. Collector of Firmwares. Enthusiast Gamer and Anime Fan ^^

Leave a Reply

Your email address will not be published. Required fields are marked *