This eases troubleshooting when working with command line arguments.
Warnings are only printed if the argument does not exist as a file
or directory path (relative or absolute). This allows positional arguments
to keep working as they are now, without printing warnings when a project
reads positional arguments to perform operations on files (e.g. when
drag-and-dropping a file onto a project executable).
This now prints a warning:
godot --non-existent-argument
This still doesn't print a warning, as it's an user argument:
godot -- --non-existent-argument
This doesn't print a warning if the file/folder path exists:
godot /path/to/file.txt
A warning is still printed if the file/folder doesn't exist. Drag-and-drop
associations always refer to existing files/folders, so that scenario was
unlikely to be encountered.
Adds "--accurate-breadcrumbs" CLI command
Additionally, leave out breadcrumbs code in non-debug, non-dev builds.
Fix regression introduced in #98388 where command_insert_breadcrumb() is
called even in non-debug builds.
Fixes#98338
`core/os/os.h` doesn't use `core/io/image.h`. It just brings
transitive dependencies. Lots of dependencies because `core/os/os.h`
is transitively included in almost every file of godot
Also added `core/io/image.h` into files^1 where `Ref<Image>` and `core/os/os.h`
were used to prevent obscure errors involving `Ref<Image>`
^1 except those which include `core/io/image_loader.h` or `core/io/image.h` by
corresponding .h file with the same name
Signed-off-by: Yevhen Babiichuk (DustDFG) <dfgdust@gmail.com>
Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com>
- Implements asynchronous transfer queues from PR #87590.
- Adds ubershaders that can run with specialization constants specified as push constants.
- Pipelines with specialization constants can compile in the background.
- Added monitoring for pipeline compilations.
- Materials and shaders can now be created asynchronously on background threads.
- Meshes that are loaded on background threads can also compile pipelines as part of the loading process.
XR is disabled when 3D is disbled so there is no sense in
setting xr specific settings and adding `--xr-mode` option
Signed-off-by: Yevhen Babiichuk (DustDFG) <dfgdust@gmail.com>
If the module is enabled (default), 2D physics works as it did before.
If the module is disabled and no other 2D physics server is registered
(via a module or GDExtension), then we fall back to a dummy
implementation which effectively disables 2D physics functionality (and
a warning is printed).
The dummy 2D physics server can also be selected explicitly, in which
case no warning is printed.
If the module is enabled (default), 3D physics works as it did before.
If the module is disabled and no other 3D physics server is registered
(via a module or GDExtension), then we fall back to a dummy
implementation which effectively disables 3D physics functionality (and
a warning is printed).
The dummy 3D physics server can also be selected explicitly, in which
case no warning is printed.
PR #90993 added several debugging utilities.
Among them, advanced memory tracking through the use of custom
allocators and VK_EXT_device_memory_report.
However as issue #95967 reveals, it is dangerous to leave it on by
default because drivers (or even the Vulkan loader) can too easily
accidentally break custom allocators by allocating memory through std
malloc but then request us to deallocate it (or viceversa).
This PR fixes the following problems:
- Adds --extra-gpu-memory-tracking cmd line argument
- Adds missing enum entries to
RenderingContextDriverVulkan::VkTrackedObjectType
- Adds RenderingDevice::get_driver_and_device_memory_report
- GDScript users can easily check via print(
RenderingServer.get_rendering_device().get_driver_and_device_memory_report()
)
- Uses get_driver_and_device_memory_report on device lost for appending
further info.
Fixes#95967
Before it was a bit unclear on what was happening, since a display
server has to fail to fall back and so the user would be left with an
error _and_ a (hopefully) running game.
Should make the experience more pleasant on Linux/BSD now that we have
two display servers.
- Deduplicate rendering driver names.
- Tweak grammar and punctuation to be consistent across both messages.
- Use "rendering method" terminology in the relevant error message.
Preview:
`--rendering-driver unknown`:
Unknown rendering driver 'unknown', aborting.
Valid options are 'vulkan', 'opengl3', 'opengl3_es' and 'dummy'.
`--rendering-method unknown`:
Unknown rendering method 'unknown', aborting.
Valid options are 'forward_plus', 'mobile' and 'gl_compatibility'.
