when the gpu index is specified through the CLI, that setting will
be inherited by both the editor (if started through project manager)
and instances of the game started through the editor
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
- Do not reload scripts from non-collectible assemblies
- Do not load GodotTools as collectible
- Do not attempt to reload the same project assembly forever
Move the benchmarking measuring methods from `Engine` to `OS` to allow for platform specific overrides (e.g: can be used to hook into platform specific benchmarking and tracing capabilities).
Frame deltas are currently measured by querying the OS timer each frame. This is subject to random error. Frame delta smoothing instead filters the delta read from the OS by replacing it with the refresh rate delta wherever possible.
This PR also contains code to estimate the refresh rate based on the input deltas, without reading the refresh rate from the host OS.
The delta_smooth_enabled setting can also be modified at runtime through OS::, and there is also now a command line setting to override the project setting.
This adds a way to ensure that methods that were modified in the Godot API will continue working in older builds of GDExtension even if the new signature is different.
```C++
// New version (changed)
ClassDB::bind_method(D_METHOD("add_sphere","radius","position"),&MyShapes::add_sphere);
// Compatibility version (still available to extensions).
ClassDB::bind_compatibility_method(D_METHOD("add_sphere","radius"),&MyShapes::_compat_add_sphere);
```
**Q**: If I add an extra argument and provide a default value (hence can still be called the same), do I still have to provide the compatibility version?
**A**: Yes, you must still provide a compatibility method. Most language bindings use the raw method pointer to do the call and process the default parameters in the binding language, hence if the actual method signature changes it will no longer work.
**Q**: If I removed a method, can I still bind a compatibility version even though the main method no longer exists?
**A**: Yes, for methods that were removed or renamed, compatibility versions can still be provided.
**Q**: Would it be possible to automate checking that methods were removed by mistake?
**A**: Yes, as part of a future PR, the idea is to add a a command line option to Godot that can be run like : `$ godot --test-api-compatibility older_api_dump.json`, which will also be integrated to the CI runs.
- Fix project settings being ignored.
- Made usages of `native_thread_allocator` thread-safe.
- Remove redundant thread-safety from `low_priority_threads_used`, `exit_threads`.
- Fix deadlock due to unintended extra lock of `task_mutex`.
* Node processing works on the concept of process groups.
* A node group can be inherited, run on main thread, or a sub-thread.
* Groups can be ordered.
* Process priority is now present for physics.
This is the first steps towards implementing https://github.com/godotengine/godot-proposals/issues/6424.
No threading or thread guards exist yet in most of the scene code other than Node. That will have to be added later.
Instead of reading files over the network, the new version uses a local file cache and only updates files when it changes.
The original remote filesystem was created 14 years ago, when ethernet was faster than hard drives or even flash. Also, mobile devices have a very small amount of storage.
Nowadays, this is no longer the case so the approach is changed to using a persistent cache in the target device.
Co-authored-by: m4gr3d
On Linux, thread IDs were not properly assigned with the current approach.
The line:
`std::thread new_thread(&Thread::callback, _thread_id_hash(thread.get_id()), p_settings, p_callback, p_user);`
does not work because the thread ID is not assigned until the thread starts.
This PR changes the behavior to use manually generated thread IDs. Additionally, if a thread is (or may have been created) outside Godot, the method `Thread::attach_external_thread` was added.
