We're alive!
I know things are slow lately, but there's still some shit getting done! Mostly taking care of low hanging fruit.


For example, I felt like dealing with issue #598. Which was the same problem as the older #379, by the way.

The base issue was that some polygons ended up sliiiightly offscreen (getting a lower Y coordinate of -0x1001 when the view volume bound is at -0x1000, for example). Not an issue with how coordinates are calculated, mind you. On the DS, polygons can be slightly offscreen like that and be clipped without any issues. But in the case of melonDS, due to how clipping was done, the texture coordinates of the vertices that stuck out would end up altered, resulting in a misaligned texture.

Ironically, using OpenGL appeared to fix the issue, but only because the way OpenGL applies textures is inaccurate to the DS hardware (which in itself causes a bunch of other texture alignment issues). So in the end, the two issues compensated eachother for a visually perfect result.

The software renderer, on the other hand, aims at replicating the original DS renderer as closely as possible, which in the end makes it more sensitive to little details like this.

Regardless, looking at the formula melonDS uses to clip polygons that are partly offscreen, it appeared that swapping the inner and outer vertices gave results closer to what the DS produced, so I did exactly that, and it ended up fixing the aforementioned issues.




So, one step closer to pixel perfection, I guess. Even though we aren't quite there yet; you might notice that the screenshot from Brain Puzzles are exhibiting another glitch that wasn't fixed.


Also, I finally took care of properly handling ROMs with encrypted secure areas (which is the case of the Virtual Console dumps, for example). Before, those could only be run by doing a full firmware boot, now they can be run via direct boot without issues.


On a bigger scale, well, we're still trying to find a good solution for the UI shit. I'm at a point where I'm envisioning the craziest options, like giving in and using Qt.

I dropped the FLTK option because FLTK uses raw pixel positions for everything, which isn't going to be too good for hiDPI support and such.

I also want to attempt things regarding local multiplayer, but it's going to be a bit of a gamble. The basic idea would be running the wifi subsystem on its own thread with a specific timing mechanism, as to ensure more reliable operation. But, not quite sure how well the emulated software is going to appreciate that.

As a side note, on the DS, the wifi system runs off its own 22MHz clock (and not the 33.51MHz system clock), so I guess that doing so wouldn't be too inaccurate. However, on the DS, things are running at more or less the same rate always.

On the other hand, in melonDS, the actual rate at which things run depends on how fast the host machine can run it, and it's impossible to reach perfectly homogeneous timing due to how the emulator works. You can use the throttling mechanisms, like the framerate limiter, audio sync, or vsync. But those kick in between entire frames, so essentially you're running an entire frame as fast as possible, then sitting around until it's time to begin the next frame. Finer throttling would reduce the gap, but would also be likely to slow things down, as the emulator isn't running homogeneously and some things take more time than others (and some things are performed all-at-once instead of being a cycle-per-cycle process like in the DS).

This is why local multiplayer doesn't work well in melonDS (and this is also why disabling throttling makes it work better). It's going to run too fast, then halt, then run too fast again, and so on. Meanwhile, in melonDS the wifi system is currently driven by the core scheduler (running one 'microsecond' every 33 cycles), so it's going to be affected by the whole on-and-off thing. You guess this doesn't bode well with the local multiplayer protocol, given how it works and the tight timings it requires.

Running the wifi system on its own thread would allow the local multiplayer exchages to function better, depending on how reliable the network is. However, it would do so at the expense of the timing between the emulator core and the wifi system. It's hard to predict how games will react to that, given we are emulating the wifi system at a low level (to give you an idea, we do emulate the transmission/reception delays for packets, not sure how much the software requires this).


Oh well, we'll see.


The Melon Factory of Kuribo64 hopes that you are well.
Peduls says:
Apr 12th 2020
Glad to see work on this emulator is still going strong! Very excited for local multiplayer. Can't wait for 0.8.4. and the option to turn "randomize MAC address" on/off.
Dsfab22 says:
Apr 12th 2020
What about internal clock so in Pokémon games berries and other events will work when not haveing emulator running
Nixel says:
Apr 12th 2020
Nice to hear! About the polygon clipping thing, does this also affect 3D stuff? The examples all show 2D UI stuff, but I would think there are also cases where 3D terrain runs into similar issues, right?
poudink says:
Apr 12th 2020
that "2D UI" is rendered using the 3D engine, so it's 3D as far as the DS is concerned.
MelonMan says:
Apr 13th 2020
Stay safe everyone! This emulator is just getting better and better. I don't have much experience with C++ but NanoGUI (https://github.com/mitsuba-renderer/nanogui) seems good. It mentions using OpenGL as a backend. Again I have no clue how it works but I hope this suggestion helps!
AsPika2219 says:
Apr 13th 2020
Waiting on next version! Keep moving forward!
Marck says:
Apr 14th 2020
Congrats for the Melon Factory!!!
ZELDA says:
Apr 14th 2020
there any different if you use vulkan as backend ?
poudink says:
Apr 15th 2020
melonDS has no vulkan backend, and I doubt it will have one any time soon, since it would be quite a bit of work to implement while not being that useful over OpenGL as far as DS emulation is concerned.
On a completely unrelated side note, really looking forward to a wifi renovation. SM64DS VS. mode hacking might finally get somewhere if it were emulated.
fintogive says:
Apr 17th 2020
i know its gonna be awile but imloking forward to cheat support when a good solution is figured out. keep up the good work! :P i love status updates.
asdf says:
Apr 17th 2020
recently there was an update to gearboy where it switched from qt to imgui.
maybe that would be another option for the ui?
extherian says:
Apr 17th 2020
Seems like just about every emudev is moving to Qt these days, I don't see why it wouldn't be a good fit for melonDS. I tested the Qt interface for Dolphin when it first came out, and found it to be a little less responsive compared to WxWidgets but also less likely to crash.
MelonMan says:
Apr 18th 2020
Asdf: I think they already considered that. https://paste.pics/8OWP3
A dragon says:
Apr 20th 2020
"melonDS has no vulkan backend, and I doubt it will have one any time soon, since it would be quite a bit of work to implement while not being that useful over OpenGL as far as DS emulation is concerned." I think the Retroarch team mentioned Parallel (the Vulkan based N64 emulator core) fixes some issues with games such as Body Harvest that other emulators have. If it's true, I'd imagine Vulkan can offer some improvements, which is why I've suggested Vulkan in the past.
Generic aka RSDuck says:
Apr 20th 2020
Vulkan doesn't automatically solve all kinds of problems. What besides giving more control away to the application, what differentiates Vulkan from modern OpenGL versions is not so much what it can do but what it can't do. In OpenGL if you do certain things everything might still run but slow, those paths have been pretty much eliminated there.

So yeah, melonDS wouldn't really profit from Vulkan and it would mostly just more code to manage.

Do you have any concrete problem with the current renderer? Because we fell into one of these "OpenGL traps", which we didn't yet (because it requires some prequisites).
Post a comment
Name:
DO NOT FILL