We've been using standard C library functions `memcpy`/`memset` for these since
2016 with 67f65f6639.
There was still the possibility for third-party platform ports to override the
definitions with a custom header, but this doesn't seem useful anymore.
Backport of #48239.
Fixes#45997.
Setting a GDNativeLibrary config file as null or any other object but a ConfigFile will now cause an error.
(cherry picked from commit 618dd892f5)
The `dev=yes` and `production=yes` options work as aliases to set a number of
options, while still aiming to allow overriding specific options if the user
wishes so. (E.g. `production=yes use_lto=no` should work to enable production
defaults *but* disable LTO.)
That wasn't working as `ARGUMENTS.get()` returns a string and not a boolean as
expected by `BoolVariable`, and this wasn't flagged as a bug... So added a
helper method using SCons' `BoolVariable._text2bool` to do the conversion
manually.
- Based on C++11's `atomic`
- Reworked `SafeRefCount` (based on the rewrite by @hpvb)
- Replaced free atomic functions by the new `SafeNumeric<T>`
- Replaced wrong cases of `volatile` by the new `SafeFlag`
- Platform-specific implementations no longer needed
Co-authored-by: Hein-Pieter van Braam-Stewart <hp@tmm.cx>
- Based on C++11's `thread` and `thread_local`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed (except for the few cases of non-portable functions)
- Simpler for `NO_THREADS`
- Thread ids are now the same across platforms (main is 1; others follow)
- Based on C++11's `mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
- `BinaryMutex` added for special cases as the non-recursive version
- `MutexLock` now takes a reference. At this point the cases of null `Mutex`es are rare. If you ever need that, just don't use `MutexLock`.
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
(cherry picked from commit b5334d14f7)
Working, with emscripten > 2.0.9
Yes, the unreleased version. 2.0.9 works, but throws and error due to a
bug in emscripten with the thirdparty ENet library.
The issue is fixed upstream so newer releases will work.
It's not an engine module. This is handled by GDNative's
`SCsub` instead, as done for other subdirectories already.
(cherry picked from commit 650ae413ce)
without this we have to manually drop a `x86_64` builds of gdnative libs into the Xcode project to allow running in `iOS Simulator`
(cherry picked from commit f49199bcc3)
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
(cherry picked from commit cd4e46ee65)
We already removed it from the online docs with #35132.
Currently it can only be "Built-In Types" (Variant types) or "Core"
(everything else), which is of limited use.
We might also want to consider dropping it from `ClassDB` altogether
in Godot 4.0.
This function is available to GDScript but not to GDNative. When exposed, it
allows building more ergonomic safe abstractions over the GDNative APIs, and
covers the use cases of the original PR.
Close#28478. Supersedes #28791.
Co-authored-by: Markus Ewald <cygon@nuclex.org>
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.
VarArg methods have the return type Object in the API json for GDNative. This
can cause undefined behavior in some language bindings due to lack of
documentation on VarArg methods' behavior.
This changes the MethodInfo of:
- CSharpScript::_new
- GDScript::_new
- PluginScript::_new
This was a regression in 3.1 and later from the new inspector, where
PROPERTY_HINT_SPRITE_FRAME was not fully re-implemented. It's meant to
be a normal PROPERTY_HINT_RANGE which also automatically increments its
value when keyed in the animation player.
To avoid code duplication, I made the frames properties use the actual
PROPERTY_HINT_RANGE and introduced a PROPERTY_USAGE_KEYING_INCREMENTS
usage flag instead.
Properly release added resource loader and save references. Otherwise PluginScript API
may cause "ObjectDB Instances still exist!" warnings and segmentation faults on exit.
That is, any library referred to in GDNative library resources, won't be copied to the export target path unless its path begins with `res://`.
The case use for this is a bit advanced: having a GDN library that will be deployed separately from the project; for instance, to a path in the system (like `/opt/...`).
Currently the GDN library editor doesn't allow to pick dynamic libraries outside the project, but that can be done by editing the `.gdnlib` file manually.
It's the recommended way to set those, and is more portable
(automatically prepends -D for GCC/Clang and /D for MSVC).
We still use CPPFLAGS for some pre-processor flags which are not
defines.
The functionality is similar to how `doc_classes` are retrieved per module.
The build system will search for custom icons path defined per module via
`get_icons_path()` method in `config.py` or default icons path.
If such paths don't exist, only the editor's own icons will be built.
Most module icons were moved from editor/icons to respective modules.
