-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement changing RenderingDevice at runtime #6423
Comments
This requires refactoring the renderers to be able to cleanly start and shut down while the engine is running (similar to This is a worthwhile effort and will help in many situations (e.g. suspend on Linux or restoring context on Android/iOS), but it's a lot of work to get right. If we also recreate the main window (which will most likely be needed), this is also an opportunity to allow switching DisplayServers and rendering methods at run-time. The current workarounds available are:
|
@Calinou the workaround doesn't appear to be working if the project has been exported with the compatibility renderer. Running it with either |
This sounds like a bug. The rendering driver should be changed automatically if using a rendering method that requires a different rendering driver. In the meantime, use |
I started working on a Godot 4 project on one computer, then tried to open the project on another computer only to be told "Your video card drivers seem not to support the required Vulkan version". Impossible to open the project for editing, unless I manually fiddle with project.godot in a text editor. It should just say "Would you like to use OpenGL instead?" I'm no expert on these matters, but why does the choice of graphics driver need to be hardcoded into each project? Wouldn't it make more sense for it to be an editor-specific option, and only finalise it for your project when building a distributable version? |
@trollusk This is unrelated: godotengine/godot#58927
Different rendering methods have different visual outputs (due to a different feature set for each). Offering a fallback requires careful planning and work put into every rendering method (on your side), so you don't end up with broken visual outputs when the project is running with certain rendering methods. For instance, SDFGI and VoxelGI are only available when using the Forward+ rendering method, not Mobile or Compatibility. Even without those GI techniques, lighting output can differ significantly between rendering methods. Like in Godot 3.x, this will be supported once the OpenGL fallback is added, but it'll have to be something you enable explicitly for exported projects (due to the visual differences you need to cater for). |
@Calinou,
It seems like key=value arguments do not work for me. I tried some other key=value arguments and they're also ignored. All the command line arguments work fine if I launch the game in the Linux terminal though. Is this a bug or am I doing something wrong? |
You need to use |
Describe the project you are working on
I'm working on a 3D platformer on Godot 4
Describe the problem or limitation you are having in your project
Currently, the rendering device is defined at startup by godot with no ability to change it except through CLI directly at startup. This is inconvenient. lots of games allow to change the backend in the graphics settings at runtime.
One advantage would be to allow the game to start in the compatibility mode like opengl 3 at first to guarantee that the game will properly start and then allow to move to vulkan at runtime
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Adding a function allowing to select the RenderingDevice to use at runtime
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
a function such as RenderingDevice.select(VULKAN_FORWARD) etc
If this enhancement will not be used often, can it be worked around with a few lines of script?
I am not aware of workarounds apart from making a separate program that would start the game with CLI arguments
Is there a reason why this should be core and not an add-on in the asset library?
This is a core aspect of godot's hardware abstraction layer
The text was updated successfully, but these errors were encountered: