The blog post mentions that C# support is coming toward the end of 2025. How extensive will support for the language be? Will it be limited to just scripts, or will it also be supported for object events as well?
#Extent of C# Support
analog agate
austere turret
I can assume that delegates (passing a function as a parameter and calling it) are already working, and the appearance of user events is essentially a reaction to your own user functions. That is, right now you can create structures or objects with arrays of functions that will be called in a simple version (and in a more complex one, too, when you can use a sortable list of wrappers and methods to emulate subscription/unsubscription).
It has not yet been explained to us whether the API for connecting external libraries will change, but the runtime environment (YYC/GMRT) is different from the CSharp runtime environment. so I don't think it's going to be that deep of an integration.
forest reef
From talks around Discord in the past it'll be limited to scripts only.
Also, I presume it'll only implement C# specification and otherwise use GM runtime library for actual functionality, as opposed to implementing .NET functionalities, like reflection and stuff. (I mention that, because I've seen someone hoping for the latter)
simple tundra
For C# support we are using the dotnet 8 (we might start with dotnet 9, as they have added some features that are desirable for console platforms) platform from Microsoft - this means that it will have 2 runtimes working hand in hand - the dotnet one and the GameMaker one - we will have an interop layer that allows conversion of types and data to flow between the 2 sides and when you are in C# you will have full access to its functionalities.
We have said for a while that this will be at a Script layer only (so you cannot write Object Events, or Timeline events in C#) but anything that uses Scripts can be used
jagged moat
For C# support we are using the dotnet 8 (we might start with dotnet 9, as they ...
"We have said for a while that this will be at a Script layer only (so you cannot write Object Events, or Timeline events in C#) but anything that uses Scripts can be used"
Is that the same case for Javascript and Typescript?
simple tundra
No JS and through that TS will be first class languages so they will have full support in Object Events etc.
TS will be compiled to JS first and then that will provide all the support required (NOTE: this is how TS is normally handled in any environment)
forest reef
To clarify: does "using the dotnet 8/9" mean that any entity from .NET Core 8/9 built-in functionality will be available in GM too?
(at least as far as the given platform permits)
For example, would I be able to use ReadOnlySpan<char> datatype for quick string manipulation in C# scripts?
simple tundra
that is the plan expecially for fundamental types like that
if functionality requires extra native support that is not directly provided by the dotnet runtime (and MS have not ported it over) then it will not be supported (at least by us)
so external libraries that have their own native libs will need to be explicitly ported over to be used
Like just because there is a C# OpenGL library does not mean that will work across target platforms
past hornet
How can decompilation be addressed when using C#?
I understand that the issue of decompilation is a troublesome problem even for engines that use C# as the main language.
silk terrace
For C# support we are using the dotnet 8 (we might start with dotnet 9, as they ...
wasn't there something about consoles not allowing JIT? isn't C# under that with dotnet?
jagged moat
If we take MonoGame for example, there you can't use some features because they are not allowed in Native AOT.
To port to consoles using MonoGame you have to use Native AOT.
Unity I believe also doesn't support some features.
I wouldn't expect to have all features available, as GameMaker will probably have to use Native AOT too when porting to consoles.
simple tundra
We will have the same restrictions as NativeAOT will be the only way we support it - this will address some of the decompilation issues as that generally only works with IL assemblies and they will NOT be used for final releases
so those restrictions will be in place - I don't have those details to hand - but you can look them up on the internet