possible C# support?

[PublicVoidUpdate]

i have been asking around and c# on psvita is already difficult given only unity and psm, so this is less a feature request and more a way to open up conversation. id love to use c# on vita in an open source non-abandonware way.

[c08oprkiua]

It might be possible through some CIL (what C# compiles into) conversion layer like what Unity does. In fact, not Sony related, but that's what Nintendo did/does for Unity for 3DS, Wii U, Switch, etc.

[PublicVoidUpdate]

does godot not already compile to cil? what does godot compile c# to then?

[c08oprkiua]

Well, from what I understand, C# gets compiled into CIL, and then that CIL is then read by the .NET runtime to run tasks.

So, someone would either have to port .NET itself to the Vita, or make something that takes the functional place of it.

Which imo, Godot should look into doing the latter anyways, but I digress.

[PublicVoidUpdate]

what would you say is the best method? porting dotnet or making an interpreter for psvita?

[c08oprkiua]

I don't know, I've never messed with .NET nor C# much. But if a CIL interpreter that directly talked to Godot was made, it would be possible to add that to Godot as a whole, not just this project, and then Godot wouldn't need the .NET runtime per say. Or, in down-the-river terms, it would help everyone everywhere, official or fork, so you might be able to get more people interested in making/helping on such a thing, not just us who are interested in Godot on a depreciated handheld.

[technicaljicama]

Right.. Godot compiles to .Net now? I believe it was mono some time ago. Anyway, PSM seems to be a subset of .NET 2.2.. This might be useful: https://github.com/GrapheneCt/VitaMonoLoader

[Delsin-Yu]

If you are talking about something similar to IL2CPP VM, I doubt it's possible to achieve on that Godot end (Unity itself is tightly integrated with their custom fork of Mono VM where Godot is not).

The NativeAOT publish mode of the modern dotnet (.Net 6+) might be a good entry point. It compiles the CIL directly into native code. However, I think is a long journey to add extra platform support for NativeAOT.

A feasible option would be writing a custom GDExtension plugin or modifying the source code to boot a dotnet runtime at the initialization level, similar to how the Godot mono module bootstraps the CoreCLR runtime via HostFXR.

I misunderstood the comment, PSVita does not have a built-in dotnet runtime, so a custom compiler that compiles a subset of C# into native / cpp code is required.

This VitaMonoLoader looks like a good candidate that suits the requirement.

[c08oprkiua]

I disagree. Remember, GDscript itself is a module in Godot, not integrated as part of the main engine, and it is capable of interacting with 90% of the engine. I don't think something that would communicate with Godot on the same level, except with CIL instead of GDscript scripts, would be impossible by any means.

Furthermore, modules are essentially an even more integrated version of GDNative/GDExtension, so if it's possible in a GDExtension, it's possible in a module.

[Delsin-Yu]

Compared to GDScript, C# is a lot more complicated than a scripting language, that's why it compiles into CIL, you need a runtime rather than an interpreter for running CIL (or you are sacrificing a majority of C# functionality).

CIL itself cannot be run directly by the operating system, you require at least a VM to translate it into the native code on the fly. While existing VMs (Mono, CoreCLR) already have their mechanism to achieve C#-Godot interoperability, the elephant in the room is to find a VM that executes CIL on the PSVita platform.

I doubt that PSVita allows JIT, so a compiler that compiles CIL into Cpp or Native code is required. That's a primary reason Unity develops libil2cpp since it's way easier to maintain a subset of the C# functions than porting the whole Mono VM onto every platform they support / will support (and most platforms are shipped with their Cpp compiler so the user code can compile directly into the target platform native code).

[c08oprkiua]

Yes. This module would ultimately not replace the full capabilities of current C# in Godot, rather making it possible for people who only use C# as a more familiar/comfortable alternative to GDscript (ie. Exclusively in the engine, for engine scripting) to export their game to more platforms.

And no, GDscript is not any more complicated than C#, at least on an overall level. Both compile to bytecode files, and then a runtime does something with those bytecode files at program execution, whether it's JIT compilation, AOT compilation at startup, simply parsing it as an instruction sheet, whatever. However GDscript has been doing it, seems to work for exported platforms, so this would likely be a mimic of that, but interpreting CIL instead of gdscript's bytecode language (I couldn't find an actual name for it).

[technicaljicama]

I might give it a shot later, if I don't forget it lol

[PublicVoidUpdate]

if you do i would be very thankful. if i wanted to get deeper understanding what would you recommend? right now i only really know c# for game design.

[technicaljicama]

I'd just try to port Godot's current approach to the Vita's mono runtime. The only 2 things I am afraid of, is that it wouldn't make the port all too legal (same level as the unity vita games) and second that the runtime is too old.

[Delsin-Yu]

Yes. This module would ultimately not replace the full capabilities of current C# in Godot, rather making it possible for people who only use C# as a more familiar/comfortable alternative to GDscript (ie. Exclusively in the engine, for engine scripting) to export their game to more platforms.

And no, GDscript is not any more complicated than C#, at least on an overall level. Both compile to bytecode files, and then a runtime does something with those bytecode files at program execution, whether it's JIT compilation, AOT compilation at startup, simply parsing it as an instruction sheet, whatever. However GDscript has been doing it, seems to work for exported platforms, so this would likely be a mimic of that, but interpreting CIL instead of gdscript's bytecode language (I couldn't find an actual name for it). @c08oprkiua

One liner: A stripped C# experience cannot be considered as a more familiar/comfortable alternative to GDscript, if so I'm proposing another scripting language such as TypeScript.

---

Just to be clear, this module we are talking about is intended for PSVita use right?

Currently, the best way to use C# as a more familiar/comfortable alternative to GDscript is the current C# in Godot. Stripping out most of C#'s BCL(base class library) is not considered as use C# as a more familiar/comfortable alternative to GDscript.

For example, the most recent version of Unity supports .Net Standard 2.1 (which one or two functions/modules unavailable), which you can consider as a subset of C# functionality, which is already giving dotnet developers headaches due to lack of Nuget Package support and newer C# version support (that's why they are slowly migrating to modern dotnet), I doubt the definition of your use C# as a more familiar/comfortable alternative to GDscript does not fit the actual familiar/comfortable need for dotnet development.

In conclusion, this custom C# language interpreter module with minimal BCL would be a feasible trade-off for cross-platforming support, but why not look towards a typed script language such as TypeScript?

[c08oprkiua]

The module would be for general Godot, not just Vita. A Vita specific solution could be implemented, but imo, it would be more worth it to make this a universal module for as many platforms to use. So, this applies to Vita, but is also a more general solution to a much wider issue with Godot.

And what exactly is implemented on the C# side of things is not my wheelhouse. I'd imagine a lot of the BCL can be substituted by Godot's in-house functions, and the rest can be filled in courtesy of taking notes from .NET or Mono's source code and recontextualizing that in the context of how Godot works. Or, make a whole mini .NET port inside Godot. Idk. As long as the backend code handling the CIL does what the dev wants/expects it to do, I'm not amazingly concerned with how the backend is implemented.

And who said anything about a trade off? No, this would exist alongside current C# support. In fact, for platforms like Windows and Linux, the current C# solutions would probably still be preferred. This solution fills the need in cases where A. The dev wants a completely self contained export (no need for the user to have a CIL runtime installed) B. The platform in question does not have a CIL runtime, or its current solutions are undesired for whatever reasons there may be.

And I'm not looking at other languages here because C# has official Godot integration while those others do not. But yeah something like this could probably be implemented for any other language too I guess lol

[Delsin-Yu]

Well... I totally understand that version of minimal C# language you described, and probably even know the details about implementation.

I'm just expressing the point that implementing such minimal C# with godot BCL would take too much effort (not worth it) than just creating a binding for scripting language...

Or I can say what you just described is another scripting language that's similar to C# in syntax, If you just want the barebone syntax, we can just ditch the whole CIL stuff.

[c08oprkiua]

That sounds good to me. I'll go ahead and throw it out there, though, that I have no personal experience with needing a solution to this issue (I have never used C#, whether with Godot or otherwise, and at most have only read over other people's code), so I'm also not the right person to bounce ideas off of if you want a real "game dev who uses C# in Godot" take. I myself think that if the syntax is identical, C# devs probably wouldn't mind using a scripting language C# clone, or at the very least they can copy-paste their C# when they need to use the integrated clone language instead, but I'm also not an actual C# dev, so idk if that would be good enough in practice or not.

But, for what it's worth, it gets my thumbs up of approval

[Delsin-Yu]

From my experience in Unity and Godot-Mono, I'm afraid the answer is no.