Three attack points, all after the regular calculations:
1. Prevent negative physics timestep counts. They could occur if
physics_jtter_fix is changed at runtime.
2. idle_step is not allowed to go below 1/8th of the input step.
That could happen on physics_jitter_fix changes or heavily
fluctuating performance.
3. Prevent that the idle_step modification breaks the promise
that Engine.get_physics_interpolation_fraction() is between
0 and 1 by doing more physics steps than the base system wants.
Fixes#26887
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
Cherry-Pick from 6be702bace.
This gives visual feedback when not starting Godot from a terminal.
This could lead to confusion when placing a Godot binary within a
project folder that has no main scene defined.
(cherry picked from commit 87fb9297e3)
Extremely long frames caused by suspending and resuming the machine could result in an overflow in the delta smoothing because it uses 32 bit math on delta values measured in nanoseconds.
This PR puts a cap of a second as the maximum frame delta that will be processed by the smoothing, otherwise it returns the frame delta 64 bit value unaltered. It also converts internal math to explicitly use 64 bit integers.
If enabled, key/touch/joystick events will be flushed just before every idle and physics frame.
Enabling this can greatly improve the responsiveness to input, specially in devices that need to run multiple physics frames per each idle frame, because of not being powerful enough to run at the target frame rate.
This will only work for platforms using input buffering (regardless event accumulation). Currenly, only Android does so, but could be implemented for iOS in an upcoming PR.
Input buffering is implicitly used by event accumulation, but this commit makes it more generic so it can be enabled for other uses.
For desktop OSs it's currently not feasible given main and UI threads are the same).
- API has been simplified: all events now go through `parse_input_event()`. Whether they are accumulated or not depends on the `use_accumulated_input` flag.
- Event accumulation is now thread-safe (it was not needed so far, but it prepares the ground for the following changes).
- Touch drag events now support accumulation.
The Transform::xform and xform_inv are made safe for Planes when using non-uniform scaling.
Basic unit tests for Transform.
Optimization of calling sites to prevent loss of performance from the changes to xform(Plane).
When the `sync_after_draw` feature was on it was possible for the profiler's frame_time measurement to be incorrect. This fixes this problem by storing the raw measured time for use by the profiler.
Added additional param to action related methods to test for exactness.
If "p_exact_match" is true, then the action will only be "matched" if the provided input event *exactly* matches with the action event.
Before:
* Action Event = KEY_S
* Input Event = KEY_CONTROL + KEY_S
* Is Action Pressed = True
Now:
You can still do the above, however you can optionally check that the input is exactly what the action event is:
* Action Event = KEY_S
* Input Event = KEY_CONTROL + KEY_S
* p_exact_match = True
* Is Action Pressed = False
* If the Input Event was only KEY_S, then the result would be true.
Usage:
```gdscript
Input.is_action_pressed(action_name: String, exact_match: bool)
Input.is_action_pressed("my_action", true)
InputMap.event_is_action(p_event, "my_action", true)
func _input(event: InputEvent):
event.is_action_pressed("my_action", false, true) # false = "allow_echo", true = "exact_match"
event.is_action("my_action", true)
```
Co-authored-by: Eric M <itsjusteza@gmail.com>
Investigations have showed that a lot of the random variation in frame deltas causing glitches may be due to sampling the time at the wrong place in the game loop.
Although sampling at the start of Main::Iteration makes logical sense, the most consistent deltas may be better measured after the location likely to block at vsync - either the OpenGL draw commands or the SwapBuffers.
Here we add an experimental setting to allow syncing after the OpenGL draw section of Main::Iteration.
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.
Physics FPS above 1000 cause the whole project to slow down
and are not very practical in the first place (since no CPU currently
available can keep up).
(cherry picked from commit 8f4ac7bc4a)
* Add support for decimal numeric entities to String::xml_unescape
* Add more error checks to String::xml_unescape
* Refactor XMLParser to use String::xml_unescape instead of an internal
implementation
The code is based on the current version of thirdparty/vhacd and modified to use Godot's types and code style.
Additional changes:
- backported and extended PagedAllocator to allow leaked objects
- applied patch from https://github.com/bulletphysics/bullet3/pull/3037
This changes the types of a big number of variables.
General rules:
- Using `uint64_t` in general. We also considered `int64_t` but eventually
settled on keeping it unsigned, which is also closer to what one would expect
with `size_t`/`off_t`.
- We only keep `int64_t` for `seek_end` (takes a negative offset from the end)
and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means
we only need to guard against passing negative values in `core_bind.cpp`.
- Using `uint32_t` integers for concepts not needing such a huge range, like
pages, blocks, etc.
In addition:
- Improve usage of integer types in some related places; namely, `DirAccess`,
core binds.
Note:
- On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with
version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for
big files on 32-bit Windows builds made with that toolchain. We might add a
workaround.
Fixes#44363.
Fixesgodotengine/godot-proposals#400.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
