Announcement

Collapse
No announcement yet.

Mono C# Bindings for Unreal 4

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    #46
    Originally posted by alg0801 View Post
    Why do you need C# bindings? Honestly C++ isn't that complicated to use...

    You really just need to get used to the interaction between classes and pointers across your project.

    The only real annoying part is having the rebuild your project and re-open the editor any time you add a class/variable. The better you plan your project, the less this will effect you.
    Better tooling support, faster build times, CLI gives you access to all sorts of languages such as F#.

    Actually I find C++ in VS2013 so horrible that I just write my code in vim.
    Last edited by maikklein; 03-31-2014, 08:31 PM.

    Comment


      #47
      Originally posted by Acenth View Post
      Mainly to learn about the engine more. I don't really have much to offer Vince's project yet, since I only just started. My experience with embedding Mono until this week had been zero.

      We also don't know when Vince will release his version, so I figured I'd at least try get something working until then.
      We are currently looking at releasing v1 of our C# implementation by June. We are also planning on an evaluation, indie, and pro build of the plugin.

      Great to hear how ambitious the community is with embedding mono. One word of caution is on the GC side of things. You'll want to use SGEN for an embedded Mono implementation. Otherwise you'll start running into memory thunking issues pretty quickly. Embedding Mono is no small task in UE4 and requires some serious thought as to what the outcome should be for UE4 developers. Are you looking calling the engine or calling the C# DLL? What about integration with BluePrints?

      Also another word of caution. Our solution takes advantage of the existing macros in the engine used for declaring BluePrint exposure such as UFUCTION() UCLASS() UPROPERTY() macros decorated across the codebase using a clever little macro setup that is engaged by the UBT.

      ================

      Right now we have a C# based UE4.DLL which can be included in any standard C# compiler as well as used by our own compiler built directly into the UE4 Editor. On the C++ side we have a MonoRuntime and Script Engine Plugin for Engine as well as a Script Editor Plugin for Editor.

      The UE4 C# library currently as it stands binds to the entire Game Framework sanely as well as any inherited classes that the Game Framework uses. So this includes common game logic UClasses like Actor, PlayerController, and Pawn (just to name a few). We have also binded Core and several other necessary parts of the engine.

      You will have a few setup steps in C++ before you can begin using the Plugins with your game. You'll need to setup the Plugin in your Game DLL. We are working on ways to overcome this step to make this feel as natural as possible to C# developers.

      We also provide a Script Editor which lives inside of the UE4 Editor which allows developers to write and compile C# directly in UE4! We use the mcs to compile C# scripts into DLLs which are placed alongside the C++ Binaries.

      We are shooting for the most natural Unreal Coding experience possible in C#.

      Here are some screenshots:
      Click image for larger version

Name:	mcs.jpg
Views:	1
Size:	12.2 KB
ID:	1049946

      Click image for larger version

Name:	Script.jpg
Views:	1
Size:	12.0 KB
ID:	1049947

      Click image for larger version

Name:	HelloWorld.jpg
Views:	1
Size:	15.6 KB
ID:	1049948

      Click image for larger version

Name:	New.jpg
Views:	1
Size:	5.8 KB
ID:	1049949

      Click image for larger version

Name:	editor.jpg
Views:	1
Size:	17.6 KB
ID:	1049951
      Attached Files

      Comment


        #48
        Originally posted by MoHoe
        @Acenth: vincemektek posted that he's been working on this for over a year now, so why are you going through all the trouble? why don't you work with him on this?

        I thinks it's great what you're trying to do Acenth, I'm just curious why you're going to commit so much time and effort when vincemektek has done most of it already?
        Because he's going to charge for his plugin.
        KITATUS
        "Information shouldn't be behind a paywall, It should be free for all!"

        Comment


          #49
          I bet the performance will suck. Best to suck it up and use C++/blueprints.

          Comment


            #50
            Originally posted by cman View Post
            I bet the performance will suck. Best to suck it up and use C++/blueprints.
            Why do you think that?

            Comment


              #51
              Originally posted by cman View Post
              I bet the performance will suck. Best to suck it up and use C++/blueprints.
              Originally posted by maikklein View Post
              Why do you think that?
              Because you should always base designs on what you think, with no empirical evidence. That's not how everyone engineers solutions?

              Comment


                #52
                Originally posted by Joviex View Post
                Because you should always base designs on what you think, with no empirical evidence. That's not how everyone engineers solutions?
                he could be a time traveler tbh
                First Person Weapons Pack
                Mirror's Edge Fanart Environment
                Portfolio at: juniez3d.tumblr.com

                Comment


                  #53
                  Originally posted by vincemektek View Post
                  We are currently looking at releasing v1 of our C# implementation by June. We are also planning on an evaluation, indie, and pro build of the plugin.
                  Hi Vince,

                  Thanks for updating us. Can you provide more details on how you plan to licence this? I really hope you don't plan to close-source your C# implementation as I think everyone here is keen to keep the open standard Epic has set in their commercial pricing model. Otherwise I think its a great idea to commercialize it - Should mean a more solid implementation on your part and if you keep it open I'm sure your customers (Us included) will be happy to contribute.

                  Comment


                    #54
                    Originally posted by maikklein View Post
                    Why do you think that?
                    Give me a reason why I shouldn't?

                    Comment


                      #55
                      Originally posted by Scott Richmond View Post
                      Hi Vince,

                      Thanks for updating us. Can you provide more details on how you plan to licence this? I really hope you don't plan to close-source your C# implementation as I think everyone here is keen to keep the open standard Epic has set in their commercial pricing model. Otherwise I think its a great idea to commercialize it - Should mean a more solid implementation on your part and if you keep it open I'm sure your customers (Us included) will be happy to contribute.
                      I'd assume with the eval, indie and pro he mentioned. Evaluation will be just that. Indie will be a closed source license and cheap. Pro would be open source and cost more.

                      Originally posted by cman View Post
                      Give me a reason why I shouldn't?
                      Give me a reason why I should think it will suck.

                      Anyways. Looking forward to seeing this come out.

                      Comment


                        #56
                        Originally posted by Ocid View Post
                        I'd assume with the eval, indie and pro he mentioned. Evaluation will be just that. Indie will be a closed source license and cheap. Pro would be open source and cost more.



                        Give me a reason why I should think it will suck.

                        Anyways. Looking forward to seeing this come out.
                        It will probably have a performance similar to Unity, but with far more problems. Do you know anything about VM's?

                        Comment


                          #57
                          Originally posted by MoHoe
                          It's good to hear that vince will have a price plan. I prefer to pay for the efforts that he has put into it and also it's better to have an on going commitment to this project, in my experience when a man has has a solid income he has less time to worry about finances and can focus on the project. 100% happy to pay and look forward to it. Well done Vince.

                          @cman : I've used unity's C# and I see no major problem with performance.. It's not as fast as C++ but I think everyone knows that already. I'm prepared to have a performance hit using C# if it means I as a one mans band will realistically be able to complete a project.

                          If you are so much against C# implementation then why are you here in this thread?
                          I'm not against C# at all, I'm being realistic. If you wanted a slow engine why aren't you using Unity? Anything larger than a non trivial project in Unity runs into memory issues.
                          Do you know anything about VM's?

                          Comment


                            #58
                            Originally posted by cman View Post
                            I'm not against C# at all, I'm being realistic. If you wanted a slow engine why aren't you using Unity? Anything larger than a non trivial project in Unity runs into memory issues.
                            Do you know anything about VM's?
                            Please enlighten us.

                            Comment


                              #59
                              Originally posted by maikklein View Post
                              Please enlighten us.
                              In C++ you have deterministic control over memory but not in a C# VM. How do you bind UE4 memory control system to a VM so that get the 2 to synch and not cause performance problems?
                              You need to introduce some form of determinism which will take it out of C# VM spec. See here memory management: http://msdn.microsoft.com/en-us/libr...(v=vs.95).aspx

                              Comment


                                #60
                                That's where you are wrong. I am not an C# expert but in the last talk from Herb Sutter, he mentions that C# has deterministic low level memory control. (At least in .NET. I don't know about Mono)
                                Last edited by maikklein; 04-06-2014, 11:16 AM.

                                Comment

                                Working...
                                X