It's hard to estimate what the performance hit would be for DraStic to do something like this (with optimized code), since ideally much of the overhead would only happen on edge pixels, but it'll be a lot of work to even get an implementation down. The only emulator I know of that emulates this is dasShiny, and it adds a lot of complexity to the code. But then apparently it'll blend in intermediate steps if there are alpha pixels, so it can sometimes do up to four pixels. There could be support to enable MSAA or similar for the OpenGL renderer, but that's not really supporting DS-style anti-aliasing.ĭS AA involves keeping the top two pixels, storing a coverage percentage of the top pixel in alpha, and blending them together.
Fastest desmume emulator jit software#
There's no anti-aliasing in the software renderer, the only time the setting (enableAntialiasing) is referenced is for is changing alpha to 50% with edge marking, which is some weird thing DS does, but not directly related to AA. Huckleberrypie wrote:They added AA to Desmume fairly recently afaik, based on what I've seen on r5043 aka the American Girl fix. They added AA to Desmume fairly recently afaik, based on what I've seen on r5043 aka the American Girl fix.
Fastest desmume emulator jit android#
Other than that, the efficiency shouldn't be that different from running it on an x86 Android tablet, and most PCs are a lot faster than those. DraStic shouldn't speend too much time interacting with the OS, although it uses OpenGL ES to scale the screens and apply filters, so the VMed OS will need a good bridge to OpenGL for this to work/not cause a big slowdown. The only missing graphics function that could have a big nevative impact on performance is anti-aliasing, but DeSmuME doesn't implement that either, and if it did it'd probably take a big speed hit too.Įxophase wrote:The overhead of running a virtual machine should mainly be at the OS level, if at all. edge marking will probably cost more but still not that much). The missing 3D graphics features, fog and edge marking, don't make that much of a speed difference (I already implemented fog, it just hasn't been released yet, and the performance impact is very small. The x86 build of DraStic is a lot less efficient than the ARM build (because it has an inferior recompiler and no NEON-optimized functions), but it's still a lot more efficient than DeSmuME even with JIT enabled, that's just the nature of its design.
I later ported all changes so that it's now based off the Git master branch of DeSmuME. It was originally based of masterfeizz's port which is probably based off the last release of DeSmuME from a few years ago. DraStic shouldn't speend too much time interacting with the OS, although it uses OpenGL ES to scale the screens and apply filters, so the VMed OS will need a good bridge to OpenGL for this to work/not cause a big slowdown. This is an unfinished port of the Nintendo DS emulator DeSmuME for Nintendo Switch. The overhead of running a virtual machine should mainly be at the OS level, if at all.
0 kommentar(er)
