Vulkan Support?

[AvoLadrian]

I was just wondering...
Does the mcpelauncher use the Vulkan or OpenGL Renderer?
I'm asking this question because when I load YSSBE (Special) Shaders. It looks completely Vanilla.

[ChristopherHX]

I would guess you didn't install it correctly, but I have never tried to install the shader to a renderdragon game version.
1.18.12 uses the original OpenGL ES 2/3 backend (0.10.0 - 1.18.12), where older versions of the shader has been working in the past.

• mcpelauncher uses the renderdragon renderer (bgfx - OpenGL ES 2/3 backend) in 1.18.30+.
• Vulkan can be used by translating OpenGL ES 2/3 to Vulkan (google/angle).

Everything else would need game modding, which is not easy and error prone due to game updates. While bgfx is opensource, has mojang forked it and made significant changes.

[AvoLadrian]

Sorry. I meant is the Minecraft Bedrock Launcher using Vulkan for rendering 3D Graphics in Minecraft or OpenGL?

[ChristopherHX]

OpenGL ES 3

[AvoLadrian]

Ok. Thanks for letting me know.

[AvoLadrian]

As of now. is there any way to allow Vulkan on Minecraft Bedrock Launcher?

[ChristopherHX]

No, the android game doesn't support vulkan therefore this launcher can't allow something not in the game.

What benefit has allowing vulkan? The YSSBE Android shader works in this launcher on 1.19.83.01.

[ChristopherHX]

In case you don't believe here a screenshot

[AvoLadrian]

I know that. I tested it and it works because it works on Renderdragon with manual installation. although they have a Dynamic shaders that requires DX11 and its forks. this is why ithe RTX Shaders will not work on the Minecraft Bedrock Launcher for the reasons described above.

[severtheskyline]

How is the situation of this now? Seems that #768 implemented Metal fine with Google's ANGLE, can it be done? If not, why was it possible to do on MacOS with Metal but not Vulkan on Linux?

[ChristopherHX]

implemented Metal fine with Google's ANGLE, can it be done?

This is emulation of OpenGL ES 3.0, this decreases frame rates and increases cpu load on apple platforms.

I can't think of any scenario emulation wins performance wise, but apple forces us to do it on intel platforms as I have no idea how the mod previously targeted OpenGL Desktop ever worked and now they switched the renderer and removed all symbols of their modified bgfx

Do you have a vulkan only gpu? You can use ANGLE externally, just rename it's libEGL.so to libEGL.so.1 and put the folder in LD_LIBRARY_PATH Build from Source/AppImage/apt/rpm should all work (Don't use flatpak prebuilds, they make it hard, but probably not impossible).

[severtheskyline]

You can use ANGLE externally, just rename it's libEGL.so to libEGL.so.1 and put the folder in LD_LIBRARY_PATH Build from Source/AppImage/apt/rpm should all work (Don't use flatpak prebuilds, they make it hard, but probably not impossible).

I did some testing with this idea, but not quite compiling from source, I first tried using LD_PRELOAD with libEGL.so which I ripped straight out of a copy of Cromite for Linux, first with the flatpak version, which, for no one's surprise didn't work, then I tried with the appimage and, by surprise, it did work:

Here is with the flatpak version (EGL):

However, I couldn't get it to run using Vulkan, it defaulted to using the desktop OpenGL backend (shown in the picture) which was a bit over the place, the framerate didn't change much (with 12 chunks on this laptop it usually moved around 50 to 60 fps and 16 ms. frametimes) but frametime did go up when loading laggy areas in my world, at least in 1.20.73, in 1.21.0 it seemed in par with OpenGL ES (it seemed that performace went down in 1.21, at least for me). Also, for the fun of it I did tried zink too, which was terrible (basically cutting my fps in half), but worked better with the desktop OpenGL from ANGLE instead of the normal EGL one (mainly EGL giving some graphical glitches, but sadly I couldn't capture them), here a picture of that abomination:

I did had an idea with this tho, since different hardware has different graphical API support (mostly how good some may perform than other, if an API is there at all), maybe it should be considered implementing ANGLE to have multiple back-ends, maybe in the profile settings there could be a drop down menu with the option to select OpenGL ES (the normal one not using ANGLE), Desktop OpenGL (with ANGLE), and a Vulkan (also with ANGLE), the default of course would the EGL, but users may select which back-end may work better for them with trial and error, itt may extend to MacOS as well, but for the poorly supported Desktop OpenGL or Metal. It may be too complex or out of the scope of the project, but wanted to leave the idea here just in case it may not be that far fetched.

[ChristopherHX]

it may extend to MacOS as well

macOS has a Default/Metal/OpenGL toggle in profile settings, you might not know this if you never started the mac version

the bundled ANGLE version has been modified, because around new year 2022-2023 were the Metal/OpenGL backends unable to boot the game without showing a black screen, that was even present on linux at this time
VULKAN always worked

ANGLE_DEFAULT_PLATFORM is the env variable to change what angle uses as backend, OpenGL is also the default for macs

It may be too complex or out of the scope of the project, but wanted to leave the idea here just in case it may not be that far fetched

Yes this is a very big project to do that, especially this is no hard requirement to play the game on linux
Just look at the number of packages I create for linux, then look at macOS were it is a single one with 3 qt version in a matrix

The UI addition is feasible, packaging not

[severtheskyline]

macOS has a Default/Metal/OpenGL toggle in profile settings, you might not know this if you never started the mac version

Considering the status of Mac gaming, it's probably for the best.

the bundled ANGLE version has been modified, because around new year 2022-2023 were the Metal/OpenGL backends unable to boot the game without showing a black screen, that was even present on linux at this time

Just curious, how is the situation for that part at the moment? I tried a normal (to my knowlegde) copy of Angle comming from this cromite release, in the changes there is no listing of any modifications to it, and both the OpenGL and Vulkan backends worked on the game (There is a bug with resizing the window that makes the whole app window flash black when it is resizing when using vulkan, not that it would matter if there are problems with implementing it anyway).

ANGLE_DEFAULT_PLATFORM is the env variable to change what angle uses as backend, OpenGL is also the default for macs

I found out the environment variable in the most deep, god forsaken forum post from google imaginable, but that doesn't really matter since it works, when adding ANGLE_DEFAULT_PLATFORM=vulkan in the environment variables it did launch on Vulkan, shown here:

I'm not gonna extend in this part much since I think the next concern is more important.

Yes this is a very big project to do that, especially this is no hard requirement to play the game on linux

Fair enough

Just look at the number of packages I create for linux, then look at macOS were it is a single one with 3 qt version in a matrix

If I get what you meant in this, I think you're refering to github actions builds, so I checked them out, and...

I didn't expect this much, specially the Angle part, would it need to be like this for every release? I won't push it any further since I can see the problem now, but could there be other ways to simplify it? Like excluding some backends at compilation time, just having some compiled libraries in the repo that get included on build time (For example, just having libEGL.so, libGLESv2.so and libvulkan.so.1 were the only ones I needed to run the game this way, then again, I guess this would be a band-aid fix) just some ideas, but yeah, it's not a necessity, but probably something to remember if the deferred rendering shaders don't play as nice going forward maybe.