The current code style guidelines forbid the use of `auto`.
Some uses of `auto` are still present, such as in UWP code (which
can't be currently tested) and macros (where removing `auto` isn't
easy).
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.
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 🎆
I couldn't find a tool that enforces it, so I went the manual route:
```
find -name "thirdparty" -prune \
-o -name "*.cpp" -o -name "*.h" -o -name "*.m" -o -name "*.mm" \
-o -name "*.glsl" > files
perl -0777 -pi -e 's/\n}\n([^#])/\n}\n\n\1/g' $(cat files)
misc/scripts/fix_style.sh -c
```
This adds a newline after all `}` on the first column, unless they
are followed by `#` (typically `#endif`). This leads to having lots
of places with two lines between function/class definitions, but
clang-format then fixes it as we enforce max one line of separation.
This doesn't fix potential occurrences of function definitions which
are indented (e.g. for a helper class defined in a .cpp), but it's
better than nothing. Also can't be made to run easily on CI/hooks so
we'll have to be careful with new code.
Part of #33027.
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.
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.
- 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.
EngineDebugger is the new interface to access the debugger.
It tries to be as agnostic as possible on the data that various
subsystems can expose.
It allows 2 types of interactions:
- Profilers:
A subsystem can register a profiler, assigning it a unique name.
That name can be used to activate the profiler or add data to it.
The registered profiler can be composed of up to 3 functions:
- Toggle: called when the profiler is activated/deactivated.
- Add: called whenever data is added to the debugger
(via `EngineDebugger::profiler_add_frame_data`)
- Tick: called every frame (during idle), receives frame times.
- Captures: (Only relevant in remote debugger for now)
A subsystem can register a capture, assigning it a unique name.
When receiving a message, the remote debugger will check if it starts
with `[prefix]:` and call the associated capture with name `prefix`.
Port MultiplayerAPI, Servers, Scripts, Visual, Performance to the new
profiler system.
Port SceneDebugger and RemoteDebugger to the new capture system.
The LocalDebugger also uses the new profiler system for scripts
profiling.
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.
Up until now debug builds would always wait up to 500 ms during initialization
to give time for debuggers to attach to the game.
We no longer want this as it increases startup time unnecesarily.
The way forward is to setup the debugger agent as client instead of server.
This way it's the game that connect to the debugger, not the other way around.
If server mode is still desired, suspend=y can be used to indefinitely wait
for the debugger to attach. This all can be specified with the environment
variable 'GODOT_MONO_DEBUGGER_AGENT' when launching the game.
This appears to be necessary for current official builds cross-compiled
with MinGW from Linux, using Mono 6.6.0.160.
Follow-up to #31784, see #29812 for details.
- Added correct config file for android dllmaps.
- Fix __Internal DllImports with a dlopen fallback.
- Add missing P/Invoke functions and internal calls expected by the monodroid BCL and our custom version of the 'Android.Runtime.AndroidEnvironment' class (this last one can be found in the godot-mono-builds repo).
- Make sure to set 'btls' instead of 'legacy' as the default TLS provider on Android.
API hashes cannot be calculated on release builds, as bindings information is lacking. Therefore, we should not be comparing it with the generated glue hash as they will never match.
This will be used for communicating between the Godot editor and external IDEs/editors, for things like opening files, triggering hot-reload and running the game with a debugger attached.
Previously, when running the project manager, we would try to load the API assemblies from the project and fail because we were not editing any project. This would make us try to copy the prebuilt API assemblies to the project. Since there is no project, it would try to copy them to the executable location. This would fail if Godot doesn't have permissions to write to that location.
This commit fixes that by instead trying to load the prebuilt API assemblies in the first place, if running the project manager.
By default, an unhandled exception will cause the application to be terminated; but the project setting `mono/unhandled_exception_policy` was added to change this behaviour.
The editor is hard-coded to never terminate because of unhandled exceptions, as that would make writing editor plugins a painful task, and we cannot kill the editor because of a mistake in a thirdparty plugin.
If both the core and editor API assemblies are missing or out of sync, Godot will only update the former and then abort when trying to load them again because the latter was not updated. Godot will update it correctly the next time it's started, but this should not be needed and it should work the first time. This commit fixes that.
Remove the old API assembly invalidation system. It's pretty simple since now the editor has a hard dependency on the API assemblies and SCons takes care of prebuilding them.
If we fail to load a project's API assembly because it was either missing or outdated, we just copy the prebuilt assemblies to the project and try again. We also do this when creating the solution and before building, just in case the user removed them from the disk after they were loaded.
This way the API assemblies will be always loaded successfully. If they are not, it's a bug.
Also fixed:
- EditorDef was behaving like GlobalDef in GodotTools.
- NullReferenceException because we can't serialize System.WeakReference yet. Use Godot.WeakRef in the mean time.
Make the build system automatically build the C# Api assemblies to be shipped with the editor.
Make the editor, editor player and debug export templates use Api assemblies built with debug symbols.
Always run MSBuild to build the editor tools and Api assemblies when building Godot.
Several bugs fixed related to assembly hot reloading and restoring state.
Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
- Only load the scripts metadata file when it's really needed. This way we avoid false errors, when there is no C# project, about missing scripts metadata file.
Apparently we don't need to call mono_debug_close_image ourselves and we can call mono_image_close right away as it's not our duty to keep that reference.
Also fixed a wrong ifdef that was causing Mono to never be initialized if mscorlib was not found (which was the case with the utf8 assemblies path bug this commit fixes).
This condition was meant for exported projects only, not for the editor only.
This is needed to avoid aborting due to missing mscorlib for projects that do not use C#.
If 'res://.mono/' exists, then we assume the project uses C#, in which case a missing mscorlib should still abort.
- Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project
- GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly
- This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
- Bundle editor dependencies:
- 'GodotSharp': Root data directory for the editor
- 'Tools': Editor dependencies. Only GodotSharp.dll for now.
- 'Api': Prebuilt GodotSharp and GodotSharpEditor API assemblies.
- 'Mono': Mono files to bundle with the editor.
- 'bin': (Optional, not used for now) Mono bin directory.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- 'lib/mono/4.5': Framework assemblies.
- Added build option to copy the required files from the mono installation to 'GodotSharp/Mono'. Enable with 'copy_mono_root=yes'. Disabled by default.
- Export template dependencies:
- 'data_AppName'/'data_Godot':
- 'Mono': Mono files to bundle with the game.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- The data directory is generated when compiling and must be bundled with the export templates. In the case of OSX, the data directory must be placed inside the 'osx.zip' export template.
- In OSX, alternative location for directories (needed for app bundles) are:
- 'data_AppName/Mono/etc' --> '../Resources/GodotSharp/Mono/etc'
- 'data_AppName/Mono/lib' --> '../Frameworks/GodotSharp/Mono/lib'
- The editor can bundle prebuilt API assemblies.
- Generate them with a tools build by running: `--generate-cs-core-api <GodotSharp_OutputDir> --generate-cs-editor-api <GodotSharpEditor_OutputDir> <GodotSharp_OutputDir>/bin/Release/GodotSharp.dll` (This command will be simplified in the future and both projects will be in the same solution)
- Build the solutions and copy the output files to '#bin/GodotSharp/Api'.
- Fixed API assembly being added twice during the export process.
This allows more consistency in the manner we include core headers,
where previously there would be a mix of absolute, relative and
include path-dependent includes.
When a Reference managed instance is garbage collected and its finalizer is called, it could happen that the native instance is referenced once again before the finalizer can unreference and memdelete it. The workaround is to create a new managed instance when this happens (at least for now).
- We no longer generate RID and NodePath C# classes. Both will be maintained manually.
- We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base).
- We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class.
This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code).
- Added missing 'RID(Object from)' constructor to the RID C# class.
- Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED.
- Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
This commit makes operator[] on Vector const and adds a write proxy to it. From
now on writes to Vectors need to happen through the .write proxy. So for
instance:
Vector<int> vec;
vec.push_back(10);
std::cout << vec[0] << std::endl;
vec.write[0] = 20;
Failing to use the .write proxy will cause a compilation error.
In addition COWable datatypes can now embed a CowData pointer to their data.
This means that String, CharString, and VMap no longer use or derive from
Vector.
_ALWAYS_INLINE_ and _FORCE_INLINE_ are now equivalent for debug and non-debug
builds. This is a lot faster for Vector in the editor and while running tests.
The reason why this difference used to exist is because force-inlined methods
used to give a bad debugging experience. After extensive testing with modern
compilers this is no longer the case.
- Setup runtime main args during initialization. This must be done manually by embedders who do not call mono_runtime_run_main. Fixes NullReferenceException in System.Environment.
- Continue to search the assembly in the rest of the search locations if loading it from one of them failed.
The heuristic whether we're in the project manager inside GDMono
didn't work if the project manager was launched by not having any path
to run.
This is fixed now by making a Main::is_project_manager().
