Run Drastic on PC

[marcin1503]

Hello

I didn't find this question in FAQ thats why I create new topic. Is possible to run this emulator on PC? I tried bluestacks in Windows but it freezes after opening the options menu. In some thread I saw mentions about linux but I didn't find any link. Maybe on linux is better android emulator and I can run it ?

[Plugyy]

You can try out genymotion, a virtualbox for android x86 with restricted gpu-support, works fine for me with ubuntu 14.04 and is as performant as native desmume. You need to install the play store somehow onto that virtualbox to install drastic fyi.

[marcin1503]

Every emulator on PC have performance below 100%. But drastic works with even 800% on my tablet. Is it because of arm architecture? If Drastic in android emulator will work like desmume it make no sense to try.

[Plugyy]

It's a virtual machine, not a mere emulator although that's written on their hp.
I think the performance of virtualbox is very much dependent whether your cpu supports vt-x.
For me Drastic on my system through that virtualbox can get way higher speeds than a native and self compiled (with added optimization flags) desmume with activated jit and disabled advanced bus-level timing. .. but I would guess drastic accomplishes that by making heavy use of frameskipping during fast forward .. and I think drastic comes by default with some deactivated graphics options to further improve performance.
i just can say again that drastic through that virtualbox is as performant as desmume on my system.

[Exophase]

The overhead of running a virtual machine should mainly be at the OS level, if at all. 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. I'm assuming that's there.. 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.

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. 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.. edge marking will probably cost more but still not that much). 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.

[Plugyy]

So this edge-marking thing is definitely coming? In some games its missing is noticeable and imho it affects the atmosphere.

[huckleberrypie]

The overhead of running a virtual machine should mainly be at the OS level, if at all. 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. I'm assuming that's there.. 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.

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. 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.. edge marking will probably cost more but still not that much). 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.

They added AA to Desmume fairly recently afaik, based on what I've seen on r5043 aka the American Girl fix.

[Exophase]

They added AA to Desmume fairly recently afaik, based on what I've seen on r5043 aka the American Girl fix.

Looking at the current code here:

http://sourceforge.net/p/desmume/code/H ... .cpp#l1390

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. There could be support to enable MSAA or similar for the OpenGL renderer, but that's not really supporting DS-style anti-aliasing.

DS AA involves keeping the top two pixels, storing a coverage percentage of the top pixel in alpha, and blending them together. But then apparently it'll blend in intermediate steps if there are alpha pixels, so it can sometimes do up to four pixels. The only emulator I know of that emulates this is dasShiny, and it adds a lot of complexity to the code. 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. Edge marking has to come first anyway, since AA needs some of the same edge determination code.

[huckleberrypie]

So it's an ersatz implementation?

[Exophase]

If you're talking about the part in rasterizer.cpp then no.. it doesn't have anything to do with anti-aliasing at all. It's just some other thing that enabling AA influences.

Like with DraStic, when AA or edge marking is enabled it makes the polygons one pixel wider (this is supposed to happen), but it doesn't actually mark edges or perform AA.