Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

    #91
    Integrating C# would be a good move to help transition the Unity refugees. Blueprint is really great and I am still getting up to speed on it. I'm all for Visual scripting but normally these are things you give to your Level Designer so he can get down to business on his own. People coming from Unity will compare Blueprint to the popular Playmaker plugin. You just won't convince them otherwise verbally. Maybe if they saw an entire AAA game made using Blueprints for gameplay... Granted, people have visual scripted entire games using Playmaker. So anything can happen

    [edit] So I'm all for letting the community integrate Mono C# etc all they want (not suggesting Epic should do it). Personally, I will probably stick to C++ and Blueprint.
    Last edited by sandboxgod; 04-14-2014, 11:40 PM.
    Godz for UT '99 / UT 2003

    Comment


      #92
      Originally posted by zoid View Post
      I'm not sure exactly what you mean by dependencies in terms of Blueprints. Blueprints in C++ are just normal UObject classes that have some meta data via UPROPERTY and UFUNCTION macros that make blueprints aware of them so the engine can instantiate and connect them together. Any dependencies you have should only be your direct parent class.

      You should be able to place any common code you want to reuse in non-blueprint cases in a simple class of your own that is called from your Blueprint class and your non Blueprint class (i.e. a class that has no blueprintcallable properties and functions).

      Maybe I'm not understanding the complete picture?
      Im not sure this is still a work in progress as I go through the prototype and port functionality I already have from UScript so I might have overlooked something. Ive been told to treat Blueprints as classes not objects but perhaps that advice was alittle misleading, Im not entirely sure. To call a blueprint as a UClass and that blueprint has to exist first for the code to compile, unless theres something more generic Im overlooking. I do think you have simplified alittle bit, the issue being like so:

      Core C++ Classes -> Core Blueprints -> Extended Blueprints

      Core C++ Classes -> Core Blueprints -> Extended C++ Classes -> Extended Blueprints

      As you can see the extended c++ classes now rely on Blueprint Classes.


      Core C++ Classes -> Extended C++ Classes /-> Core Blueprints

      This breaks links to Core Blueprints.

      Core C++ Classes -> Core Blueprints -> Extended Blueprints
      Core C++ Classes -> Extended C++ Classes -> Extended Blueprints

      This works but will take more management and might break merges more often when classes are created and blueprints shifted around.

      Originally posted by Tim Sweeney View Post
      This is a great point, that an interop layer must necessarily be present at the interface between code and sufficiently powerful visual tools. The layer enabling C++ programmers to expose features to Blueprint layers is one example. Another example is the visual material system, where code generated for shader nodes is essentially strcat'd together behind the scenes into a shader program that is sent to DirectX or OpenGL for realtime execution on the GPU.

      The big question for engine developers is whether to utilize different programming languages for different parts of the programming pipeline, introducing an interop layer where they are partitioned.

      BTW: It's fine to compare to Unity and other engines here. Each engine arrived at a very different solution to gameplay programming, and comparing their decisions is a valuable exercise that increases everyone's understanding of the tradeoffs.
      Okay I just thought the conversation was drifting alittle far, Im certainly not against comparisons but I do come here to talk about Unreal Engine primarily for obvious reasons

      That is interesting, I have used the display source for materials so I knew it was alittle bit different to Blueprints but I had not realized it was actually working with the raw text kinda like macros. From how I see it though the visual scripting tools are a good reason to leave the real nitty gritty programming in C++, Ive seen tools come from DOS all the way through Windows to where they are now and game designers never have been so lucky as they are now with the amount of tools and the magnitude of the quality, not only that but there are really cohesive suites now compared to the past where the tools were nothing more than a gloried level design tool.

      I think the additions people will make to this refound solid base is a great reason to choose C++, Im sure it certainly helped with the source release too not having to deal with a scripting language that is essentially obsoleted with C++ access. Blueprint on the other hand has enough going for it that its worth using in places instead of text based programming and in alot of ways its easier and more straight forward than UScript, its certainly not perfect as the spaghetti monster always looms but it can be just as hard to trace code even in C++ if its written poorly enough so hopefully we'll see more people adopting good practices brought over from the school of C++.

      I can certainly see UE4 having quite the longevity, thats important for me when committing to learn a toolset and part of the reason Im not sure about taking my 3dsmax knowledge any further is because of the uncertainty behind whether Autodesk will entirely shift focus to a more cohesive linear pipeline and product line at some stage. I know UE4 will change but I trust Epic to filter down changes in the best possible manner, Ive been working on monthly UDK releases for some time now so Im used to seeing changes and additions pop up at that rate. Ive always known we use what you guys use first, anything ontop of that tends to be gravy and there is a shift in focus to taking more input from the community but I always expected C++ to be the supported language because as long as Ive known its what Epic has been using. Im not sure if the fact Unreal Engine is a virtual machine has anything to do with it either, that it needs a more portable language to make it worth while.

      For me though when we talk about gameplay programming, I cant help but see the future as a syntax independent mathematical modeled visual scripting tool which learns how its users work and adapts to that and gives them the best possible speed by staying as close to bare metal as it can. As much as people might disagree with me WYSIWYG is an extremely big thing in visualizing not just gameflow but program flow overall, so it helps on a number of different levels and I really took what you said about looking at children and the way they are picking up new technologies to mind. It just becomes clear to me that language can be a barrier we try to overcome and with that type of mentality in mind I can see why people like .net, it does have this unification theme to it in trying to remove those barriers but its still text based and programming flow is largely not done in pure text but block diagrams and flow graphs which are visual tools


      Originally posted by Ben Zeigler View Post
      MonsOlympus has some good questions from the last page, so I thought I'd describe how Fortnite is mixing C++ and Blueprints. Here's an example class hierarchy for one of our enemies:

      AActor -> AFortPawn -> AFortAIPawn -> AFortAIPawn_Husk -> HuskGeneric -> HuskThrowing

      FortPawn is C++ and has code to deal with things like our animation implementation. FortAIPawn is C++ and has the hooks for the behavior tree AI system. AFortAIPawn_Husk is very light and has a few things for increased performance. HuskGeneric is a spawnable blueprint, and has the majority of the data references built into it. HuskThrowing is a variant of HuskGeneric that throws bones, so uses most of the same data references and overrides some behavior. This structure has worked pretty well for us, but the specific decisions depend on how the team is setup. We could probably do without AFortAIPawn_Husk, it's mostly there for historical reasons, or you could make that layer an abstract blueprint or "Core blueprint". What basically happened for us is that the designers and programmers worked towards each other as we implemented new functionality, and we met in the middle. Most of the replication logic is inside the native code, most of the visual logic is in the blueprint, and most of the gameplay logic is inside other objects referenced by the blueprints. For instance the HuskGeneric blueprint actually dynamically decides what it should look like, based on random chance. That system works well the way the artists implemented it so it's implemented in the blueprint event graph. But, if something was too complicated to implement efficiently in blueprint, we'd move it to C++ and refactor the blueprint.

      A key part of the fortnite setup is that we try to avoid referenc data assets from C++ classes, and we're currently removing most of the rest of the references. We do this primarily through Object Libraries, the Async Loading doc page has a good overview of how to set that up. We use Object Libraries for things like weapons, items, enemies, etc. We load an entire directory of assets, and then expose methods to find the desired asset based on game-specific queries. It'll be something like "spawn the enemy named husk". The other method we use extensively is to have data references hanging off of a GameSingleton, I discuss the general method over at this AnswerHub question. That singleton has pointers to things like the player's initial inventory, what blueprint to use for the player's pawn in different situations, etc. Using those two methods we've removed most of the data references from our C++ classes

      If anyone has specific questions about to set up a hierarchy, ask away and I'll reply. As an example, Mons I'm not entirely sure what you meant by "I might encounter the need to have C++ Blueprint dependencies like Archetypes and Id prefer not have those hard links between external and internal classes". What specific pattern are you trying to avoid?
      Ahh thank you that is extremely helpful. My main concern is Blueprint Classes and calling Blueprint functionality from within C++, I would prefer to keep those calls all C++ native and override in Blueprint. I think its similar to what you are saying about data objects but in this case its class references because of the need to call functionality, even if I cast I still need the class of Blueprint to call the appropriate function. I was having some issues calling through C++ into the blueprint layer but that may just be a project specific issue. With the Archetypes to explain that, is that you would have to:
      • Create the class for the archetype compile.
      • Then open the editor and create the archetype.
      • Copy the reference to the asset to the clipboard close the editor and copy it into Uscript.
      • Then recompile with the asset reference linked so you could access the archetype.


      This is what creates the interdependency and if we are modifying blueprint callables or native implemented events I cant help but see us running into issues pretty quickly.
      Last edited by MonsOlympus; 04-15-2014, 12:07 AM.

      Comment


        #93
        This seems like a silly discussion really. C++ is there because we have SOURCE CODE access and the Unreal Engine was born in C++, Unity as an example doesn't give you access to their source code hence you get C#, Java, Boo languages to write your games. If they were going to leave a written scripting language available I would imagine the would have left uscript there. Regardless I know about the V8 plugins to enable JavaScript for UE4 is in development by someone. I am sure if someone out there REALLY wanted to code in C# for UE4 they could do the same, seems kind of counter productive though as it would be quicker to just code your games with the tools available but each there own (I did enjoy using C# in Unity though ) but I much prefer Blue Print
        Last edited by Chrustec; 04-15-2014, 12:07 AM.

        Comment


          #94
          Originally posted by nlaq View Post
          This thread is silly.

          People are correct in saying that C++ can outperform C# (either MS's CLR or Mono's) if written correctly. However, writing performant code in *any* language isn't a trivial task. Just writing in C++ isn't going to give you any automatic performance boost. Just as with managed code, much care needs to be taken in how you [de]allocate memory, exploit caches and architect your code.

          There very much is a sort of poisonous mentality in the games industry that native code is the only appropriate choice for all game and engine logic. I think this comes from inexperienced developers who heard someone say once that C++ can outperform C#, and didn't take the time to understand the context of that sentiment. Frankly, I wouldn't trust a developer who makes the blanket claim that C++ is the only correct choice in game development to have the experience or knowledge to correctly use C++ in the first place. The whole thought process behind people pushing C++ as the only viable language in games reeks of immaturity and unprofessionalism. An alternate explanation is that C and C++ are taught at many schools for programming and game development (for good reason: learning C++ is an excellent experience that I wish on all programmers who want to further their skills).
          I don't think any blanket statements have been made advocating C++ as the only solution to any problem. I think the case has been made that there are downsides to any managed language, and that C# and IL languages in particular lack the comparative speed and language features relative to C++ and therefore make it a less optimum choice for a large complex real-time application.

          No one is trying to make some kind of crusade for or against any particular language here.

          Just to remind you the original question on this thread was why Epic had dropped UnrealScript in favor of C++ and Blueprints.

          Originally posted by nlaq View Post
          1) Writing performant code is difficult and requires rigorous testing and deep knowledge of general computation and the specific algorithms used in this domain. A person with good programming sense can easily write managed code that outperforms native code written by someone who lacks the proper background and experience. Please don't push C++ because "it's faster" if you do not understand, for example, cache lines or proper memory allocation.
          This is a bad generalization in my opinion. Domain specific knowledge is critical in certain classes of problems, but that does not mean that language choice is irrelevant by any means. There are trade-offs.

          Generally speaking, across an application, C# is slower than C++, ranging from 2x to possibly many times slower... Pointing out that an expert programmer can write code that outperforms a monkey banging on a keyboard in C++ doesn't really make that fact any less true.

          That fact in no way means that C# or other managed languages are a poor choice for games. Minecraft was written in Java and it runs just fine.

          But UE4 is meant to push the bleeding edge. Potentially losing a factor or 2x or more off the top of a program just based on your choice of language before you write any code at all is a discussion worth having.

          Originally posted by nlaq View Post
          3) Ease of use. Ease of use is not an excuse for non-programmers to be able to write code - on the contrary. I use this term to say that a language such as C# will allow an experienced developer to write correct code more quickly; and give them the tools to architect their logic in such a way as to promote reuse and modularity (thus decreasing the amount of time required for maintenance, fixing bugs, prototyping or adding new features).
          These generalizations apply equally to C++ and C# and to any modern programming language, including Blueprints.

          Originally posted by nlaq View Post
          So what exactly am I suggesting? Basically: Unity's scripting model. I'm not going to go on a general U4 vs UE5 debate here: but I think one of the things that the Unity folks did better than Epic was expose a scripting API in C#. People can, and will continue to, write poor C# in Unity that negatively impacts performance - but the vast majority of the time, properly written code has no noticeable impact. The architectural and stability advantages are very much worth the insignificant performance penalty.
          There are no inherent stability advantages or disadvantages inherent to either language, except for garbage collection. The good and bad of GC in a real-time application is a big topic. It's also not a trivial issue. GC cycle hitches in Unity are a real issue.

          The expressive power of C++ as compared to C# allows for significantly more elegant and powerful code architecture. Slate in UE4 is a good example of this. In-fact the entire Unreal Object system is a living breathing example of the type of architectural expressiveness allowed by C++ that would never be possible in C#.

          Comment


            #95
            Originally posted by MonsOlympus View Post
            For me though when we talk about gameplay programming, I cant help but see the future as a syntax independent mathematical modeled visual scripting tool which learns how its users work and adapts to that and gives them the best possible speed by staying as close to bare metal as it can. As much as people might disagree with me WYSIWYG is an extremely big thing in visualizing not just gameflow but program flow overall, so it helps on a number of different levels and I really took what you said about looking at children and the way they are picking up new technologies to mind. It just becomes clear to me that language can be a barrier we try to overcome and with that type of mentality in mind I can see why people like .net, it does have this unification theme to it in trying to remove those barriers but its still text based and programming flow is largely not done in pure text but block diagrams and flow graphs which are visual tools
            Yeah that's the sort of thing that's gonna be really exciting. How cool would it be to use the UE4 editor in Oculus and move your hands around to build and script.

            Comment


              #96
              Originally posted by Shadowriver View Post
              People who belive in this are the once that can't grassp why so simple games like Minecraft or Fez have so high requirments and yell "opimize" at developers

              C++ compiles to direcly to CPU machine code it does not have manage code which makes you code easier in cost of prefermence. You cant go faster then that or else you create more optimal assebler code. I ammused that developer now days are so lazy and addicted to assist code that they start to discredit C++, where i belive C/C++ is first thing they should learn as this way you understand software a hell lot of better. When i first used c++ i felt free like a bird.

              Also small reminder.... Unreal Engine always had C++ coding since very begining, with *.u file you could also see associated *.dll file, but it was not avable to nonlicence users... until this point (or rether licence become cheaper). If you wonder why licenced developers could do more with UE thats a reason, they could do call to even deepest point of engine, could implement external code liberies and so on. Epic states that Blueprint is what replace UnrealScript, and give access to C++ so things fit perfecly
              C# compiles to IL but it is then just-in-time-compiled to machine code...so after the first run, it can be just as fast as C++ code compiled to machine. Furthermore you can ngen C# code right to machine code from the get go with no IL. Once it's machine code, it's all the same assuming the proper optimizations are in place and both the Microsoft C++ and C# compilers are optimized. People who aren't familiar with managed languages assume that some how they are interpreted...this not true.
              Last edited by Jarhead; 04-15-2014, 12:39 AM.

              Comment


                #97
                I'm so happy to hear about this development, Tim. To folks on the thread: the primary goal of 'managed' languages was to 'manage' a single resource: memory. Few if any other resources are managed and memory can be easily managed through constructors and destructors and classes that do simple reference counting. I used to be a big fan of things like Java and C# (and I even wrote an UnrealScript compiler a long long time ago) but am now firmly in the camp of those who feel the whole 'managed' idea was a big mistake and distraction that mainly allowed (encouraged even) a generation of programmers to be clueless about how hardware works. We need less language diversity and more focus on becoming competent with existing constructs. -B

                Comment


                  #98
                  Originally posted by zoid View Post
                  Yeah that's the sort of thing that's gonna be really exciting. How cool would it be to use the UE4 editor in Oculus and move your hands around to build and script.
                  Thats actually a really interesting idea, I had considered using a touched based interface with blueprint being able to slide nodes around and attach multiple wires using both hands to speed things up alot more and even giving digits more freedom for those precise moves. With oculus I guess it could be possible to navigate a 3D blueprint space so spaghetti might be less of an issue as it is in the 2D space since we could rotate around, really get in amongst the blueprints themselves. Whether or not its useful is another debate entirely though, personally I think program AI has to come along side or it might not work. See the windows paper clip might have been despised but we have things like JIT compilers now that do incrementally build, even UE4 does it with shaders and lighting, it builds ontop of builds so you could end up with some sort of cache brain you can access similar to the sims saved game data or even your smart phone keyboard memory.

                  Comment


                    #99
                    Originally posted by Chrustec View Post
                    This seems like a silly discussion really. C++ is there because we have SOURCE CODE access and the Unreal Engine was born in C++,
                    That's not really true. The reason why we get only C++ is because Epic decided to drop UnrealScript. If they had decided against open sourcing the engine, we still would've gotten C++ for gameplay programming.

                    Don't get me wrong, I fully support the decision to go with C++ and I relish the opportunity to do some serious C++ programming again. The last four years for me have mostly been spent on C# with some Python and Java on the side, and I've been itching to get back to C++. However, I do acknowledge that this decision leaves out a sizable group of people who are well enough programmers that Blueprint is below their level but C++ is far above their level. Providing a language in-between those two extremes could be desirable for that reason.

                    The last few days I've done a bit of philosophizing whether it might be worth the effort of integrating Python as a scripting language for UE4. But the more I think about it, the more I wonder if the problem it solves weighs up against the mass of problems it introduces. And considering the arguments in Tim Sweeney's post earlier in this thread, I would say the answer to that is "no". It might still be interesting though to provide a scripting language that acts as an alternative to the visual scripting of Blueprint, communicating against the same API and compiling down to the same internal format. That way you avoid the trouble of having to maintain a new and separate invocation layer, while still providing a compelling and useful gameplay programming language.

                    Comment


                      Originally posted by Nico de Poel View Post
                      while still providing a compelling and useful gameplay programming language.
                      It is already there. C++ it its name.

                      Comment


                        Originally posted by honeybadgertrainer View Post
                        Does Epic have some sort of style guide for C++ programming, that you either use internally or recommend for users of Unreal Engine 4?

                        (C++ is arguably a very "large" language, and every successful large C++ project that I've seen has chosen a certain subset of the language and adhered to that subset. For example, the google C++ style guide advises against exception, and the MISRA C++ standard (for industrial/embedded devices) prohibits heap allocation. And I can't find the video right now, but I remember John Carmack saying in a Q&A that he also has in his mind a "sane subset" of C++ he used for Quake 4/Rage/etc. I would love to know if Epic has something similar.)
                        Yes me too I was wondering this same thing.

                        Comment


                          I do believe some people are overlooking the obvious complexities of C++, thats not to say its bad once you actually know it and there are alot of learning resources but that is also one of the issues, with UScript for example there were a few trusted sources but for C++ there are literally topics all over which returns more false positive search hits when scouring the internet. I consider myself to be quite a capable programmer but with the removal of UScript I now consider myself largely a beginner based soley on my lack of experience with C++ and nothing more. Infact I have enough experience across C-Type languages to say I actually know more programming concepts than what the base C++ language provides.

                          Its easy to get a narrow field of view when youre always playing in that field but as soon as you step out into the surroundings things can be quite daunting, this case is non-specific but transferable skills will always trump everything else. If you honestly NEED C++ because you cant do it any other way then there is a problem, just like if I couldnt do what I was doing in UScript any other way, granted it'll take time to learn the syntax and nuances especially in C++'s case because it seems to really enjoy being just obscure enough to be frustrating.

                          This is largely based on my experience with actually writing in various languages and has little to do with the underlying semantics, Im certain sure we could show clocked times of foreach in every language vs one and other but thats not real world is it. We all know that throwing more programmers at a problem wont necessarily get it solved quicker, you'll probably just end up with multiple solutions because its clear we'll never agree on a one size fits all. It largely comes down to personal preference and I find I actually prefer C to Epic's UE4 C++ but thats an opinion and goes to how I feel about the usability and how productive I would rate myself which is actually the most important thing about this entire discussion, you can have all the speed in the world but if youre running in the wrong direction all the time its not going to help you.

                          Gameplay programmers need to be more productive than ever in this environment, we have people pushing for games to be made over a weekend and we cant do that while we are typing out macros and extra domain specific syntax all the time. That is why I would choose UScript over C++, is that its lean, I know full well the drawbacks which is why I think Blueprint is a great replacement and I do believe people saying blueprints isnt really for advanced programmers might need to open their eyes like I have. If a programmer is more productive in C++ I want to give them the tools and the backing to be able to strive in that environment and the same goes for blueprint, if I had other options like C# I could certainly be more productive in text based programming. In the end we're in the business of making products, obviously we all weigh up the pros/cons for a specific project and base our choice in third party software on that, dont we?
                          Last edited by MonsOlympus; 04-15-2014, 10:55 AM.

                          Comment


                            Originally posted by MonsOlympus View Post
                            In the end we're in the business of making products, obviously we all weigh up the pros/cons for a specific project and base our choice in third party software on that, dont we?
                            Games to be specific,

                            OOOww, why C++....
                            Ooowww, why not C#
                            ooowww, why not python
                            ooowww, now I have to learn new things.
                            ooww it is so difficult now, each error in my code blows and does not allow to compile...

                            Poor you.
                            You must understand that:
                            a) This is gaming industry and so it follows:

                            In order to have best performance you have to use C++.
                            In order to have best flexibility you have to use C++.
                            In order to have AAA games with AAA performance/visuals you have to use C++.

                            Get it!

                            No java, c# or other slow mo creature can provide you with it. Get it, deal with this and be grateful...

                            P.S.
                            The only sources on C++ you need:

                            1. Bjarne Stroustrup - Programming: Principles and Practice Using C++
                            2. Bjarne Stroustrup - The C++ programming Language 4th edition
                            3. Andrei Alexandrescu - Template metaprogramming

                            In that order, study them, and you'll will be flying.
                            Last edited by smallB; 04-15-2014, 12:56 PM.

                            Comment


                              I couldn't agree more with Tim that PINVOKING the entire UE4 engine is a nightmare. That was one of my earlier mistakes working on our UE4 C# Plugin. You'll never PINVOKE this engine in its current development state and expect to be able to maintain it easily over time. Even using a tool like SWIG to do the majority of your script binds is a total nightmare... well maybe not a nightmare but at least a bad dream.

                              Though while C++ may be superior because of its the lowest common denominator (well... whose discrediting assembly here its not particularly the best for game scripting when you start lacing it with what C++ really is which is templates and complex macros which is evident by the presence of BluePrints in UE4 which simplifies all that and packs it down to ByteCode. If you are working with a diverse indie team with many different skill sets you are unlikely to be able to utilize your team with just C++. Game designers that work in BluePrint often prototype and then programmers need to pull that logic down to a scripting language like C++. Its nice to have alternatives. Most game engines I've worked with had this ability in some form or another.

                              This is why I opted for the PINVOKE'LESS methodology provided by the Mono Runtime. I only picked Mono because they already had the technology developed for internal calls and I believe C# is a great addition to UE4.

                              How does it work?

                              The Mono runtime provides two mechanisms to expose C code to the CIL universe: internal calls and native C code. Internal calls are tightly integrated with the runtime, and provide no support for marshalling between runtime types and C types.

                              For example, passing a C# string will result into a MonoString* in the C function when using an internal call (that is, it will be a pointer to the managed heap object representing the string). A C# string passed to a PINVOKE C function will result instead in, for example, a utf8 char pointer, depending on the marshalling attributes.

                              To make the runtime lookup the symbol in the current executable, we use the special library name __Internal.

                              The "__Internal" library name will instruct Mono not to look this up in an external library, but to try to satisfy the symbol referenced (DoSomething) in the current executable image.
                              Code:
                              using System.Runtime.InteropServices;
                               
                              [DllImport ("__Internal", EntryPoint="DoSomething")]
                              static extern void DoSomething ();
                              If you want direct access to managed objects you can register C code with the runtime, and later bind to it from managed code.

                              Code:
                              mono_add_internal_call ("Hello::Sample", sample);
                              From there its just a matter of declaring it on the C# side and calling the method.

                              What we've done with our C# implementation is created a macro which understands BluePrint callables and uses Epic's very own logic for exposing native C functionality to BluePrint. We are able to adhere to the rules of BluePrint yet produce a fully working C# API.

                              Combined with Mono's SGEN GC its a fairly efficient approach. Certainly nothing prevents developers from still maintaining complex code at the C++ level and allowing game design to take place in C#.

                              Comment


                                Originally posted by vincemektek View Post
                                I couldn't agree more with Tim that PINVOKING the entire UE4 engine is a nightmare. That was one of my earlier mistakes working on our UE4 C# Plugin. You'll never PINVOKE this engine in its current development state and expect to be able to maintain it easily over time. Even using a tool like SWIG to do the majority of your script binds is a total nightmare... well maybe not a nightmare but at least a bad dream.

                                Though while C++ may be superior because of its the lowest common denominator (well... whose discrediting assembly here its not particularly the best for game scripting when you start lacing it with what C++ really is which is templates and complex macros which is evident by the presence of BluePrints in UE4 which simplifies all that and packs it down to ByteCode. If you are working with a diverse indie team with many different skill sets you are unlikely to be able to utilize your team with just C++. Game designers that work in BluePrint often prototype and then programmers need to pull that logic down to a scripting language like C++. Its nice to have alternatives. Most game engines I've worked with had this ability in some form or another.

                                This is why I opted for the PINVOKE'LESS methodology provided by the Mono Runtime. I only picked Mono because they already had the technology developed for internal calls and I believe C# is a great addition to UE4.

                                How does it work?

                                The Mono runtime provides two mechanisms to expose C code to the CIL universe: internal calls and native C code. Internal calls are tightly integrated with the runtime, and provide no support for marshalling between runtime types and C types.

                                For example, passing a C# string will result into a MonoString* in the C function when using an internal call (that is, it will be a pointer to the managed heap object representing the string). A C# string passed to a PINVOKE C function will result instead in, for example, a utf8 char pointer, depending on the marshalling attributes.

                                To make the runtime lookup the symbol in the current executable, we use the special library name __Internal.

                                The "__Internal" library name will instruct Mono not to look this up in an external library, but to try to satisfy the symbol referenced (DoSomething) in the current executable image.
                                Code:
                                using System.Runtime.InteropServices;
                                 
                                [DllImport ("__Internal", EntryPoint="DoSomething")]
                                static extern void DoSomething ();
                                If you want direct access to managed objects you can register C code with the runtime, and later bind to it from managed code.

                                Code:
                                mono_add_internal_call ("Hello::Sample", sample);
                                From there its just a matter of declaring it on the C# side and calling the method.

                                What we've done with our C# implementation is created a macro which understands BluePrint callables and uses Epic's very own logic for exposing native C functionality to BluePrint. We are able to adhere to the rules of BluePrint yet produce a fully working C# API.

                                Combined with Mono's SGEN GC its a fairly efficient approach. Certainly nothing prevents developers from still maintaining complex code at the C++ level and allowing game design to take place in C#.
                                I genuinely hope that UE4 will always be C++ and no C# or Java (or other slow creature) will creep up and hit performance of it. I really hope so.

                                Comment

                                Working...
                                X