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.
(cherry picked from commit 671467b888)
Added `SystemConfiguration.framework` to the Xcode project to fix
undefined symbols errors building without the interpreter, like:
`_SCNetworkReachabilityScheduleWithRunLoop`.
Added explicit static constructors to the generated `NativeCalls`
class to avoid a `TypeInitializationException` at startup when
Godot attempts to read the static fields (like `godot_api_hash`)
from this class.
This seems to be an issue with Mono's AOT compiler and classes
with the `beforefieldinit` attribute. Not sure if it only happens
when the fields are only accessed via reflection as was our case.
Explicitly declaring the static constructor makes the C# compiler
not add the `beforefieldinit` attribute to the class.
We use `Mono.Cecil` to search for P/Invoke methods in assemblies in
order to collect symbols that we must prevent from being stripped.
We could pass the symbols as `-u` linker arguments (`-Wl,-u,symbol`)
for the native target (not for the project), but it was simpler to
generate referencing code and avoid changes to Godot's iOS exporter.
Replaced obsolete preprocessor check for simulator/device in C code.
Architecture can no longer be used to determine this with Apple Silicon.
The new code uses `TARGET_OS_SIMULATOR` from `TargetConditionals.h`.
We have some mono libs which can only be used in devide builds.
We were adding them as static libs. Previously it was only causing
warnings because missing arch for the simulator, but now this
is treated as an error.
To fix this we turn them into xcframeworks with dummy static libs
for the simulator and the actual ones for devices.
This changes the types of a big number of variables.
General rules:
- Using `uint64_t` in general. We also considered `int64_t` but eventually
settled on keeping it unsigned, which is also closer to what one would expect
with `size_t`/`off_t`.
- We only keep `int64_t` for `seek_end` (takes a negative offset from the end)
and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means
we only need to guard against passing negative values in `core_bind.cpp`.
- Using `uint32_t` integers for concepts not needing such a huge range, like
pages, blocks, etc.
In addition:
- Improve usage of integer types in some related places; namely, `DirAccess`,
core binds.
Note:
- On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with
version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for
big files on 32-bit Windows builds made with that toolchain. We might add a
workaround.
Fixes#44363.
Fixesgodotengine/godot-proposals#400.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
We decided to rename the upcoming 3.2.4 release to 3.3 to better reflect that
it is a significant feature release, and not a maintenance update.
The `3.2` branch was also renamed to `3.x` and will now be the development
branch for future 3.x releases (3.3, 3.4, etc.).
`Main::cleanup()` prints warnings if it finds `StringName`s still alive.
We need the `BindingsGenerator` to be destructed before calling cleanup.
(cherry picked from commit d9603b2d73)
- 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)
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
(cherry picked from commit b98e8b11e6)
- Avoid spaces in Mono log file names.
- Use a `.log` extension for Mono logs, just like non-Mono logs.
- Use periods to separate hours/minutes/seconds for non-Mono logs.
(cherry picked from commit 4d81776fc9)
Makes it let's bothersome to work with builds from our
godotengine/godot-mono-builds scripts, as they write the
BCL into an output directory separate from the runtime
(which is good as two runtimes may share the same BCL).
(cherry picked from commit dd5ace219d)
The property has no effect as the older VS project system doesn't
work with Sdk style projects.
The presence of the property was preventing Visual Studio for Mac
from opening the project if the Godot extension is not installed.
Allow game projects to use a Godot.NET.Sdk with a newer patch version.
The major and minor version are still required to be the same.
For example: Allow a Godot 3.2.4 C# project to use a hypothetical
3.2.5 version of Godot.NET.Sdk.
- Removed item list that displayed multiple build
configurations launched. Now we only display
the last build that was launched.
- Display build output next to the issues list.
Its visibility can be toggled off/on.
This build output is obtained from the MSBuild
process rather than the MSBuild logger. As such
it displays some MSBuild fatal errors that
previously couldn't be displayed.
- Added a context menu to the issues list with
the option to copy the issue text.
- Replaced the 'Build Project' button in the panel
with a popup menu with the options:
- Build Solution
- Rebuild Solution
- Clean Solution
- The bottom panel button was renamed from 'Mono'
to '.NET' and now display an error/warning icon
if the last build had issues.
When NormalizePath was called with an absolute
path (with drive letter) on Windows, it would
prepend a file path separator to the path, e.g.:
'\C:\Program Files\'.
Apparently this was still accepted as a valid
path by DotNetGlob and it stopped working when
we switched to MSBuildGlob.
(cherry picked from commit 1db0395950)
At least on Windows there seems to be issues if
the solution has no BOM and contains a project
with cyrillic chars.
(cherry picked from commit 1c74fa4242)
MSBuild Item returns empty strings if an attribute isn't set (which
caused an IndexOutOfRangeException in NormalizePath).
We were treating Excludes incorrectly, Remove directives provide the
intended behaviour in the auto-including csproj format.
This error was normally being printed when
trying to open the project assembly while
the project was not yet built.
The error should not be printed. It's the job
of this method's caller to decide whether to
print an error or not if loading failed.
The editor wasn't clearing the debugger agent
settings properly after a processing a play
request from an IDE. This caused consequent play
attempts to fail if not launched from the IDE,
as the game would still attempt and fail to
connect to the debugger.
The concrete cause: Forgetting to clear the
`GODOT_MONO_DEBUGGER_AGENT` environment variable.
(cherry picked from commit 6e7da72648)
This is a cherry-pick of
ced77b1e9b
with several 3.2 specific alterations.
There are a lot of build issues coming from
old style projects. At this point fixing every
single one of those would require adding patch
after patch to the project file, which is a
considerable amount work and makes the csproj
even more bloated than it already is.
As such I decided this effort would be better
spent back-porting the Sdk style support that's
already available in 4.0-dev to the 3.2 branch.
This will prevent many issues, but it will also
introduce other benefits, among them:
- While target framework stays as .NET Framework
v4.7.2, it can be changed to .NET Standard 2.0
or greater if desired.
- It makes it much easier to add future patches.
They are added to Godot.NET.Sdk and the only
change required in Godot code is to update the
Sdk version to use.
- Default Godot define constants are also
backported, which fixes IDE issues with the
preprocessor.
There are a few differences in the changes
applied during patching of the csproj compared
to 4.0 with the purpose of preventing breaking
builds:
- 'TargetFramework' stays net472 both for new
projects and when importing old ones. It can
be manually changed to netstandard 2.0+ if
desired though.
The following features are enabled by default for
new projects. Enabling them in imported projects
may result in errors that must be fixed manually:
- 'EnableDefaultCompileItems' is disabled as it
can result in undesired C# source files being
included. Existing include items are kept.
As long as 'EnableDefaultCompileItems' remains
disabled, Godot will continue taking care of
adding and removing C# files to the csproj.
- 'GenerateAssemblyInfo' is disabled as it
guarantees a build error because of conflicts
between the existing 'AssemblyInfo.cs' and the
auto-generated one.
- 'Deterministic' is disabled because it doesn't
like wildcards in the assembly version (1.0.*)
that was in the old 'AssemblyInfo.cs'.
Of importance:
This is a breaking change. A great effort was
put in avoiding build errors after upgrading a
project, but there may still be exceptions.
This also breaks forward compatibility. Projects
opened with Godot 3.2.3 won't work out of the box
with older Godot versions. This was already the
case with changes introduced in 3.2.2.
Albeit C# support in 3.2.x was still labeled as
alpha, we've been trying to treat it as stable
for some time. Still the amount of problems this
change solves justifies it, but no more changes
that break project compatibility are to be
introduced from now on (at least for 3.x).
This upgrade is needed in order to support
reading and editing project files that use Sdks
as well as other new features. A common example
in 3.2 is having to specify a PackageReference
version with a child element rather than the
attribute. This is no longer the case now.
Partial cherry-pick of f3bcd5f8dd
Most of the other changes from that commit were already partially
cherry-picked in 3928fe200f.
Not sure if we should check revision too, but this is good enough for what we want.
This will be needed to load the correct Microsoft.Build when we switch to the nuget version.
Manual cherry-pick of af4acb5b11 (relevant parts)
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
(cherry picked from commit d2461bad63)
For some reason `mono_unhandled_exception` is not
printing the exception as its comment claims.
Use `mono_print_unhandled_exception` instead.
(cherry picked from commit f87ae395ee)
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.
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)
Simple fix for #38627. iOS (#20268) and HTML5 (#20270) removed from list of exceptions
for platforms supported in warning message.
(cherry picked from commit 3d03be7a56)
Any C# file can be loaded as script and at load
time we don't yet know if it's actually meant to
be used as a script. As such, such an check can
result in a lot of false errors.
If the file is really meant to be used as a
script, an error would be printed later when
attempting to instantiate it any way.
(cherry picked from commit 38cd2152e6)
When a child scene inherits a parent scene with a C# root node, the
parent scene's export variables appear to assume values set in the
parent scene, in the child scene's Inspector. However, when the child
scene is played, the parent scene's export variables assume default
values.
When a node is created, it inherits its parent C# script's fields from
the map CSharpScriptInstance::script->member_info. However this map was
not initialized outside the editor, and this commit ensured it is. This
fixes issues #36480 and #37581.
This is a manual backport of PR #38638 for 3.2.
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.
- Make GodotTools output directly to the SCons output directory.
- Removed xbuild_fallback from the build system.
(cherry picked from commit b61ffef0ab)
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.
(cherry picked from commit 81f13f6171)
- 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.
(cherry picked from commit 71fc87e101)
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.
MinGW should support both its own format `.a` and MSVC's format `.lib`, but Mono's module was only using the former. With this change it's now possible to build with MinGW and link the official Mono for Windows which is built with MSVC.
