Commit graph

69 commits

Author SHA1 Message Date
Ignacio Roldán Etcheverry
d78e0a8426 C#: Make GodotSharp API a NuGet package
In the past, the Godot editor distributed the API assemblies and
copied them to project directories for projects to reference them.
This changed with the move to .NET 5/6. Godot no longer copies the
assemblies to project directories. However, the project Sdk still
tried to reference them from the same location.
From now on, the GodotSharp API is distributed as a NuGet package,
which the Sdk can reference.

Added an option to `build_assemblies.py` to copy all Godot NuGet
packages to an existing local NuGet source. This will be needed
during development, while packages are not published to a remote
NuGet repository.
This option also makes sure to remove packages of the same version
installed (~/.nuget/packages). Very useful during development, when
packages change, to make sure the package being used by a project is
the same we just built and not one from a previous build.

A local NuGet source can be created like this:

```
mkdir ~/MyLocalNuGetSource && \
dotnet nuget add source ~/MyLocalNuGetSource/ -n MyLocalNuGetSource
```
2022-08-22 03:36:51 +02:00
Ignacio Roldán Etcheverry
4b90d16250 C#: Initial NativeAOT support
This commit adds initial support for games exported as NativeAOT shared
libraries.

At this moment, the NativeAOT runtime is experimental. Additionally,
Godot is not trim-safe as it still makes some use of reflection.
For the time being, a rd.xml file is needed to prevent code triming:

```
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
  <Application>
    <Assembly Name="GodotSharp" Dynamic="Required All" />
    <Assembly Name="GAME_ASSEMBLY" Dynamic="Required All" />
  </Application>
</Directives>
```

These are the csproj changes for publishing:

```
  <PropertyGroup>
    <NativeLib>Shared</NativeLib>
  </PropertyGroup>
  <ItemGroup>
    <RdXmlFile Include="rd.xml" />
    <PackageReference Include="Microsoft.DotNet.ILCompiler" Version="7.0.0-*" />
  </ItemGroup>
```

More info:
- https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/compiling.md
- https://github.com/dotnet/runtimelab/tree/feature/NativeAOT/samples/NativeLibrary
- https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/rd-xml-format.md
2022-08-22 03:36:51 +02:00
Ignacio Roldán Etcheverry
18f805b3aa C#: Upgrade to .NET 6 (5.0 -> 6.0) 2022-08-22 03:36:51 +02:00
Ignacio Roldán Etcheverry
e22dd3bc6a C#: Static marshaling for bindings and source generators
Previously, we added source generators for invoking/accessing methods,
properties and fields in scripts. This freed us from the overhead of
reflection. However, the generated code still used our dynamic
marshaling functions, which do runtime type checking and box value
types.

This commit changes the bindings and source generators to include
'static' marshaling. Based on the types known at compile time, now
we generate the appropriate marshaling call for each type.
2022-08-22 03:36:51 +02:00
Ignacio Roldán Etcheverry
92503ae8db C#: Add source generator for properties and exports default values
The editor no longer needs to create temporary instances to get the
default values. The initializer values of the exported properties are
still evaluated at runtime. For example, in the following example,
`GetInitialValue()` will be called when first looks for default values:

```
[Export] int MyValue = GetInitialValue();
```

Exporting fields with a non-supported type now results in a compiler
error rather than a runtime error when the script is used.
2022-08-22 03:36:51 +02:00
Ignacio Roldán Etcheverry
88e367a406 C#/netcore: Add base desktop game export implementation
This base implementation is still very barebones but it defines the path
for how exporting will work (at least when embedding the .NET runtime).

Many manual steps are still needed, which should be automatized in the
future. For example, in addition to the API assemblies, now you also
need to copy the GodotPlugins assembly to each game project.
2022-08-22 03:36:51 +02:00
Ignacio Roldán Etcheverry
4d710bf659 C#: Add initial implementation of source generator for script members
This replaces the way we invoke methods and set/get properties.
This first iteration rids us of runtime type checking in those
cases, as it's now done at compile time.
Later it will also stop needing the use of reflection. After that,
we will only depend on reflection for generic Godot Array and
Dictionary. We're stuck with reflection in generic collections
for now as C# doesn't support generic/template specialization.

This is only the initial implementation. Further iterations are
coming, specially once we switch to the native extension system
which completely changes the way members are accessed/invoked.
For example, with the native extension system we will likely need
to create `UnmanagedCallersOnly` invoke wrapper methods and return
function pointers to the engine.

Other kind of members, like event signals will be receiving the
same treatment in the future.
2022-08-22 03:36:51 +02:00
Ignacio Roldán Etcheverry
f9a67ee9da C#: Begin move to .NET Core
We're targeting .NET 5 for now to make development easier while
.NET 6 is not yet released.

TEMPORARY REGRESSIONS
---------------------

Assembly unloading is not implemented yet. As such, many Godot
resources are leaked at exit. This will be re-implemented later
together with assembly hot-reloading.
2022-08-22 03:35:59 +02:00
bruvzg
8823eae328
Rename OSX to macOS and iPhoneOS to iOS. 2022-07-21 09:37:52 +03:00
Raul Santos
d5d1645e15 Bump Godot.NET.Sdk and SourceGenerators versions
Bump `Godot.NET.Sdk` to version 4.0.0-dev6.
Bump `Godot.SourceGenerators` to version 4.0.0-dev3.
Use floating version 4.0.*-* for package references in Sdk.
2021-12-05 15:56:18 +01:00
Raul Santos
c52f21335c Fix Godot.SourceGenerators for generic classes
Fix invalid C# generated by source generators for generic classes and
add generic classes to the Sample project for testing.
2021-12-05 15:52:25 +01:00
Aaron Franke
5f8275d9ac
Add a simple C# .editorconfig 2021-07-23 17:04:53 -04:00
Ignacio Etcheverry
ee8e5146a4 C#: Fix ScriptPathAttribute generator with none or nested namespaces
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.
2021-03-13 01:04:59 +01:00
Ignacio Etcheverry
e2afe700f6 Add C# source generator for a new ScriptPath attribute
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.
2021-03-06 21:50:32 +01:00
Ignacio Etcheverry
64b5ee7010 C#: Make editor create NuGet fallback folder for Godot packages
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/'.
2020-10-23 10:54:49 +02:00
Rémi Verschelde
1af3cf15c2
Mono: Fix typo in Godot.NET.Sdk.nuspec
Fixes #42666.
2020-10-09 13:37:07 +02:00
Aaron Franke
42e70a77ef
Rename the ".mono" folder to ".godot/mono" 2020-09-23 15:42:29 -04:00
Rémi Verschelde
3e78963bb9
Fix typos with codespell
Using codespell 1.17.1.

Method:
```
$ cat > ../godot-word-whitelist.txt << EOF
ang
curvelinear
dof
doubleclick
fave
findn
leapyear
lod
merchantibility
nd
numer
ois
ony
que
seeked
synching
te
uint
unselect
webp
EOF

$ codespell -w -q 3 -I ../godot-word-whitelist.txt --skip="./thirdparty,*.po"
$ git diff // undo unwanted changes
```
2020-09-18 13:44:25 +02:00
Ignacio Etcheverry
ced77b1e9b 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'.
2020-07-25 19:22:01 +02:00