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'.
Sometimes Visual Studio documents have the root path all in upper case.
Since Godot doesn't support loading resource files with a case insensitive path,
this makes script resource loading to fail when the Godot editor gets code
completion requests from Visual Studio.
This fix allows the resource path part of the path to be case insensitive. It
still doesn't support cases where the rest of the path is also case insensitive.
For that we would need a proper API for comparing paths. However, this fix
should be enough for our current cases.
ToolButton has no redeeming differences with Button;
it's just a Button with the Flat property enabled by default.
Removing it avoids some confusion when creating GUIs.
Existing ToolButtons will be converted to Buttons, but the Flat
property won't be enabled automatically.
This closes https://github.com/godotengine/godot-proposals/issues/1081.
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 was a regression from 93d7ec8836 (#38110).
Mono's old implementation of Microsoft.Build hardcodes HasUnsavedChanges to
always return true.
This workaround can be reverted once we switch to official Microsoft.Build.
- Include PDB files in exported games.
- Release export templates also allow debugging now.
Right now the only way to enable debugging in exported games is with the environment variables, which may be cumbersome or not even possible on some platforms.
Right now, games only work on devices when exported with FullAOT+Interpreter.
There are some issues left that need to addressed for FullAOT alone. Right now,
it's giving issues with the Godot.NativeCalls static constructor.
- Travis: Change x11 to linuxbsd
- SCons: Change x11 plataform to linuxbsd
- Plugins: Remove ; to avoid fallthrough warning
- DisplayServerX11: Implement set_icon
- DisplayServerX11: Fix X11 bug when a window was erased from windows
map, all the changes from that erased windows are sending to the main
window
- DisplayServerX11: Reorder create_window commands
- DisplayServerX11: Change every Size2 to Size2i and Rect2 to Rect2i
where it belongs
+ More X11 fixes which have been integrated directly back into reduz's
original commits while rebasing the branch.
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.
As our script class parser is error prone, we should not impede the build from continuing because of a parsing error.
This should be reverted in the future once we switch to Roslyn.
Previously we had a placeholder solution called 'Managed' to benefit from
tooling while editing the a part of the C# API.
Later the bindings generator would create the final 'GodotSharp' solution
including these C# files as well as the auto-generated C# API.
Now we replaced the 'Managed' solution with the final 'GodotSharp' solution
which is no longer auto-generated, and the bindings generator only takes
care of the auto-generated C# API.
This has the following benefits:
- It's less confusing as there will no longer be two versions of the same file
(the original and a generated copy of it). Now there's only one.
- We no longer need placeholder for auto-generated API classes, like Node or
Resource. We used them for benefiting from tooling. Now we can just use the
auto-generated API itself.
- Simplifies the build system and bindings generator. Removed lot of code
that is not needed anymore.
Also added a post-build target to the GodotTools project to copy the output to
the data dir. This makes it easy to iterate when doing changes to GodotTools,
as SCons doesn't have to be executed anymore just to copy these new files.
