search

libretro / parallel-n64

Optimized/rewritten Nintendo 64 emulator made specifically for Libretro. Originally based on Mupen64 Plus.
330 stars 128 forks source link

Various bugs between difference video renderes using Angrylion #520

Open KristopherTadlock opened 6 years ago

KristopherTadlock commented 6 years ago

RA v 1.7.3 Windows 10 x64 16GB DRAM GTX 1080 driver version 197.55 Haswell 4690K@4.4ghz

Vulkan:

Starting vulkan from the command line breaks Vsync. Using the vysnc flag doesn't seem to help.

OpenGL: VI Overlay kills the visible display. Audio can be heard playing the background. Toggling VI overlay on/and off within the same game, or between loads of a game produces the same effect.

D3D 10: Works just fine. Probably a bug with RA, loading a game does not load the shader preset and has to be enabled every time.

D3D 12: Works fine, but shaders seem to have no effect (probably just not supported yet).

Miscellaneous bug: Applying per game configurations changes the configuration for the entire core. For example, disabling VI Overlay while running, using the save per game config option, and then loading another title has VI Overlay disabled as well.

Finally, and I am sure the devs are aware of this, there are pretty severe regressions between parallel using gliden64 and CXD4, and m64p using the same plugins. Seeing as the parallelie plugin support was dropped recently, there doesn't seem to be a reason why this should be the case.

hizzlekizzle commented 6 years ago

You may already be aware, but the GLideN64 plugin that's in this core is much older and worse-off than the one in the mupen64plus-libretro core.

inactive123 commented 6 years ago

We are still hoping somebody can port gliden64 over and then we keep it updated in the parallel N64 repo.

KristopherTadlock commented 6 years ago

Hey Hizzlekizzle, I was aware of mupen64plus, but I wasn't aware that it had been updated fairly recently to what appears to be glideN64 2.0. This allows me to emulate all but one or two games in retroarch, which is great. I hadn't expected it to get anymore attention, because the RA devs have been saying for a while now that mupen64plus wasn't going to be supported. Happy to be wrong on that one.

hizzlekizzle commented 6 years ago

It's not going to be supported moving forward, so it's frozen in time as of the last update, which was a bit over a year ago, IIRC. However, it was in really good shape at that point and continues to be very usable and user-friendly, aside from the small handful of games that have been fixed since then (Indiana Jones, Rogue Squadron, etc.). I still use it on my Shield ATV.

ghost commented 6 years ago

Without making people assume things will be done.... I did some looking into the most recent GLideN64 things.

Some deliberate major code changes were done upstream, such as changing to a completely abstracted API handler (to allow things like D3D and Vulkan down the line). They also abstracted things like framebuffer handling so things like the libretro client allocated framebuffer object can be used as the primary drawing surface. This applies to things like GL extension handling too, which means portions of GLideN64 need to be redone to fit into libretro.

Updating mupen64plus is much more problematic, again due to the deliberate changes some developers did to make sure everything is abstracted (basically, structs all the way down and zero globals in sight). This affects even things like the dynamic recompiler, which relies on GNU tools like Awk to compile.