Pith bend message now has correct size (was 2 bytes instead of 3).
Recognized (but not implemented) 0xF? messages. SysEx messages will be reocognized as such, but their contents will be ignored.
Fixes#26637.
Fixes#19900.
The viewport_size returned by get_viewport_size was previously incorrect, being half the correct value. The function is renamed to get_viewport_half_extents, and now returns a Vector2.
Code which called this function has also been modified accordingly.
This PR also fixes shadow culling when using ortho cameras, because the correct input for CameraMatrix::set_orthogonal should be the full HEIGHT from get_viewport_half_extents, and not half the width.
It also fixes state.ubo_data.viewport_size in rasterizer_scene_gles3.cpp to be the width and the height of the viewport in pixels as stated in the documentation, rather than the current value which is half the viewport extents in worldspace, presumed to be a bug.
We used a lock signals in the signal_map while emitting, because it was
not allowed to disconnect them while being emitted.
We used that lock to check if we where deleting an object during signal
emission.
Now that we allow to disconnect signals while they are being emitted, if
an object first disconnects, then gets deleted we can't know that a
signal was being emitted during the destructor.
This commit adds a new `_emitting` boolean member to Object to be set
while emitting and checked in the destructor, while removing the old
signal lock which is now unused.
Used to allocate in stack (via alloca) which causes crashes when trying
to encode big variables.
The buffer grows as needed up to `encode_buffer_max_size` (which is
8MiB by default) and always in power of 2.
According to 22637beb2e (commitcomment-36651823)
and as confirmed by @reduz, this seems not to be necessary now that we
copy-on-write.
This triggered freeze scenarios in cases where a node would be deleted
while being used as a target in a signal emission.
Fixes#34650.
Fixes#34769.
Now those two errors go back to reporting:
```
ERROR: emit_signal: Condition ' !target ' is true. Continuing..:
At: core/object.cpp:1191.
```
Avoids crashes on debug mode. Instead it now breaks the execution and
show the error in-editor. Will still crash on release.
Also add a similar check to Marshalls to ensure the debugger doesn't
crash when trying to serialize the invalid instance.
Unify pack file version and magic to avoid hardcoded literals.
`version.py` now always includes `patch` even for the first release in
a new stable branch (e.g. 3.2). The public name stays without the patch
number, but `Engine.get_version_info()` already included `patch == 0`,
and we can remove some extra handling of undefined `VERSION_PATCH` this
way.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
It will now give information about the originating object instance
and when locked, the target callback.
This should help debugging editor and game issues that are now being
reported due to adding signal locking in
22637beb2e.
Some cases were not handled properly for Polygon2D after making changes in common code to fix Line2D antialiasing. Added an option for drawing polygons to differentiate the two use cases.
Fixes#34568
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
The calculation used to be wrong when exactly at a power of 2.
`nearest_shift` always return the "next" power of 2
`nearest_shift(4) == 3 # 2^3 = 8`.
On the other hand `next_power_of_2` returns the exact value if that
value is a power of 2 (i.e. `next_power_of_2(4) == 4`).
I.e. :
```
WARN_PRINT(itos(next_power_of_2(4)) + " " + itos(1 << nearest_shift(4)));
// WARNING: ... : 4 8
```
Is this by design?
Before this fix, opening relative export paths inside of an EditorFileDialog was not possible. This was fixed by modifying String::path_to_file() to save relative paths in EditorExportPreset::set_export_path() more appropriately and changing EditorFileDialog::set_current_dir() to open relative paths.
Near matching was not implemented like in TranslationServer, so a
resource remapped for 'ru' (but not 'ru_RU') would not be used as
fallback if the system locale was 'ru_RU'.
Fixes#34058.
The previous code only parsed the first two characters (potentially reading
out of bounds if input was invalid), but some locales use a 3-letter language
code (e.g. 'nah_MX').
So I refactored the logic a bit to properly parse the locale and extract the
part left of the regional code, if provided (supports both 'en_US' and 'en-US'
style).
I made TranslationServer::get_language_code() public as I'll use it in a
follow up commit.
Underscaled arc tolerance produced very small values so that changes
to this parameter were negligible when scaled internally, hence significant
performance drop (lots of intermediate points inserted in an arc). Now the
performance is mostly the same compared to other types of offsetting
(SQUARE, MITER).
Polygon2D:
The property wasn't used anymore after switching from canvas_item_add_polygon() to canvas_item_add_triangle_array() for drawing.
Line2D:
Added the same property as for Polygon2D & fixed smooth line drawing to use indices correctly.
Fixes#26823
This makes it possible to know whether the window is focused
at a given time, without having to track the focus state manually
using `NOTIFICATION_WM_FOCUS_IN` and `NOTIFICATION_WM_FOCUS_OUT`.
This partially addresses #33928.
This allows setting the `read_chunk_size` of the internal HTTPClient.
This is important to reduce the allocation overhead and number of file
writes when downloading large files, allowing for better download speed.
s * edge0 = -d / a * edge0 = -edge0⋅v0 / (edge0⋅edge0) * edge0 = vector projection of -v0 onto edge0
By incorrectly using -e/c instead of -d/a, Face3::get_closest_point_to was returning the wrong point in certain cases. Specifically, I noticed it returning vertex[0] when it should have been returning vertex[1].
Messages coming from ERR_EXPLAIN / ERR_*_MSG macros used to strip the
error explanation in release builds and was changed in a recent
refactoring.
This commit restores the old behaviour (fixing release builds).
