* Added a new macro SNAME() that constructs and caches a local stringname.
* Subsequent usages use the cached version.
* Since these use a global static variable, a second refcounter of static usages need to be kept for cleanup time.
* Replaced all theme usages by this new macro.
* Replace all signal emission usages by this new macro.
* Replace all call_deferred usages by this new macro.
This is part of ongoing work to optimize GUI and the editor.
While there are still various bugs to solve and features to implement, the C#
support as of Godot 3.4 is fairly mature and already used by a number of users
in production. Now that we default to dotnet CLI as build tool, it also seems
to be more reliable than MSBuild.
The documentation can (and does for the most part) point out some caveats that
users should be aware of, but this info dialog has outlived its intended
purpose.
- Fix C++ compile errors about pending variable renames after the `Reference` to `RefCount` change.
- Fix C# compile errors due to the recent rename of `EnablePlugin()` and `Build()`, which are now underscore-prefixed in bindings.
- Additional rename: `godot_icall_Reference_Dtor` to `godot_icall_RefCounted_Dtor`.
The order of numbers is not changed except for Transform2D. All logic is done inside of their structures (and not in Variant).
For the number of decimals printed, they now use String::num_real which works best with real_t, except for Color which is fixed at 4 decimals (this is a reliable number of float digits when converting from 16-bpc so it seems like a good choice)
The following two bugs were fixed:
- For classes without namespace we were still generating `namespace {`
without a namespace identifier, causing a syntax error.
- For classes with nested namespaces we were generating only the innermost
part of the namespace was being generated, e.g.: for `Foo.Bar` we were
generating `namespace Bar {` instead of `namespace Foo.Bar {`.
This wasn't causing any build error, but because of the wrong namespace
Godot wasn't able to find the class associated with the script.
This source generator adds a newly introduced attribute,
`ScriptPath` to all classes that:
- Are top-level classes (not inner/nested).
- Have the `partial` modifier.
- Inherit `Godot.Object`.
- The class name matches the file name.
A build error is thrown if the generator finds a class that meets these
conditions but is not declared `partial`, unless the class is annotated
with the `DisableGodotGenerators` attribute.
We also generate an `AssemblyHasScripts` assembly attribute which Godot
uses to get all the script classes in the assembly, eliminating the need
for Godot to search them. We can also avoid searching in assemblies that
don't have this attribute. This will be good for performance in the
future once we support multiple assemblies with Godot script classes.
This is an example of what the generated code looks like:
```
using Godot;
namespace Foo {
[ScriptPathAttribute("res://Player.cs")]
// Multiple partial declarations are allowed
[ScriptPathAttribute("res://Foo/Player.cs")]
partial class Player {}
}
[assembly:AssemblyHasScripts(new System.Type[] { typeof(Foo.Player) })]
```
The new attributes replace script metadata which we were generating by
determining the namespace of script classes with a very simple parser.
This fixes several issues with the old approach related to parser
errors and conditional compilation.
It also makes the task part of the MSBuild project build, rather than
a separate step executed by the Godot editor.
The ClassDB tests will detect when the core API has dependencies on
the editor API, which is not allowed.
This should prevent or warn early about issues like #44856
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 🎆
This is needed with newer Mono versions, at least with Mono 6.12+
Depends on the following commit from our build scripts:
godotengine/godot-mono-builds@9d75cff174
The underscore prefix was used to avoid the conflict between the `RID` class
name and the matching enum value in `Variant::Type`.
This can be fixed differently by prefixing uses of the `RID` class in `Variant`
with the scope resolution operator, as done already for `AABB`.
Main benefits:
- Projects can be built offline. Previously you needed internet
access the first time building to download the packages.
- Changes to packages like Godot.NET.Sdk can be easily tested
before publishing. This was already possible but required
too many manual steps.
- First time builds are a bit faster, as the Sdk package doesn't
need to be downloaded. In practice, the package is very small
so it makes little difference.
Bumped Godot.NET.Sdk to 4.0.0-dev3 in order to enable the
recent changes regarding '.mono/' -> '.godot/mono/'.
