Happy birthday, albeit late
It turns out that melonDS is two years and 20 days old, counting from the first serious commit. So:



Too many candles there? Nah! That's just the melonDS company being generous.


So, the usual bit of retrospective. We're not going to repeat the whole history, you can read that on the one-year post.

Anyway, reading the DeSmuME commit log shows that they're trying to play catch-up.

Ironically enough, they finally took their wifi system out from behind its EXPERIMENTAL_WIFI wall, and exposed the settings to their users. They even went as far as fusioning the old 'adhoc'/'infrastructure' modes (basically selecting between nifi/local and internet/WFC), akin to melonDS where the setting just doesn't exist-- it's always running both modes at the same time.

A few notes on that, for those who are interested into DeSmuME altWFC:

* You need a recent DeSmuME build, such as those produced by their buildbot. Not the 0.9.11 release from 2015.
* It functions the same way as melonDS, you need libpcap and an Ethernet connection.
* They haven't yet been fixing the underlying issues in their wifi stack or maybe even emulator core. For example, Mario Kart DS races don't work, while they do on melonDS. (I do not know what causes the issue in DeSmuME though, haven't faced it at all in melonDS, so I can't help there)

However it is nice that they're finally reconsidering their stance on what was largely my work, and giving it some spotlight.

It's also nice in that melonDS is achieving one of its goals there, not regarding wifi but in a more general sense. One of the reasons behind this project was the state of the DS emulation scene at the time. melonDS showed a clear intention of disrupting what was an increasingly stale scene, injecting some fresh blood into it and hopefully encouraging further development by an effect of emulation (heh).

Well, seems we're getting there!


So, I want to take a while to thank all of you comrades who have helped make this possible, be it by providing amazing documentation, testing games, reporting bugs, suggesting fancy things, making videos, donating on Patreon, or whatever else that has ever helped me. melonDS is not a one-man show, we are in this together. Thank you for your support! And the whole DS scene can thank us all too as everybody benefits from this.


As for year 2018, it wasn't full of a lot of awesome melonDS development, mostly because it's largely been a shitshow. But the pace is picking up again, so, may 2019 be a better year.


Here is a quick roadmap for further melonDS releases.

0.8 will be when we have a decent OpenGL renderer. So we can pull awesome shit like upscaling or Switch/Android/whatever ports that don't run at crapoed-snail speeds. Might also give a speed boost on desktop. The current renderer is a bottleneck when it's used for serious 3D scenes. But hey, it's nearly pixel-perfect and makes for authentic DS graphics experience! :P



If you enjoy licking the bars in that level, you get an accurate render of that quirky texturing. Who would want upscaling or other graphics enhancements when you have THIS?

:P

In a more serious note, that also happens to be GPU-related, the more immediate roadmap, for what would be version 0.71 or so.

0.71? 0.7.1? 0.7b? 0.7.zog? What would be the best there? Can't immediately go to 0.8, I promised it'd be the OpenGL renderer release.

Anyway.

This intermediate release will be that of timing renovation and primped up wifi connectivity. Which will, you guess, need a bunch of testing to make sure it's going okay and we don't end up shipping a 0.8 whose awesomeness is completely undermined by timing bugs.

The timing renovation includes GPU timings too. For now, these are only the geometry engine timings, which dictate how long display lists take to run. On the other side, rendering engine timings would basically be the time taken to draw polygons, and therefore emulating glitches arising from having too much shit onscreen. This is a whole other can of worms we aren't opening for now.

I talked a bit about the geometry engine timings in the last post, but actually, it's a bit more complicated than what I stated.

For example, vertex timings. Each time I came up with a model for those and how they interacted with other commands, I always found test cases that contradicted this model. The answer is that vertex timings aren't uniform. Each vertex which completes a polygon will take longer to execute and impose rules on when the next vertex commands can run. Vertex commands themselves can take 4 or 6 cycles (add one cycle for a full 16-bit vertex) depending on which command follows, there is parallel execution going on. However, the time required for building a polygon is 28 cycles for a triangle and 37 cycles for a quad. And, for example, after completing a triangle, the next vertex can only start 10 cycles later, the one after that needs to be atleast 9 cycles later, and so on.

So, yeah. I have yet to test all the commands I can test to determine how they behave relative to vertex commands. For example, for some weird reason, command LIGHT_VECTOR needs to wait until the polygon-building process has completed, which can slow things down a lot if you're changing light directions per polygon. LIGHT_VECTOR is a bit of a snowflake though, most commands seem to parallelize fine.

Also, as a phun side note, the lag spikes I was getting in SM64DS were caused by a bug in how I counted cycles during GXFIFO stalls. Now it seems to be happy with the GXFIFO stalls even without touching the GPU timings. Maybe it's meant to work this way after all? That might be why they made it run at 30 FPS.

Oh well.

The other bit of this release would be, basically, making the whole online wifi shit more user-friendly. Like, actually finishing that feature. Making it work under Linux and with npcap and all that. Making it work with a wifi connection, or even Bluetooth, IR, radio, smoke signals, or whatever you like, which will require adding in a small DHCP and NAT.


The melonDS adventure isn't over! May it continue forever. Thank you all!
Sorer says:
Nov 23rd 2018
I wish there was a way to get rid of using winpcap at all.
So many emulators that emulate online networking are using it and it's so restrictive.
I know PCSX2 uses winsock to kinda alleviate the problem but it also still uses winpcap.
I wonder how Dolphin is doing the WFC emulation without using winpcap tho.
Daemon says:
Nov 23rd 2018
>I wonder how Dolphin is doing the WFC emulation without using winpcap tho
Read the code?
StapleButter says:
Nov 23rd 2018
Dolphin (and other emulators for modern consoles) are able to HLE the console's communication layer, which more than often is just plain old BSD sockets or close enough, and pass it down to the host socket implementation.

it's different when you can't HLE because all you're getting is, well, raw packets. the winpcap method is the easiest one for routing those to the actual network. an alternative would be deconstructing the TCP/UDP flows and feeding them through sockets, but this is quite more work than just passing things around.
Sorer says:
Nov 23rd 2018
>Read the code?
I am Not a developer but i know how emulators work.
Thanks StapleButter for the explanation.
Daemon says:
Nov 24th 2018
>but i know how emulators work
pretty sure you don't
StapleButter says:
Nov 24th 2018
ffs Daemon can you stop being a dick
SonicBlader says:
Nov 24th 2018
Wow! Has it really been more than 2 years? I still remember when the first build of it was released! You have done some really great work StapleButter! :D

As for the version numbering, personally, I would prefer 0.7.1 and 0.7.2 and so on. Others seem a bit weird.
extherian says:
Nov 24th 2018
If you go develop an OpenGL renderer, please render everything on the GPU, geometry included. The way DeSmuME is now, the resolution you can run at is capped by your CPU clock speed when it really out to be entirely GPU dependent. I can't render the opening scene of Spirit Tracks at higher than 3x native because my 3.9GHz CPU isn't fast enough to go any higher.

I understand that the Nintendo DS GPU doesn't map well to OpenGL, but there's no point in writing an OpenGL renderer at all if you just repeat the mistakes DeSmuME made with theirs. I can wait for a properly written hardware renderer, it doesn't have to be ready by version 0.8. I don't care how slow it is as long as it's GPU bound, not CPU bound. If it's worth it doing at all, it's worth doing it right.
hammy3502 says:
Nov 24th 2018
Thanks for all the awesome work StapleButter! Even though I only found out about the project around version 0.6, it's still been amazing to see it evolve and to finally have a DS emulator that has wifi! Thanks again for the amazing work :D
StapleButter says:
Nov 25th 2018
Not sure we can do really everything on the GPU. Early DeSmuME versions did that, for instance (merely mapping GX commands to their OpenGL equivalent), and there were a number of issues with it. The GX sorts polygons based on a number of criteria, and there are things that rely on it. Also, the polygon and vertex lists are limited in size, which means we have to do our own culling and clipping or we run out of space pretty quick on intensive scenes.

That being said, quick testing shows that geometry engine emulation in melonDS (transform/lighting, polygon setup, culling, clipping, viewport transform) is far from being a bottleneck. Which is also what some profiling sessions show: as far as 3D graphics are concerned, the bottleneck is the rasterizer. So running that part on hardware should speed it up nicely. And similarly, if we increase the rendering resolution, what will end up needing more processing power will be the rendering engine, not the geometry engine (as this isn't generating more polygons).

I don't know how much of a hit we get from the command interpreter, but I can't really test that accurately-- 3D games tend to get stuck if the GXFIFO is taken out. Not that we can emulate that part in OpenGL anyway.
Post a comment
Name:
DO NOT FILL