Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

    Originally posted by smallB View Post
    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.
    No one is arguing that the core UE4 Engine shouldn't be in C/C++, this is clearly the most sensible thing to do.

    What many people want is an easy way to program game/scripting logic in something besides C++(but that is an established programming language, and not visual like blueprints). As vince points out, the performance of most game logic is completely inconsequential, When somethings using less than 1% of the resources, does it really matter if it's 0.8 or 0.6? No, as programmers we have more expensive problems to tackle, so anything that makes our job faster saves time, and time is money.

    Comment


      C++ is as if you're hitting the lowest ground. It's like you got NDK in Android, it's like you got Objective-C with C++ in iOS, it's like you got asm.js for HTML5. In terms of me being a coder, this idealism of using one of the most powerful engine using C++ is one of the satisfying moment in my whole programming life. For me, even though C++ is fast whatsoever with disadvantages of high learning curve and/or harder code management, it is merely a fun language you will ever mess up with, but also crucial in commercial terms, so all the fun won't go to waste. Since Unreal has reached deep down here in indie community, as a hobbyist I find this very, very mutual and amusing at the same time, you know, touching those to the very bones of the engine. FOR $20 A MONTH. It's like I'm subscribing to a living museum and being able to touch them all.
      Last edited by 83551; 04-15-2014, 01:41 PM.

      Comment


        Originally posted by vincemektek View Post
        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#.
        This is very cool. But just to clarify the C# runtime is restricted to using existing blueprint callable functions. You aren't getting a UActor reference in C# with full access right? You are essentially able to script the connections between blueprint nodes? Do you have some example code that demonstrates it, for example setting the XYZ position of a UActor in C#?

        Comment


          Originally posted by DWORD View Post
          UnrealScript was the wrong choice indeed. It's slow (20x slower than C++) and C# is way more powerful. I wound't say that C# is the future of game programming, but its very good. I prefer C/C++ as a programming language, C# is the second best.

          The "easy" transition from UnrealScript to C++ is because they rely too much on their macros, which makes it very similar to UnrealScript.
          Comparing the "speed" of a scripting language versus a "real" language is a completely useless thing to do -- there's no good use comparing two completely different things.

          Adding a scripting language to even UE4 would not be a useless endeavour, simply because one has access to the source code. I seem to recall that there was at least one developer who had replaced UnrealScript with Python in UE3, and they obviously had source access, but felt it would be advantangeous to have a more accessible language to do some work in.

          Certainly, overall, C++ is probably "best" to work in, speedwise, considering that the engine is built in it, but I think that a lot of the supposed advantages/disadvantages to doing so are vastly overstated.

          Until I started working with Unreal professionally a bit over 4 years ago?, I was over 20 years rusty (probably closer to 25) on C++. C++ in Unreal is completely different from C++ in any other project that I've seen, they've pretty much built a complete language inside C++. I've been working with C++ in other projects ever since then ... and everyone else's C++ doesn't even resemble the language that I learned back in the late 80's/early 90's. Programming in Unreal doesn't even resemble any other modern C++ project that I've worked with since.

          Of course, one nice advantage, is that you can go off and write all your own things, in whatever the heck style you want, using or not using Unreal's macro language, and then glue it in with a few uses of that, and off you go.

          Frankly, I think it would be super awesome if someone could figure out a way to rapidly implement QML as a UI framework into Unreal, but unfortunately, I imagine that either decoupling QML from Qt, or integrating Unreal with Qt would be proposing a nightmare. :-)

          Comment


            Originally posted by smallB View Post
            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.
            I would totally dispute that -- You can write a **** in any language, and you can write something that is fast and performant in any language*

            I think my favorite example, is the Guitar Hero clone that was written (mostly) in Python. And I was running it at full speed on hardware that doesn't even compare to my lowest end tablet right now (4 year old tablet)

            * of course, there will be some things where your bar of performance may be vastly different, but for some tasks, C++ doesn't give acceptable performance, either.

            Comment


              Originally posted by smallB View Post
              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.
              No offence, but your comments are pretty common to the amateur mindset. The C++ == speed meme is something you really have to get over. A pragmatic ( read -- good ) programmer looks at all tools available to do the job and choose the right one for the situation. Even in games, and other realtime perfomant applications, C++ isn't always the right tool, although often it is. Dismissing other tools based mostly on reputation is silly at best.


              Would you hire a contractor that thought a hammer was the solution to every problem?
              Last edited by Serapth; 04-15-2014, 05:51 PM.

              Comment


                Originally posted by zoid
                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.
                Did you read the thread? There are quite a few garbage posts such as:
                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...
                The comment you were referring to was directed at posts such as these.

                Note that in my reply, I did state that native code is a very appropriate choice for many of the performance critical subsystems in the engine; but may be significantly less so for game logic, AI, networking code and so on (i.e. a majority of the game-specific logic you may wish to implement).

                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.
                Of course there are trade offs. My point was simply to state that if you cannot enumerate the exact reasons why writing code in a particular language, and using particular language features that aren't available in other languages, then you are not qualified to make the statement "X is faster than Y". That's because C++ being inherently faster than C# is a myth. Writing the same logic in either language will produce fairly similar results in regards to performance; unless you are specifically taking advantage of things that are impossible to replicate in C#.

                Generally speaking, across an application, C# is slower than C++, ranging from 2x to possibly many times slower...
                This is untrue. C# is compiled into IL, IL is compiled (at runtime) into machine code. There are certain things that the runtime does that makes it slightly slower (array references are bounds-checked for example - though scoff at this all you want, but this feature has removed a metric crapload more critical (and potentially security related) bugs than C#'s lack of constness has added). However, for the most part, the machine code produced by a .net assembly will be very similar to that produced by C++. The biggest performance hit is the time it takes to warm up - but this only affects startup times (and the first time a method is invoked) but can be completely eliminated by using a tool such as nGen.

                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.
                As I said before; C# is not a good choice for the core engine and certain sub-systems such as collision detection, physics simulation or rendering. That's because these are general systems (that don't require per-game modification) and that are maintained by a team of expert developers who have the time and energy to optimize them, all day, every day. Many other systems, the kinds that a gameplay programmer, tool developer, or AI developer would write are not performance critical. Giving them a leg up in productivity and correctness is worth a slight performance hit - hell, while this figure is absolutely incorrect, I'd even say a 2x performance hit is more than worth it. Remember: these systems do not need to be executed many times in a frame.

                And what if, one day, they do need to write something performance critical? They can still certainly jump into C++ and make their modifications that way.

                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.
                Safety Features:
                - Array bounds checking
                - Better type safety
                - An exception system that developers aren't embarrassed to use
                - No raw/dangling pointers
                - Requirement that variables be definitely assigned before access

                OO Features:
                - Interfaces
                - Better enums
                - Lack of multiple inheritance (I've yet to see a proper use-case of multiple inheritance in C++, except in the case where classes with only pure virtual methods are used to emulate interfaces). This especially holds true as the programming industry, at large, now discourages heavy use of inheritance in favor of composition-based OO strategies.
                - Arguably better generic type system. C++ templates are glorified macros, while generics in C# are baked straight into the runtime. 90% of cases where C# generics can't emulate something that you can do with C++ templates are unnecessary in C# - such as traits. Furthermore, generics in C# do not affect the size of the assembly, nor the time it takes to compile.

                Runtime Features:
                - Proper reflection - which includes instantiating generic types at runtime. Yes, reflection can be emulated in C++ though heavy use of templates, but this adversely affects compile times as well as runtime performance.
                - Type safe dynamic code generation via expression trees

                Other Features:
                - Unicode (UTF-16) is baked straight into the framework and requires no additional thought. The existence of a string primitive (and lack of support of C-style strings) removes complexity and increases compatibility with third party code.
                - The existence of a delegate type. This, yet again, can be emulated in C++ though clever use of templates and other features - yet, delegates are a first class citizen of the .net world.

                Productivity Features:
                - Much, much (much much much much) faster compile times
                - Visual Studio's C# support, combined with ReSharper, destroy any toolset of any language I have come into contact with. Ever.
                - The way in which the compiler handles errors (C++ errors, especially linker errors, can be quite cryptic)

                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#.
                C++ is hardly more "expressive" than C#. C++ is a hodgepodge of features that, with dedication and discipline, can be cobbled together into sensible code. Most of the time, however, these "expressive" features of C++ are simply used to emulate features that are inherently available in C# and other .net languages. Slate is some sort of odd subset of C++ that cleverly uses some of C++'s unique features (such as C++'s obscene list of overloadable operators) to create a programming experience that is some kind of imitation of a C# like language combined with a declarative DSL.

                Furthermore, it may have been advantageous for Epic to have created an actual, outside-of-C++, DSL for slate layout files. Creating DSLs is incredibly easy to do in C#, especially with tools such as Antlr - and if you combine them with the dynamic code generation features of C#, they can have the same performance characteristics of straight-up managed code.

                Also, what do you mean by:
                the ability to do full static analysis
                ?

                You can statically analyze C# pretty easily; and, in fact, it is much faster and less error prone to do so.

                Comment


                  I don't know why you guys still writing walls of text about something irrelevant. For now we got C++ because it easier to hook up right now, C++ always been in unreal, simply not accessible for mare mortals until now (it's something that i think most people still don't get it, C++ didn't replace anything, it's Blueprint that replace both UnrealScript and Kismet). But as there source code people can implement support for any language they wish for, there already people doing C# bindings even with editor integration, you can even recreate UnrealScript, i bet some crazy person will do that one day..... so everyone can be happy.... yes, right now

                  I really recommend to learn C++ thru, because without that knowledge you won't be able to go deep in to the engine and extend thru it's borders.... which was the same with UE3,2,1 for licenced users
                  =========
                  My Tutorials:
                  Basic knowledge about Classes and UObject environment and stuff like that

                  Comment


                    Originally posted by smallB View Post
                    Games to be specific,

                    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.
                    Wow you totally missed the point of me easing into that post didnt you, I knew someone would be offended. None of those will tell me about UE4 C++ in specific so I have to learn 2 fold, which Im not complaining about by the way! For Engines Im not going to argue but as a gameplay programmer I feel the language complexities and learning new languages is a huge barrier holding me back which is why Blueprint is great since it focuses on math and not syntax but ofcoarse as always thats glossed over and I get called a noob. For an industry where things change all the time we do tend to find ourselves locking things down, if it wernt for the great physicists challenging the status quo we wouldnt be where we are today, I'll leave you with that thought because you continue your religious mantra (Im used to dealing with zealots).

                    Basically I dont feel bound by an underlying language, engineers might need to do that but honestly thats why I use third party engines, because I want to make games not the technology and Im sure there are people wanting to make technology so more power to them. I just hope they dont get caught up in making technology to lose sight of what it was they wanting to do to begin with. I agree with eblade too, any language can be used poorly that even includes visual languages, my goal is to make people aware that game design actually goes outside the bounds of any programming language and runs much deeper in the fabric of the cosmos and that mathematical concepts transcend syntax.

                    Comment


                      Originally posted by Shadowriver View Post
                      I don't know why you guys still writing walls of text about something irrelevant. For now we got C++ because it easier to hook up right now, C++ always been in unreal, simply not accessible for mare mortals until now (it's something that i think most people still don't get it, C++ didn't replace anything, it's Blueprint that replace both UnrealScript and Kismet). But as there source code people can implement support for any language they wish for, there already people doing C# bindings even with editor integration, you can even recreate UnrealScript, i bet some crazy person will do that one day..... so everyone can be happy.... yes, right now

                      I really recommend to learn C++ thru, because without that knowledge you won't be able to go deep in to the engine and extend thru it's borders.... which was the same with UE3,2,1 for licenced users
                      I think we're mostly disputing the people who are saying C++ is the end-all be-all of everything. Personally, I don't know anything about C# (other than submitting some bug fixes in some tools, I've never had any reason to learn it), but I know a whole lot about Python, PHP, Unrealscript, Javascript, and a lot of other things that I've had reason to use. I use the tools that get the job done, but I'm rarely the guy deciding what those tools should be for a product. And I'm really certain that there are very good reasons why people don't just write everything in C++. :-)

                      Comment


                        Originally posted by eblade View Post
                        I think we're mostly disputing the people who are saying C++ is the end-all be-all of everything.
                        And other people disputing those who saying that C++ is terrible of a choose for game play use... which it isn't UE4 API in C++ are not much diffrent from UE3 UnrealScript, other the fact it is C++ it's feel the same and it's faster.
                        =========
                        My Tutorials:
                        Basic knowledge about Classes and UObject environment and stuff like that

                        Comment


                          Originally posted by MonsOlympus View Post
                          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.
                          Yeah, that archetype method is what we generally use in fortnite, but basically without the 4th step. We avoid having asset references from C++ to Asset, so that step #4 is usually "open a different asset in the editor and point it to the new blueprint".

                          Refactoring blueprint events and functions can be a bit complicated. Luckilly, there are some pretty handy redirectors built into the engine. Here's a few examples of how you do this kind of refactoring, from our defaultEngine.ini file.

                          Code:
                          +ActiveClassRedirects=(OldClassName="FortGameInfoBase",NewClassName="/Script/FortniteGame.FortGameModeBase")
                          +K2FieldRedirects=(OldFieldName="BuildingActor.ReceiveDestroyed",NewFieldName="BuildingActor.OnDeathServer")
                          +TaggedPropertyRedirects=(ClassName="FSM_AIProjectileThrow",OldPropertyName="InitialAccuracy",NewPropertyName="InitialAccuracyMax")
                          +K2ParamRedirects=(NodeName="/Script/BlueprintGraph.K2Node_CallFunction", OldParamName="FortMissionLibrary.SpawnMissionItemPickup.MissionItemData", NewParamName="MissionItemDefinition")
                          Using redirectors you can set up a situation where the old blueprints will fix themselves automatically on load, and then eventually you want to resave the blueprints to make the changes "stick". It's basically the same way that data redirectors work.

                          Comment


                            Originally posted by Shadowriver View Post
                            And other people disputing those who saying that C++ is terrible of a choose for game play use... which it isn't UE4 API in C++ are not much diffrent from UE3 UnrealScript, other the fact it is C++ it's feel the same and it's faster.
                            I must have missed those posts, Ive seen alot of highlighting of issues with C++ that people tend to overlook. The API still relys heavily on the base C++ syntax which is why Im saying that there are complexities that wernt there before and ofcoarse its faster in terms of computation, not production capacity which entirely depends on the programmers. I will always be of the opinion that just because a person knows C++ or an API for that matter doesnt make them a good game designer, thankfully we have blueprint otherwise we would be leaning heavily on a community that has a very ingrained ideology that anyone who doesnt know their language must obviously know less then they do, nothing against the guys at Epic and Im not going to single anyone out but even they do it (granted they might actually know more ).

                            The point is that C++ is just a tool, we use it, it doesnt elevate anyone to some higher level on its own, the concepts behind the language were around long before the actual syntax took shape and there are reasons why the syntax can seem obscure at times because things have been shoehorned in. Newer languages can see the mistakes that older languages have made and improve upon them, Im not going to say anyone is right or wrong but we need to compare them to know what works and what doesnt. Every single time I mention the innate complexities of C++ I get shrugged off, without fail, It would just be nice for people who like C++ to tell us about their issues with the language too from a more experienced perspective but as eblade said its rare to hear people who work with C++ criticize it and Im going to bet that it isnt because the language is perfect because I can say without a doubt it certainly is not.


                            Originally posted by Ben Zeigler View Post
                            Yeah, that archetype method is what we generally use in fortnite, but basically without the 4th step. We avoid having asset references from C++ to Asset, so that step #4 is usually "open a different asset in the editor and point it to the new blueprint".

                            Refactoring blueprint events and functions can be a bit complicated. Luckilly, there are some pretty handy redirectors built into the engine. Here's a few examples of how you do this kind of refactoring, from our defaultEngine.ini file.

                            Code:
                            +ActiveClassRedirects=(OldClassName="FortGameInfoBase",NewClassName="/Script/FortniteGame.FortGameModeBase")
                            +K2FieldRedirects=(OldFieldName="BuildingActor.ReceiveDestroyed",NewFieldName="BuildingActor.OnDeathServer")
                            +TaggedPropertyRedirects=(ClassName="FSM_AIProjectileThrow",OldPropertyName="InitialAccuracy",NewPropertyName="InitialAccuracyMax")
                            +K2ParamRedirects=(NodeName="/Script/BlueprintGraph.K2Node_CallFunction", OldParamName="FortMissionLibrary.SpawnMissionItemPickup.MissionItemData", NewParamName="MissionItemDefinition")
                            Using redirectors you can set up a situation where the old blueprints will fix themselves automatically on load, and then eventually you want to resave the blueprints to make the changes "stick". It's basically the same way that data redirectors work.
                            That is just amazing, I have been looking over the document you linked and the asyncronous stuff does seem promising, its certainly concepts I havent worked with before but Im hoping they dont turn out to add too much complexity. These redirectors sound like they could really help with the possible issues of linking C++ and Blueprints so I appreciate you taking the time to talk about these, I honestly had no idea these were even there so I'll pass this information on to the other programmers on the team also, they might be able to make more use of the C++ end of things than I can currently.

                            Im guessing by the removal of the 4th step we are talking as in the GameModes how we can link to classes within the editor from a blueprint but we can link to either C++ or Blueprint Classes for Pawn, Controller, etc.
                            Last edited by MonsOlympus; 04-15-2014, 09:56 PM.

                            Comment


                              Originally posted by Shadowriver View Post
                              I don't know why you guys still writing walls of text about something irrelevant. For now we got C++ because it easier to hook up right now, C++ always been in unreal, simply not accessible for mare mortals until now (it's something that i think most people still don't get it, C++ didn't replace anything, it's Blueprint that replace both UnrealScript and Kismet). But as there source code people can implement support for any language they wish for, there already people doing C# bindings even with editor integration, you can even recreate UnrealScript, i bet some crazy person will do that one day..... so everyone can be happy.... yes, right now

                              I really recommend to learn C++ thru, because without that knowledge you won't be able to go deep in to the engine and extend thru it's borders.... which was the same with UE3,2,1 for licenced users
                              Extending the borders of the engine? How many AAA multi-million dollar developers do we have on this forum? I doubt 99% of people could really make any use of the source code. I've been coding in C++ for 14 years and I've built game engines, there is nothing wrong with Java or C# in fact it's been great to prototype engines with LWJGL and I never came across a difference in performance when switching to C++. I do so because the amount of resources available is staggering compared to resources in C# and it would make life hell constantly trying to reinvent the wheel.

                              It doesn't matter about having knowledge of low-level interactions with hardware and memory management, we are in this to make games right? Not engines!..

                              Whatever get's the job done quickly the language is just a tool, if people are serious about making games. They'll leave their pride outside the room, an art pipeline alone for a AAA game is enough to make teams of 10 or 20 sweat horribly.
                              Last edited by ShadowKindGames; 04-15-2014, 08:49 PM.

                              Comment


                                Originally posted by ShadowKindGames View Post
                                Extending the borders of the engine? How many AAA multi-million dollar developers do we have on this forum? I doubt 99% of people could really make any use of the source code. I've been coding in C++ for 14 years and I've built game engines, there is nothing wrong with Java or C# in fact it's been great to prototype engines with LWJGL and I never came across a difference in performance when switching to C++. I do so because the amount of resources available is staggering compared to resources in C# and it would make life hell constantly trying to reinvent the wheel.

                                It doesn't matter about having knowledge of low-level interactions with hardware and memory management, we are in this to make games right? Not engines!..

                                Whatever get's the job done quickly the language is just a tool, if people are serious about making games. They'll leave their pride outside the room, an art pipeline alone for a AAA game is enough to make teams of 10 or 20 sweat horribly.
                                Did anyone saying here you need to rewrite UE4 or something? People acting here like C++ is something terrifyingly hard and time consuming, in reality engine APIs is no different from seem in other UEs, it feels like using UnrealScript just it's C++... and thanks to that you can do anything unlike it was in UnrealScript, which also required C++ to go beyond things. And it also got same object management and garbage collection. Blueprint missing something which is in APIs? just bind it with child class which you can use in blueprint and there you go.... you exteded borders of this engine already.... and it actually easier then making Kismet nodes in UnrealScript And not to mention all i did is recommand, not command people

                                But again there no point of argueing really, if people hate C++ so much that they even don't what to try it and want to use C# or anything else... no problem, there people already doing even C# editor integration for that and i bet they are not AAA studio (studio that have AAA reviews by definition? ), and there JUST one person who works on JavaScript support for everyone, over time i bet where will a hell lot of plugins for lot of stuff for others to use, extending borders of this engine
                                =========
                                My Tutorials:
                                Basic knowledge about Classes and UObject environment and stuff like that

                                Comment

                                Working...
                                X