Hello, esteemed developers of the Virtual Joystick class!
I’m reaching out to you regarding an issue we’ve encountered when using the Virtual Joystick element on Android and iPhone devices. We’ve noticed that this element behaves very unstably and causes several problems.
Specifically, when the Virtual Joystick is activated, it intercepts and overlaps other controls, making navigation difficult and inconvenient for users. Attempts to switch the element to fullscreen mode using the canvas.requestFullscreen() method result in the control simply disappearing, which is not the desired outcome.
Furthermore, trying to adjust the container size using the containerSize method leads to rendering bugs, rendering the functionality of the element non-functional.
We’re disappointed that the Virtual Joystick turned out to be such an underdeveloped element, especially considering the inspiring interview with Jason Carter and David Catuhe, where the 7th version was touted as a full-fledged powerful engine.
Examples of problematic behavior can be seen on the following Playgrounds:
I also want to mention a bug in the Playground platform itself: on mobile devices, it’s impossible to enter fullscreen mode for the canvas, whereas on the desktop version, it works.
We would greatly appreciate any assistance in resolving these issues and improving the stability and functionality of the Virtual Joystick.
VirtualJoystick not being visible after canvas.requestFullscreen() is the expected behavior, because he is not the content of the canvas, he is a separate HtlmElement.
To keep him visible, try document.body.requestFullscreen().
Playgound’s fullscreen for mobile works fine for me, but if you’re on an Apple device, unfortunately Apple phones don’t support the fullscreen api.
But I do agree that virtualJoystick is a bit hard to use, I’m currently using a custom solution.
Thank you very much for your response. Unfortunately, the Chrome browser on Android cannot open the body in fullscreen mode. Only a fullscreen canvas will help me. And you were right. It’s true. VirtualJoystick indeed creates an external canvas with z-index: 5 after all the code and doesn’t work inside the active canvas. Here’s what it generated after my canvas: <canvas width="375" height="667" touch-action="none" style="width: 100%; height: 100%; position: absolute; background-color: transparent; top: 0px; left: 0px; z-index: 5; touch-action: none;"></canvas>
It turns out that VirtualJoystick doesn’t work with the BabylonJS canvas at all and is external. But why? After all, the GUI library draws objects inside my canvas perfectly fine, and all the buttons can interact with it. Is it impossible to improve VirtualJoystick so that it works not as a makeshift solution, but as a full-fledged BABYLON.GUI element?
Despite that this class was written 8 years ago, it is still quite usable if you know how to work around its shortcomings. I couldn’t enable full-screen mode for the Canvas while keeping VirtualJoystick visible, but I managed to get rid of the address bar in mobile Chrome on Android. I added the following tag to the : <link rel="manifest" href="/manifest.json"> and placed the manifest.json file in the root directory of the web server. This way, my website started prompting to install PWA, and on Windows and Android, I can run my website as an app, and I managed to do it in full-screen mode for the entire website body, if not the Canvas itself. Good solution to keep using VirtualJoystick.
Good solution to keep using VirtualJoystick.