Age | Commit message (Collapse) | Author |
|
C#: Switch games to MSBuild Sdks and .NET Standard
|
|
Godot.NET.Sdk
-------------
Godot uses its own custom MSBuild Sdk for game
projects. This new Sdk adds its own functionality
on top of 'Microsoft.NET.Sdk'.
The new Sdk is resolved from the NuGet package.
All the default boilerplate was moved from game
projects to the Sdk. The default csproj for
game project can now be as simple as:
```
<Project Sdk="Godot.NET.Sdk/4.0.0-dev2">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
</PropertyGroup>
</Project>
```
Source files are included by automatically so
Godot no longer needs to keep the csproj in sync
when creating new source files.
Define constants
----------------
Godot defines a list of constants for conditional
compilation. When exporting games, this list also
included engine 'features' and platform 'bits'.
There were a few problems with that:
- The 'features' constants were only defined when
exporting games. Not when building the game for
running in the editor player.
- If the project was built externally by an IDE,
the constants wouldn't be defined at all.
The new Sdk assigns default values to these
constants when not built from the Godot editor,
i.e.: when built from an IDE or from the command
line. The default define constants are determined
from the system MSBuild is running on.
However, it's not possible for MSBuild to
determine the set of supported engine features.
It's also not possible to determine if a project
is being built to run on a 32-bit or 64-bit
Godot executable.
As such the 'features' and 'bits' constants had
to be removed.
The benefit of checking those at compile time
was questionable, and they can still be checked
at runtime.
The new list of define constants includes:
- GODOT
- GODOT_<PLATFORM>
Defaults to the platform MSBuild is running on.
- GODOT_<PC/MOBILE/WEB>
- TOOLS
When building with the 'Debug' configuration
(editor and editor player).
- GODOT_REAL_T_IS_DOUBLE
Not defined by default unless $(GodotRealTIsDouble)
is overriden to be 'true'.
.NET Standard
-------------
The target framework of game projects was changed
to 'netstandard2.1'.
|
|
|
|
|
|
Also a few minor API changes like adding AABB.abs()
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
|
|
|
|
Mono/C#: Fix several clang-tidy warnings and cleanup
|
|
|
|
fix crash when pass null in print array in GD.print 2
fix crash when pass null in print array in GD.print 3
fix space
|
|
|
|
Which means that reduz' beloved style which we all became used to
will now be changed automatically to remove the first empty line.
This makes us lean closer to 1TBS (the one true brace style) instead
of hybridating it with some Allman-inspired spacing.
There's still the case of braces around single-statement blocks that
needs to be addressed (but clang-format can't help with that, but
clang-tidy may if we agree about it).
Part of #33027.
|
|
By adding a reference to the 'Microsoft.NETFramework.ReferenceAssemblies' nuget
package, we can build projects targeting .NET Framework with the dotnet CLI.
By referencing this package we also don't need to install Mono on Linux/macOS
or .NET Framework on Windows, as the assemblies are taken from the package.
|
|
This reverts commit ec7b481170dcd6a7b4cf0e6c1221e204ff7945f3.
This was wrong, `d` is not a distance but the `d` constant in the
parametric equation `ax + by + cz = d` describing the plane.
|
|
|
|
Causes issues with some editors as it's confused with `string.Empty`.
Should use `string.IsNullOrEmpty(str)` instead.
|
|
Add a Color constructor for Color with alpha
|
|
|
|
|
|
|
|
Added marshalling for `System.Collections.Generic.List<T>` and
`System.Collections.Generic.Dictionary<TKey, TValue>`.
|
|
|
|
A few extra renames for classes which were missed in last week's PRs.
|
|
[Mono] Add Vector2i and Vector3i
|
|
These have conversion operators between their non-integer equivalents. Vector2i to Vector2 is implicit, while Vector2 to Vector2i is explicit. All conversion code is done in the integer files, so Vector2.cs contains no reference to Vector2i etc.
|
|
Don't store GC handles for C# script instances and instance bindings as 'Ref<MonoGCHandle>'; store the raw data instead. Initially this was not possible as we needed to store a Variant, but this had not been the case for a looong time yet the stored type was never updated.
|
|
Implementation for new Variant types Callable, Signal, StringName.
Added support for PackedInt64Array and PackedFloat64Array.
Add generation of signal members as events, as well as support for
user created signals as events.
NOTE: As of now, raising such events will not emit the signal. As such,
one must use `EmitSignal` instead of raising the event directly.
Removed old ThreadLocal fallback class. It's safe to use thread_local now since
it's supported on all minimum versions of compilers we support.
|
|
|
|
Mono/C#: Add missing parameters to 'ResourceLoader.Load<T>()'
|
|
|
|
|
|
objects and made them default.
|
|
Handle removal of Pool*Array types and other recent changes.
|
|
|
|
Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are
sugar for `Vector<Type>`.
|
|
|
|
Those keywords were deprecated for 3.1 in #22087.
Also fix token name for `TK_REMOTE`, should be "remote" like the keyword.
|
|
The behavior for Basis and Transform2D is unchanged, and Transform gets new behavior. All of the behavior is identical to GDScript's behavior.
|
|
Use uint/ulong for Color in C#
|
|
Closes #35598
|
|
|
|
|
|
GetNodeOrNull<T> was using GetNode instead of GetNodeOrNull
|
|
|
|
|
|
|
|
|
|
|
|
Up until now, 'GD.Print' would convert parameters first to
Variant and only then to String. This meant parameters that cannot be
converted to Variant would be printed as "Null".
This commit makes 'GD.Print' fallback to 'System.Object.ToString()'
if the parameter could not be converted to Variant.
The same applies to all 'GD.Print' variants:
'GD.PrintS', 'GD.PrintT', 'GD.PrintErr' and 'GD.PrintRaw'.
|
|
|
|
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.
|