C# support - Githubissues

vroad commented 8 years ago

My fork already has C# support, and I want this to be merged so that everyone can use/contribute to it. From where should I start? maybe from lime-tools and CFFI loader?

ibilon commented 8 years ago

That's probably something that needs to be "all at once": tools/ndll/cffi, at least enough to have the hello world sample run.

james4k commented 8 years ago

Is there a good reason to add a C# target? On Jun 20, 2016 5:55 AM, "Valentin Lemière" notifications@github.com wrote:

That's probably something that needs to be "all at once": tools/ndll/cffi, at least enough to have the hello world sample run.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openfl/lime/issues/763#issuecomment-227111367, or mute the thread https://github.com/notifications/unsubscribe/AAuwMg6rDd9spHzs1GF6Tc8LOytXZr3bks5qNnGvgaJpZM4I44kR .

vroad commented 8 years ago

It compiles faster than cpp.
On CoreCLR, app runs faster than cpp in some situations. On Mono, performance is not good as cpp, but not so bad.
You might be able to make app part crossplatform, like neko.
Debuggable with Visual Studio or Xamarin Studio.
C# Supports #line directive, which is similar to JavaScript's source maps.
It runs on Android, and is debuggable over adb. Probably we can support iOS in the future as well.

vroad commented 8 years ago

I found a problem while preparing a new PR. App crashes with AccessViolationException when renderer is deleted. Probably because finalizer is called from a different thread than the one created OpenGL context?

vroad commented 8 years ago

I think that we need to manage OpenGL contexts by ourselves to get rid of this problem. It's strange to use OpenGL context created by SDL's renderer.

james4k commented 8 years ago

Are these good enough reasons to add another target that will need to be maintained/supported indefinitely? Can the project take on the additional maintenance burden? What kind of users would take advantage of this? I don't want to shoot this down, just feel like I have to point out the costs.

This is a separate discussion, but why not improve the cpp target?

vroad commented 8 years ago

This will not increase maintenance burden much since it uses the same native backend as cpp/neko/nodejs. Adding another backend other than native/html5, such as Unity backend, may incur maintenance burden as you said.

Improving performance/stability/usability of hxcpp itself is out of my scope. I'm not familiar with hxcpp code base at that level, and it's just difficult to implement fastest garbage collector. I know that some developers are working on GUI debugger for VS code, but its readme says it's still unstable.

vroad commented 8 years ago

hxcpp itself is mostly stable, though, I ran into some weird crash issues before. On C# it's difficult to make app crash at native level unless you do something wrong in unsafe or native code. So stability is also one of the reasons I'd like to support C#.

I don't know much about cppia actually. Is that stable now? Does that work in the same way as other VMs? Debugging doesn't seem to be supported on cppia.

tienery commented 8 years ago

@vroad Have you used MonoGame before? Because if you have I think externing that library is probably more beneficial than adding a C# target that will likely require lots of [ImportDLL] externs to OpenGL to get it to function properly. And if that were the case, you might as well use an existing wrapper for C#, which just adds another layer on top of the Haxe-generated code.

Sure if you can get the GLRenderer to point to OpenGL calls correctly in C# using an up-to-date wrapper, then cool.

This article on StackOverflow provides an answer to using C++ over C# for three fairly important reasons, performance I think being at the top.

And even if it is nice to have C# as a target, those programmers who are more conscious of performance will choose C++ over C#, hand-written or otherwise.

vroad commented 8 years ago

@tienery No, you don't need to wrap them with DllImport manually. As I mentioned in previous posts, C# target works in the same way as existing native targets such as C++, neko, and nodejs. It loads native functions at runtime with LoadLibrary or dlopen. I haven't tried MonoGame yet, but isn't that an open source implementation of XNA? I think it's hard to maintain another backend in addition to html5 and native.

Also, I don't think C# is always slower than C++, because JIT compiler can make use of information that is only available at runtime, and its runtime has better garbage collector, etc. Mono's JIT is not as fast as CoreCLR or hxcpp, but I think it's not so bad.

You can also parallelize loops on C#. I don't think it's directly supported on hxcpp currently.

vroad commented 8 years ago

Should I send pull request anyway? That will give other developers an opportunity to try this out.

jgranick commented 8 years ago

I'm very interested, especially if its simple to test. Who knows, it might replace C++ or Neko as a standard Windows testing target

vroad commented 7 years ago

lime samples now works with official version of lime, though it still crashes at exit.

jgranick commented 7 years ago

Although we have C# (initially), there are improvements needed to make it really valuable. I've opened a new issue to track that :smile:

https://github.com/openfl/lime/issues/881

openfl / lime

C# support #763