Closed yaw-man closed 2 years ago
How does your image confirms it? Is that a debug flag or something..?
My apologies - reading it back, the image is not at all self-explanatory! I attached a debugger to the plugin, set a breakpoint at DistrhoUINekobi's constructor, then stepped through until I saw an OpenGL call. If that doesn't actually confirm that the plugin is using the right backend, let me know :)
I am wondering if this due to the version of DPF you are using. I just updated the main branch to get all the latest features and fixes, so update your DPF submodule and try again. Latest commit is "Fix typo leading some VST3 groups having 0 ports".
Let me know if/how that works for you.
Actually I can reproduce this now. Something broke for opengl-based Windows with DPF a while ago and went unnoticed. The commit a941917f15be21e6bdce6793addec225537cccc5 doesn't have the issue. So it is something after that one.
Found it, commit f26b8147d309f8b3cdcaa6b3e6d8dac773658009 is the regression. This was supposed to fix another issue, but resulted in bad things for us...
Fixed in 241845f387f03473e84254f7bfb73bd09460417a
Compiling on Windows, using Visual Studio 2022 Community's compiler for amd64.
Picture of Nekobi VST2, hosted in OpenMPT:
Picture confirming that the plugin actually calls OpenGL:
Repo with the CMakeLists files I used to build this: https://github.com/yaw-man/Nekobi