|Home | Downloads | Screenshots | Forums | Source code | RSS|
|< Chaos aheadSneak peek of melonDS 0.9 >|
Apr 11th 2020, by Arisotura
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.
|27 comments have been posted.|
|< Chaos aheadSneak peek of melonDS 0.9 >|