search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.18k stars 21.2k forks source link

C# status and plans towards 3.1 #18364

Closed neikeq closed 5 years ago

neikeq commented 6 years ago

I'm opening this issue to inform other developers interested in the mono module about the current status and the plans towards 3.1.

As you may have notice, I've been quite inactive during the last month and a half. This is related to my studies, and there is nothing that can be done about it. This low activity will sadly continue until June 14, approximately, when I will finally be free once and for all to focus entirely on Godot.

Since I will have very little time to dedicate to Godot during this period of time, I decided to make a list of essential tasks that need to done for the 3.1 milestone, and postpone everything else for future releases. The list is the following:

Other developers are free to make contributions to any area. However, keep in mind that I may leave them aside for review after 3.1 is released if I don't consider them essential for this release. Please, let me know if you think I'm forgetting something in the list above.

I'm keeping this issue open for discussion.

neikeq commented 6 years ago

Finish project exporting. This is almost done. It's just missing exporting the right mono runtime library for the target platform, making it work with the Export PCK/Zip(-only) option, and more testing of course.

Just to clarify, it's already possible to test project exporting. All you need is to compile the export templates and place them in $HOME/.local/share/godot/templates/3.1.dev.mono/ (%APPDATA%/Godot/templates/3.1.dev.mono/ on Windows). You will have to copy the mono runtime library manually as mentioned above. Keep in mind only desktop platforms are supported for now.

KellyThomas commented 6 years ago

Long term which platforms can we expect to support mono exports?

PJB3005 commented 6 years ago

I believe that eventually the plan is to support ALL platforms, even web (MSIL -> wasm is something that mono and such are working on).

With the GodotSharpTools bit & build: don't you mean GodotSharpEditor? I thought that was the one that needed it to build the csproj files and such.

neikeq commented 6 years ago

Platforms:

Desktop: Right now, we support the x11, Windows and OSX platforms. I didn't test on Server, UWP and *BSD yet, but they may be working already. Mono does not fully support Haiku yet. Mobile: We will support both Android and iOS. The Android port should be straightforward. iOS exporting will require the extra step of compiling the assemblies ahead of time. WebAssembly: There is work to bring the Mono runtime to WebAssembly, so this should be possible in the future. I'm not sure if embedders can test it at its current state. Consoles: No idea. All I know is there are ports provided by third parties.

With the GodotSharpTools bit & build: don't you mean GodotSharpEditor? I thought that was the one that needed it to build the csproj files and such.

GodotSharpTools is the one that the editor uses for reading/editing with csproj files, building solutions and executing MonoDevelop. GodotSharp and GodotSharpEditor are the API assemblies. I will rename them to GodotAPI and GodotEditorAPI respectively before 3.1 to avoid confusion.

PJB3005 commented 6 years ago

For what it's worth, I can definitely tell you that Server loads up successfully for the purposes of exporting to Windows. Haven't tried to run actual code on it though.

On Mon, Apr 23, 2018, 10:47 Ignacio Etcheverry notifications@github.com wrote:

Platforms:

Desktop: Right now, we support the x11, Windows and OSX platforms. I didn't test on Server, UWP, BSD and Haiku yet, but they may be working already. Mobile: We will support both Android and iOS. The Android port should be straightforward. iOS exporting will require the extra step of compiling the assemblies ahead of time. WebAssembly: There is work to bring the Mono runtime to WebAssembly, so this should be possible in the future. I'm not sure if embedders can test it at its current state. Consoles:* No idea. All I know is there are ports provided by third parties.

With the GodotSharpTools bit & build: don't you mean GodotSharpEditor? I thought that was the one that needed it to build the csproj files and such.

GodotSharpTools is the one that the editor uses for reading/editing with csproj files, building solutions and executing MonoDevelop. GodotSharp and GodotSharpEditor are the API assemblies. I will rename them to GodotAPI and GodotEditorAPI respectively before 3.1 to avoid confusion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/18364#issuecomment-383500986, or mute the thread https://github.com/notifications/unsubscribe-auth/AHu1w6os8QgftKsVEE3aMDufzeSygNMaks5trZUWgaJpZM4Te_7X .

DevMagicLord commented 6 years ago

I'm interest a lot in C#. Mainly because Object Oriented language and because game source code is obfuscated when the game is published unlike GDscript.

LaurentOngaro commented 6 years ago

thanks for this info. Is the following compatibility bug planned for the next devs ? Running a C# project with a 32 bits binary on a 64 bits windows causes a crash I think It's important because , if I'm right, only 64 bit versions with mono can be used and exported till now.

aaronfranke commented 6 years ago

Shall we turn this post into a [Tracker] with a list of to-do items via - [ ]?

DevMagicLord commented 6 years ago

Instead of to-do create new individual issues for each item.

raymoo commented 6 years ago

@DevMagicLord Isn't GDScript compiled to bytecode before packaging?

so-rose commented 6 years ago

Just to clarify, it's already possible to test project exporting. All you need is to compile the export templates and place them in $HOME/.local/share/godot/templates/3.1.dev.mono/ (%APPDATA%/Godot/templates/3.1.dev.mono/ on Windows). You will have to copy the mono runtime library manually as mentioned above. Keep in mind only desktop platforms are supported for now.

So, I tried to do exactly this. It didn't work! I thought I'd report my findings for the record - perhaps it can be of some use for you later @neikeq!

My commands were (from a totally clean repository clone at 1113a738baeabebbee0d51f9c51d4f842fba0fda):

# Build Godot to Generate Glue
scons p=x11 tools=yes module_mono_enabled=yes mono_glue=no -j 32
bin/godot.x11.tools.64.mono --generate-mono-glue modules/mono/glue

# Build Godot w/Mono
scons p=x11 target=release_debug tools=yes module_mono_enabled=yes -j 32

# Generate Export Templates
scons p=x11 target=debug tools=no module_mono_enabled=yes -j 32
scons p=x11 target=release tools=no module_mono_enabled=yes -j 32

I then copied the export templates to $HOME/.local/share/godot/templates/3.1.dev.mono/ as described, and renamed them to match the distributed export templates.

I proceeded to open the built editor, godot.x11.opt.tools.64.mono, with a test project (which contains no C# code whatsoever - it's entirely GDscript; there isn't even a .csproj file) and export a Linux/X11 Build to res://bin/. I then copied the following files to the same folder as the export:

When I ran the exported project, this happened:

$ ./test.x86_64 
Mono: Initializing module...
ERROR: _initialize_and_check_api_hashes: Mono: Core API hash mismatch!
   At: modules/mono/mono_gd/gd_mono.cpp:318.
Mono: Runtime initialized
Mono: INITIALIZED
<Black Screen>
^C

There's the error! It is, in fact, the error described in #14584 .

My mono version is 5.10 - not sure if that matters:

Mono JIT compiler version 5.10.1.20 (tarball Thu Mar 29 10:48:35 UTC 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
    TLS:           __thread
    SIGSEGV:       altstack
    Notifications: epoll
    Architecture:  amd64
    Disabled:      none
    Misc:          softdebug 
    Interpreter:   yes
    LLVM:          supported, not enabled.
    GC:            sgen (concurrent by default)
Zireael07 commented 6 years ago

My mono version is 5.10 - not sure if that matters:

Yes it matters, Godot supports only 5.4.

paulloz commented 6 years ago

My mono version is 5.10 - not sure if that matters:

Yes it matters, Godot supports only 5.4.

That is only true when you're using the released binaries. When you're compiling yourself you can pretty much use any recent Mono version.

PJB3005 commented 6 years ago

@so-rose I believe that is the issue to be fixed by #18514

neikeq commented 6 years ago

Yes, that issue is fixed by #18514. Although it shouldn't prevent your game from working, it's just a false warning.

You don't need to copy GodotSharpTools.dll and mscorlib.dll with the exported game. GodotSharpTools is editor only, and the editor already copies mscorlib (inside the PCK file). libmonosgen-2.0.so is not needed when static linking mono. You can do that with mono_static=yes when building.

Export PCK/ZIP works with Mono now, so the only thing missing is copying the mono shared libraries (if they were linked dynamically), and project exporting will be done.

mhilbrunner commented 6 years ago

From https://github.com/godotengine/godot/issues/19101:

Things that I'd expect before I'd consider C# production ready, in order of importance:

To explain the last point:

IMO, we need to test C# more widely before calling it production ready. I propose to release 3.1 (or 3.0.3) with working exporting and wait for some (to be determined) time after that, seeing what issues crop up, before calling it that.

Because if I was one of the first users to run into export issues because thats a new functionality, and C# as a whole was called production ready, I'd be upset. Opinions?

neikeq commented 6 years ago

That's what beta is for, isn't it?

aaronfranke commented 6 years ago

Would anyone be opposed to renaming Fposmod() in Mathf to Mod()?

  1. None of the other float-returning methods start with the letter F

  2. It's not PascalCase if you count pos and mod as words

  3. The pos distinction is not necessary because for "non-positive modulus" also known as "remainder" there's already an operator in C# called %. People using the Mathf function would only ever be looking for something that wasn't in the C# language.

  4. Mod() looks a lot cleaner than Fposmod().

As someone who uses this function a lot in my code, I would definitely appreciate this change.

EDIT: https://github.com/godotengine/godot/pull/19231

paulloz commented 6 years ago

I hate to be the person bringing back the same thing over again but I think the generic GetNode (#16871) is still something that'd be good to address before being production ready (it can be seen as part of the «API should be mostly final» part).

PJB3005 commented 6 years ago

18773 is something that I feel also needs doing before we can mark C# as stable.

PJB3005 commented 6 years ago

Would it be a good idea to make the docs have a doc-wide language toggle between C# and GDScript? Then we can deviate at least semi mildly from the GDScript API without making things too confusing.

neikeq commented 6 years ago

For the info, I will be finally back on Wednesday next week.

mhilbrunner commented 6 years ago

@PJB3005 I fear that would lead to two completely distinct sets of documentation in the long term.

aaronfranke commented 6 years ago

@PJB3005 @mhilbrunner Is there no way to do this similar to how Unity has their docs, which has examples for both C# and JS? https://docs.unity3d.com/ScriptReference/MonoBehaviour.Start.html See language toggle at top-right.

vnen commented 6 years ago

@aaronfranke current docs already do something like that (see the code snippets http://docs.godotengine.org/en/latest/getting_started/step_by_step/your_first_game.html). The problem I see is writing a whole new Class API docs just for C#.

exts commented 6 years ago

@vnen http://godotsharp.net/api/ someone seemed to already generated it. the crazy part about that generation is it's showing the changes between versions O_o. maybe we can get in contact w/ that guy to do a PR for the official api docs?

vnen commented 6 years ago

@exts I don't know who maintains that, but generating such pages isn't that hard and not even the problem. My issue is with writing new docs just for C# (that is, something that can't be automated).

mhilbrunner commented 6 years ago

Also, not only writing those new docs but maintaining them.

neikeq commented 6 years ago

The class reference description for the generated API is automatically generated from the existing class reference. It's still not translating it from bbcode to xml tags, but that can be easily solved. A problem would be translating the GDScript code examples (inside code tags) in the generated bindings to C#, if we desire to do so. I don't see any problem in maintaining docs for the part of the API we write manually.

aaronfranke commented 6 years ago

Should Printerr be changed to PrintErr? Currently kinda looks like "Printer".

EDIT: https://github.com/godotengine/godot/pull/20337

akien-mga commented 6 years ago

I've opened some issues to discuss Mono/C# support for the remaining platforms:

Nufflee commented 6 years ago

I'm working on #12917 and #12415.

neikeq commented 6 years ago

@Nufflee Good luck. You may get stuck due to #10946 though. At least that's what happened to me last time I tried.

Nufflee commented 6 years ago

@neikeq Hmm, I'm not too sure how that's really related to this but we should probably continue this conversation in the PR.

aaronfranke commented 6 years ago

Another minor issue, I noticed that the Vector Lerp method in Godot is called "LinearInterpolate" rather than the shorter and probably more familiar "Lerp". More familiar to users, since it's called Lerp in Unity. The name "LinearInterpolate" is also inconsistent with the other method "Slerp" which isn't expanded to "SphericalLinearInterpolate". And most importantly, this is inconsistent with the Mathf.Lerp method.

Would anyone be opposed to changing "LinearInterpolate" to "Lerp"? I would also have to change the C++ code to "lerp" in order to be consistent, or I can just change the C# code if that's desired.

EDIT: https://github.com/godotengine/godot/pull/20371 (no C++ changes, for now, as per Nathan's suggestion)

NathanWarden commented 6 years ago

I think your suggestion would make the Godot API itself more consistent since the default floating point math function is also called lerp. I wouldn't be opposed to it being Lerp in C#, and at some point it would make sense for the C++ side to also be called lerp. I'm not opposed at all to changing the C++/GDScript side now, but I think API breakages may not be wanted in the 3.x series. I guess it can't hurt to just make a PR explaining the issue.

exts commented 6 years ago

@NathanWarden I believe since c# is unstable breakage should be allowed with 3.1

savuori commented 6 years ago

Should Sync Script Changes work with .cs files as well? Live updating code would be super handy for exploratory development and fine-tuning.

immccc commented 6 years ago

Maybe a bit offtopic, but as the code of my game is constantly growing, and I prefer C#/Mono for a list of reasons, but haven't used it so far because its non fnished status, perhaps a good idea would be to have a GDScript to C# converter, so that there is a basis that will make refactoring code to C# easier.

aaronfranke commented 6 years ago

@immccc You are welcome to develop that feature, but I don't think that would be very easy to do, and it would always be imperfect. If you want to switch your code to C# it's best to do it manually.

immccc commented 6 years ago

@aaronfranke that would be imperfect for sure and the user will have to review and tune each source file, but the amount of tedious work writing file per file as a middle age scribe monk is saved, at least a considerable part :) (or that's the idea)

robgraeber commented 6 years ago

For those wondering how you’d even approach a gdscript converter, there was a guy a few years ago who made a Obj-C to C# converter. The way he did it was first convert it to TXL, which is an intermediary language made for this thing, then convert it to C#.

http://razum.si/automagical/about

On Sat, Aug 25, 2018 at 1:15 AM immccc notifications@github.com wrote:

@aaronfranke https://github.com/aaronfranke that would be imperfect for sure and the user will have to review and tune each source file, but the amount of tedious work writing file per file as a middle age scribe monk is saved, at least a considerable part :) (or that's the idea)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/18364#issuecomment-415952428, or mute the thread https://github.com/notifications/unsubscribe-auth/ACRvBzJ4xG-aRijv4Vy5h523AJm3YBSmks5uUQe0gaJpZM4Te_7X .

aaronfranke commented 6 years ago

Should Cartesian2Polar and Polar2Cartesian be in Vector2 instead of Mathf?

swarnimarun commented 6 years ago

@aaronfranke I say Vector2 makes more sense. As even a polar vector is a vector.

Byteron commented 6 years ago

I hope this is the right issue for that: I was wondering if it would be possible to rename Classes that already exist in C#, like e.g. Godot.Dictionary to Godot.GDictionary. I had a couple of conflicts because of these having the same name.

aaronfranke commented 6 years ago

@Byteron This has already been fixed, but it hasn't arrived in a release version yet. In 3.1 and possibly 3.0.7, Godot.Dictionary will be moved to Godot.Collections.Dictionary.

Zireael07 commented 6 years ago

How soon is the bundled Mono coming?

Byteron commented 6 years ago

@aaronfranke only for Dictionary, or for all shadowing classes? And thank you for the quick answer! :)

neikeq commented 6 years ago

Only Dictionary and Array for now. Are there any others that cause problems? For one, I know Thread. I would like to move it to Godot.Threading together with other related classes like Mutex and Semaphore.

Byteron commented 6 years ago

There also is Godot.Directory and System.IO.Directory.