melonDS 0.4 -- It's here, finally!

melonDS 0.4 was long awaited, and finally, it's here!

So here's a quick rundown of the changes since 0.3. I'm keeping the best for the end.

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 anythig 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!

You can find melonDS 0.4 on the downloads page.

Patreon for melonDS if you're feeling generous.
Mike says:
Jul 16th 2017
Hey man! I've been lowkey following the DS emulation scene for /years/. Still can't believe I'm seeing history unfold before my eyes with your solving of the field's biggest mystery in wifi and all. You, my good sir, are a miracle worker. Thanks for your excellent work! :)

Also, first. Hoho.
telon22 says:
Jul 16th 2017
Excellent WORK!
You have my thanks for this!
DexterColt says:
Jul 16th 2017
Thank you so much for doing this, this is completely amazing, I can't thank you enough for this!
If it's not already there, please consider adding a function that allows you to import save files from other emulators.
Somerandom user says:
Jul 16th 2017
can you test some more 3d graphics like lego games, or some mario 3d games?
AsPika2219 says:
Jul 17th 2017
Thanks for working WIFI games! Please test more games which worked on Desmume and no$gba before!
I hope you continue working WIFI on Desmume VERY SOON™!!! :D
Someperson says:
Jul 17th 2017
Has this been optimized to work well on very low end PCs yet? Like i have an AMD A4-5000 APU clocked @1.5 GHz with 4GB of 1600 MHz RAM & no dedicated GPU so it would be nice if i can play things like Pokemon smoothly.
Rin Tohsaka says:
Jul 18th 2017
In response to "Someperson" above, that CPU is unfortunately a poor choice for emulation - the A4-5000 gets its strength from a (relatively) fast GPU and having 4 CPU cores.

Emulation for any system weaker than the PS2 generally only cares about having one or two fast CPU cores and nothing else.

By comparison, any 10-year old Core 2 Duo even with el-lame-o Intel integrated graphics is going to perform better at DS emulation if software rasterization is being used, and possibly even with hardware rasterization (though 10-year-old Intel GPUs probably don't support the necessary graphics APIs that modern emulators expect for hardware rasterization).
AsPika2219 says:
Jul 18th 2017
Please add 32 bit support for future version of melonDS, plus waiting for AR codes, codebreaker etc...
Rin Tohsaka says:
Jul 21st 2017
In response to "AsPika2219" above, a 32bit version seems unlikely considering that any x86 CPU that doesn't support 64bit is going to be too slow anyway.

(most common examples would be the Athlon XP, Pentium 4, Pentium D, original Core Duo, and 1st gen Intel Atom)
AsPika2219 says:
Jul 21st 2017
OK! Sound likes waiting for JIT fuctions to make speed faster OR I think some source codes was control the speed system.
AsPika2219 says:
Jul 21st 2017
Oh yeah! There another emulator called MEDUSA (for Nintendo DS) was created by Jeffrey Pfau (also makes mGBA emulator). This guy was professional reverse engineering and focus speed, accuracy etc... Visit here for information!
Post a comment