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.
poudink says:
Apr 21st 2020
ParaLLEl is more accurate. It use Vulkan, but it's not because it use Vulkan and is more accurate that it is more accurate because it uses Vulkan. Personally I'd attribute that to the whole "LLE" part and also to the fact that people still use Jabo or Rice graphics plugins instead of the much more accurate GlideN64 or Angrylion plugins with those other emulators you speak of.
A dragon says:
Apr 22nd 2020
I suppose it's true that it won't automatically solve problems. It's how it's used. Vulkan's supposed to be the successor to OpenGL, so in theory, it should have more functionality. There's a number of games where there's misaligned textures. Pokemon Diamond/Pearl is one where it has black gaps on map tiles, for example. I think I remember some oddities with the clouds on Solatoroba: Red the Hunter. If these can't be solved with OpenGL, I'm wondering if Vulkan might have some additional functionality that could fix it.
Ajay says:
Apr 23rd 2020
Still waiting melonDS for Switch new version,thank you so much!I really like SRW-W,But working not good,Please keep going
Comlud says:
Apr 27th 2020
I'd not recommend Vulkan though for the fact that it's simply very hard to learn.
I don't think anyone will want the dev team to spend 2-3 years making a renderer that solves some misaligned textures.
Generic aka RSDuck says:
Apr 27th 2020
Vulkan is not "hard" if you're familiar with recent OpenGL versions. I recently moved the Switch frontend from OpenGL to deko3d (which is pretty much homebrew Vulkan but even a little bit more low level and specifically for the Switch) and although it took some troubleshoothing, it was pretty straightforward. In some sense OpenGL with it's legacy remains (e.g. the border parameter in glTexImage2D which has to be set to zero by spec) can be more confusing.
Arisotura says:
Apr 29th 2020
moreover, the Vulkan renderer wouldn't solve shit like misaligned textures. those details aren't really specific to OpenGL, they are how modern GPUs do things internally.
Marck says:
May 3rd 2020
Hey, Melon Team, the newest leak of data from nintendo could help the develpoment of the emulator? Saw this a little while ago and got me thinking.
poudink says:
May 3rd 2020
isn't it only wii stuff though
poudink says:
May 3rd 2020
oh and gamecube and ique stuff too. I don't see any DS stuff though.
extherian says:
May 4th 2020
The source code leak is useless for emulation projects because if a lawyer can prove they looked at it, then Nintendo could get them shut down.

Why do you think so many ROM sites get shut down, but the emulators themselves remain up on github out in the open? It's because as long as they're reverse-engineering the hardware rather than using copyrighted blueprints, they are immune to legal action from Nintendo.
Arisotura says:
May 5th 2020
besides, it's more fun to reverse-engineer the actual hardware. leaks are like cheating :P
Marck says:
May 5th 2020
Nice to know! Let the fun prevail, always.
Post a comment
Name:
DO NOT FILL