Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

    It would probably help to specify what exaclty you mean when you say "games". Do you mean the engine code? Would certainly agree it needs to be C++ at this point in time. But gameplay code? Why do you think blueprints exist and are recommended to use by Epic even to programmers? According to your "perfection" assessment, blueprints aren't only mediocre, they are downright absymal.

    You're way too hung up on performance. Most modern games are GPU limited anyway. You can do stuff in blueprints and nobody will ever notice. Performance critical stuff you can do in C++ or port it to C++ later.

    I also never heard of a guy complaining when offered a Ferrari, at least not about how hard it may be to drive. About maintenance cost perhaps yeah, and rightfully so.

    Comment


      Originally posted by Veovis Muad'dib View Post
      What was the reason for keeping this cesspool of a thread open again?

      If you take the question at face value, it was answered on page one by Tim Sweeney, and I don't know of anyone more qualified to answer that specific question.

      If you take the question as "Why don't I have x or y language" then that has also been covered, there are Blueprints and a Lua plugin, others are working on everything from C# to proprietary languages to Javascript.
      Meh, to be perfectly honest I find it rather entertaining how every other week or so some new guy chips in here to tell us how things really are. I don't know why but I like these threads sometimes, they are a bit of a diversion and they also show, if nothing else, how many kinds of people and opinions there are. As long as everything is kept relatively civil, there's no need to close a thread.

      Comment


        I have never used C++ in my life, coming from UScript, using C++ in unreal is pretty straightforward and easy, I don't really care if someone else wants to use C# or something else. That's pretty much their prerogative.
        Bacon Man : An Adventure (UE4)

        Comment


          Originally posted by smallB View Post
          ^^^ Said Ford Fiesta driver...

          Yeah, right...
          I drive a Focus actually! :P (practical option)
          Give me a bike, skateboard or skates most days though. (preferrential option)
          I'd like a Ferrari, but only to throw it round a track if I was in the mood. (special cases)

          This thread is kind of dragging on.

          I love digging into the C++ source. It's helping to improve my programming.
          I find some things easier to express in code than in a visual graph.

          I have been implementing cool things without impediment, it has only required that I learn new concepts and develop my skills further.
          I would probably not be developing as much experience if I was still coding in C#.
          As such I think my time is best spent doing more of the same, rather than dwelling on the semantics of the engine architecture.

          Comment


            Originally posted by Triplelexx View Post
            I drive a Focus actually! :P (practical option)
            Give me a bike, skateboard or skates most days though. (preferrential option)
            I'd like a Ferrari, but only to throw it round a track if I was in the mood. (special cases)
            .
            Not if you required (expected) to cover daily long distances as fast as possible though Then the choice is clearer and clearer.

            You speak from the perspective of a (and please don't get me wrong, I'm not trying to insult neither you nor anybody else, I'm just playing along with the analogy) amateur driver. If you were a pro and required to try to beat times and cover long distances day in and day out your reasoning most likely be different. (I hope
            Last edited by smallB; 08-31-2014, 05:53 AM.

            Comment


              Originally posted by Gigantoad View Post
              I also never heard of a guy complaining when offered a Ferrari, at least not about how hard it may be to drive. About maintenance cost perhaps yeah, and rightfully so.
              There is no perfect analogy, nope there ain't any... But in this case the funny thing is that (in this analogy and in this particular example) maintenance costs are higher to keep Fiesta than Ferrari.
              Last edited by smallB; 08-31-2014, 05:54 AM.

              Comment


                Originally posted by smallB View Post
                There is no perfect analogy, nope there ain't any... But in this case the funny thing is that (in this analogy and in this particular example) maintenance costs are higher to keep Fiesta than Ferrari.
                Are you factoring in fuel and insurance? Cos you should.

                (In other news, never ever use a car analogy when talking about software. They always backfire.)

                Look, smallB, you may be god's own gift to programming. You may be able to code rings around Carmack, juggle the entirety of UE4 in your head at all times, and be able to write infinite loops that execute in under a second. But you may also just be someone with little experience and a lot of attitude, and to be frank? That's the impression I'm getting from you here.

                Programming languages are tools. Nothing more, nothing less. Some of them are more versatile than others, but claiming that any one of them is "the best" is just as misguided as claiming that since hammers are the best tools to drive nails into walls, noone would ever need or want a screwdriver. Yes, C and C++ are very performant. Yes, they're usually the best choice to implement a graphics or physics engine. But that doesn't mean they're equally good to use for other tasks in game development. A well written, performant scripting language that level designers and artists can use without shooting themselves in the foot is also important, and C++ completely fails at that task due to its complexity.

                Comment


                  Seems i missed something, what's problem? If you need some easy-upper-level coding - use blueprints, it's very powerful. If you need some low-level code - use c++, it's simple enough in ue4, at least you don't need to manage memory by itself. So blueprints slower but easier, c++ is fast but harder. C# and other vm-based languages can't provide such flexibility

                  Comment


                    To smallB:
                    I have recently watched many lectures about C++ from many sources - specifically, talks by a guy name Bjarne Stroustrup, which happened to invent C++...

                    Here is one of them


                    You know, it is interesting how little he shares with you in regards to idealizing C++. In fact, most of what he says is showing C++'s weaknesses and dangers.

                    Here are some examples:
                    Code:
                    A very simple example is 
                    
                            vector<vector<double>> v;
                    
                    In C++98, this is a syntax error because >> is a single lexical token, rather than two >s each closing a template argument list. A correct declaration of v would be:
                    
                            vector< vector<double> > v;
                    
                    I consider this an embarrassment. There are perfectly good reasons for the current rule and the evolution working group twice rejected my suggestions that this was a problem that was worth solving. However, those reasons are language technical and of no interest to novices (of all backgrounds – including experts in other languages). Not accepting the first (and most) obvious declaration of v wastes time for users and teachers.
                    Code:
                    The error messages that come from slight errors in the use of a template, such as a standard library algorithm, can be spectacularly long and unhelpful. The problem is that the template code’s expectations of its template arguments are implicit. Consider again find_if(): 
                    
                             template<class In, class Pred> 
                             In find_if(In first, In last, Pred pred) 
                            { 
                                 while (first!=last && !pred(*first)) ++first; 
                                 return first; 
                            }
                     
                    Here, we are making a lot of assumptions about the In and Predicate types. From the code, we can see that In must somehow support !=, *, and ++ with suitable semantics and that we must be able to copy In objects as arguments and return values. Similarly, we can see that we can call a Pred with and argument of whichever type * returns from an In and apply ! to the result to get something that can be treated as a Boolean. However, that’s all implicit in the code. The standard library carefully documents these requirements for forward iterators (our In) and predicates (our Pred), but compilers don’t read manuals.
                    Try this error and see what your compiler says: 
                    
                            find_if(1,5,3.14); // errors
                    Code:
                    Another “embarrassment” is that it is legal to copy an object of a class with a user-defined destructor using a default copy operation (constructor or assignment). Requiring user-defined copy operations in that case would eliminate a lot of nasty errors related to resource management. For example, consider an oversimplified sting class:
                    
                            class String { 
                            public: 
                                String(char* pp) :sz(strlen(pp)), p(new char[sz+1]) { strcpy(p,pp); } 
                                ~String() { delete[] p; }
                                char& operator[](int i) { return p[i]; } 
                            private: 
                                int sz; 
                                char* p; 
                            };
                    
                            void f(char* x) 
                            { 
                                 String s1(x);
                                 String s2 = s1; 
                             }
                    
                    After the construction of s2, s1.p and s2.p points to the same memory, this will be deleted twice, probably with disastrous results. This problem is obvious to the experienced C++ programmer, who will provide proper copy operations or prohibit copying. However, the problem can seriously baffle a novice and undermine trust in the language.

                    He is very much against your attitude of idealism, and is very vocal about this view of his. I am also reading one of his book these days, quite an old book, his favorite, you might like it, it's called: "The Design and Evolution of C++" (a.k.a: "D&E" for short).
                    Here are some quotes:
                    Programming Languages
                    Several reviewers asked me to compare C++ to other languages. This I have decided against doing. Thereby, I have reaffirmed a long-standing and strongly held view: Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness.
                    Many C++ design decisions have their roots in my dislike for forcing people to do things in some particular way. In history, some of the worst disasters have been caused by idealists trying to force people into' 'doing what is good for them." Such idealism not only leads to suffering among its innocent victims, but also to delusion and corruption of the idealists applying the force. I also find idealists prone to ignore experience and experiment that inconveniently clashes with dogma or theory.
                    In short, his attitude towards C++, is much more modest and pragmatic then the attitude you have demonstrated here.

                    As for the performance-argument, it is probably the most irrelevant in this context - Epic's personnel has repeatedly stated that Blueprints are around 10X slower then native-c++, and yet they still recommend them for most scripting tasks, as they were developed specifically for that (which was a very large and substantial investment on their part). So, Epic does not share your worries about performance. Nor does Unity-Technologies, CryTek, or any game-engine development company in the history of gaming. Virtually any AAA game that has been successful in the last decade, has had some sort of a scripting-environment embedded in it - whether it be proprietary or commercial, home-grown or open-standard, every game has it. Period. Including the most performance intensive ones. And there is reason for that - it has contributed to the game's success, in that it enabled quick-iterative workflows, which is the foundation for any successful creative-process. This rules-out C++ if only for compile-time reasons alone. Some companies went so far as to build their own integration to languages like "D" which have orders-of-magnitude faster compile-time, with negligible performance-costs (if at all), and endured the suffering of having to maintain that integration, only for the benefit of a fast iteration-time - it IS THAT important. The quality of a game is measure on many more axises than just raw-performance. Since it's a creative-collaborative-process, developers don't really know what works well until they try it out. It's more of a "discovery" process then an "engineering" one - and so, in that space "iteration-time" is KING. The more iterations a team may perform in the time they have before launch, the better the game will end-up being - it's that simple.

                    And as for your numbers about C++ vs C#, no one is countering that - it was measured, and is a fact.
                    The question is NOT:
                    "Is this true?"
                    The question is rather:
                    "Is this relevant?"

                    I'll give you a simple example that would demonstrate how in some cases performance is irrelevant:
                    Say you want to play Quake3 Arena. But not just play it by yourself - you want to arrange a tournament of a 100 people, and you are in charge of building the machines that would host the event. You are evaluating which graphics-card to buy for these machines.
                    You have 2 choices, and both cost exactly the same:
                    1. A card that takes 100W, and runs Quake3 at 300fps.
                    2. A card that takes 200W, and runs Quake3 at 600fps.

                    Which would you choose?

                    If going by raw-performance alone, the answer is obvious - you pick option 2.
                    But wait, is it even possible at all to see the differences between them?
                    Lets say that you have super-fast monitors that are connected to these machines - they have a 200hz refresh-rate.
                    Is that enough?
                    Well, even with option one, you are still not able to even see all the frames that are being cranked-up by that card...
                    What do you gain by buying option 2?
                    Absolutely nothing.
                    What do you gain by buying option 1?
                    A much lower electricity bill...

                    You could also take your cars example, just put it in this kind of location:
                    Click image for larger version

Name:	IndianTraffic.jpg
Views:	1
Size:	63.7 KB
ID:	1056160

                    You get the picture?

                    As for C# performance, for the case of unity, you should watch this lecture:

                    *** SPOILER: At minute 33 he shows "the numbers" - Native C++ scored 31, "Converted"-C# scored 33 (lower is better).
                    Here is a time-coded link to the benchmark-charts:
                    https://www.youtube.com/watch?v=Bfa9ILwlsFw#t=2005

                    And a note on that, the main reason they are doing this, is NOT performance, but portability and launch-time - similar reasons for why Microsoft is doing something similar with their ".Net Native" initiative.

                    For VegasRich:
                    I HATE macros. I can't even count the times that some jack *** used a macro and didn't add a brace, or some other little bull **** thing and it lead to hours of debugging hell.
                    I work in C#, C++, Lua, Java, or whatever gets the job done fastest. Any language is only as productive as the coder using it - if you're unproductive then you're unproductive. Understand: the problem is YOU.
                    Given that "debugging" is a major part of programmer-productivity, this makes your 2 arguments logically-inconsistent with each other... :P

                    Bottom-line, performance is NOT free - it has "costs".
                    In most cases, the costs are in increased complexity and reduced productivity.
                    There is no serious systems-engineer that would claim otherwise.

                    This is why you MUST weigh the costs against the benefits, to find out if it is justified.
                    In most cases it isn't.
                    That's why there is a famous phrase:
                    "Premature optimization is the root of all evil"
                    Look it up...
                    Last edited by EruArnold; 09-01-2014, 06:16 PM.

                    Comment


                      This thread still going? Just chill guys, everyone will have what they want.

                      Ultimate anwser to quastion: Unreal was written in C++ since it's creation and since then evolved, thats why it a lot more easier, cheaper and efficient to give access to extending the engine code (because thas what C++ coding is in UE4) which they already did in past with licensed developers, then playing around with another scripting system while having blueprints. Recently scripting plugin was made for easier binding, so community over time will implement and language they like, maybe even revive UnrealScript. So i don't see point of those wall text battles, if they don't appreciate C++, then whatever, leave them be.
                      =========
                      My Tutorials:
                      Basic knowledge about Classes and UObject environment and stuff like that

                      Comment


                        Originally posted by EruArnold View Post
                        You get the picture?

                        As for C# performance, for the case of unity, you should watch this lecture:
                        *** SPOILER: At minute 33 he shows "the numbers" - Native C++ scored 31, "Converted"-C# scored 33 (lower is better).
                        Here is a time-coded link to the benchmark-charts:
                        https://www.youtube.com/watch?v=Bfa9ILwlsFw#t=2005
                        I'm not following the discussion closely but this only shows that performance is critical. It matters to an extent that Unity is going out of their way to get C# converted to C++. IL2CPP is an excellent move. They'll gain speed and continue to lure and appease developers who prefer C#. No doubt, it'll be a huge boost to Unreal Engine if/when it's open to other languages like this (convert to C++).

                        Originally posted by EruArnold View Post
                        That's why there is a famous phrase:
                        "Premature optimization is the root of all evil"
                        Look it up...
                        I dislike that sentiment. It's too often out of context. It's usually rehashed by people: 1. who don't care enough about performance; 2. who are in an environment where they don't have to care; 3. who conflate [caring about optimizing, learning to optimize and profile] with the notion of ["premature" (needless) optimization]. It's only "premature" if it's having little or no bearing on actual performance.

                        Originally posted by EruArnold View Post
                        You have 2 choices, and both cost exactly the same:
                        1. A card that takes 100W, and runs Quake3 at 300fps.
                        2. A card that takes 200W, and runs Quake3 at 600fps.

                        Which would you choose?
                        We live in a world where people use different GPUs and CPUs. Only a 10% difference in frames can make the difference between enjoyable vs. unplayable. If a person has a very lightweight game or isn't concerned with millions of users on older devices, then, sure, it's less important.

                        Comment


                          Originally posted by EruArnold View Post
                          As for the performance-argument, it is probably the most irrelevant in this context - Epic's personnel has repeatedly stated that Blueprints are around 10X slower then native-c++, and yet they still recommend them for most scripting tasks, as they were developed specifically for that (which was a very large and substantial investment on their part).
                          You took it out of context. Blueprints are 10x times slower uder certain conditions. Like performing heavy math operations.
                          When what you blueprint does is only calling C++ functions (sic!), you only pay interop cost. Which is negligible.
                          https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                          Comment


                            To worm:
                            I'm not following the discussion closely but this only shows that performance is critical. It matters to an extent that Unity is going out of their way to get C# converted to C++.
                            Well, it's interesting, but the IL2CPP initiative actually started as a way to make a native/non-plugin port of the Unity Player for he web, using WebGL.
                            So, the main target here, as you can see, is actually Javascript engines - and that is all they are currently willing to confirm.
                            The performance-benchmark was really out of any context, and was of a disjointed implementation of the Mandelbrot-Set, so you can extrapolate anything practical out of that, except for theoretical-capability to convert C# code into C++ code, that in certain-situation would yield similar performance-characteristics.
                            They are a VERY LONG way from having a fully-stand-alone implementation of the grand-vision of being able to compile fully-working games in C++ for ANY platform.

                            Really, if you look-up what Microsoft is doing with ".Net Native", and especially WHY they are doing it, you would quickly discover that it has nothing to do with performance per-se. IF they get performance-increase, it's a nice side-effect, but it's not the main goal.

                            What IS the main goal?

                            Well, there are many, and it depends.

                            When it comes to Microsoft, their main worries is are:
                            1. Launch-time : Some of their Windows Phone apps, sometimes currently take "minutes" to load-up...
                            2. Portability : A lot of platforms don't have a .Net-Framework in them, and even those that do, have different combinations of versions of it, so they want to be able to package their apps with the relevant framework-code, in the relevant version, but ONLY that, so it wouldn't balloon in size.

                            When it comes to Unity, the main reasons are:
                            1. Upgrading .Net-Version support in a portable way : There is virtually infinite chatter around the Unity community about how out-dated the version of .Net that they support (I know it's actually Mono, I'm talking feature-set version). Basically, it's a "LEGAL" issue now... Mono used to be Open-Source, but now most of the development is done as a proprietary-solution by a company named Xamarin. They essentially "hijacked" this Open-Source project and "monopolized" it, by actually hiring all of it's main contributors to work on their flavor of it... So Unity-Technologies basically got royally-screwed... The version that UT forked all these years ago was under a different license, and they couldn't keep it up-to-date after a certain version of it when the licence-model changed - it's a very long and complex/messy story, so I'm paraphrasing here - the bottom-line is, the version of ,Net that they are using (again, in terms of feature-set), is roughly 8 years old now (It's mostly 2.0, with some specific 3.5 features like Generics), and their community is raging and roaring about that for a few years now...
                            So they need another route for cross-platform support going forward, that doesn't rely on the Mono project in it's current evolution-route...
                            THIS is the BIG ISSUE here - anybody claiming otherwise, has a lot to catch-up on...
                            2. Packaging : The main problem they currently have with that, is that they have to basically include all of their engine (and their Mono implementation with it), for every App that is built... What they hope to accomplish long-term, is the ability to "tree-shake"-away all of the code that is not being used, and this is something that most C++ compiles already do very well. So in converting the C# code into C++ in the build-process, they get to benefit from this ability, and shrink-down their build-artifacts dramatically - which is important for "mobile", but actually CRITICAL for "web"...

                            By braking the dependency of Editor-version of .Net and the target-platform's support, they get to finally upgrade their .Net-version supported-feature-set.
                            But as the dude said in the video, "...the .Net upgrade is contingent upon the success of IL2CPP for all supported platforms...".
                            Meaning, if the IL2CPP initiative doesn't pan-out, Unity users will not get their long-awaited upgrade...

                            Nowhere in this entire fiasco is "performance" ever mentioned as a major-factor...
                            So you can't claim that they currently have performance-issues with the current C# solution - that is said nowhere(!).
                            It is a side-effect and a "potential" benefit, for "some" cases, and that's how they are treating it - it's all they're willing to commit to, for now.


                            I dislike that sentiment. It's too often out of context.
                            It's usually rehashed by people:
                            1. who don't care enough about performance
                            2. who are in an environment where they don't have to care
                            3. who conflate [caring about optimizing, learning to optimize and profile] with the notion of ["premature" (needless) optimization]
                            I have seen many treatments on this phrase - yours is the first I encounter.
                            It is unanimously accepted and understood that there is a tendency for people to "intuit" about performance-factors in their code, "before" they test it, and it is also very well-known and acknowledged that MOST intuitions in this area are evidently-wrong, most of the times - and in either directions(!)
                            So, really, I have no idea where you're getting this notion from...
                            If someone uses this phrase to trick-himself into justifying being lazy about profiling/optimizing, then that someone completely missed the point of this phrase - and in any case probably has poor personal-integrity...
                            To take such an example and extrapolate from it, and generalize it to the point of diluting it's message entirely - I don't even know what to label such an attitude... Looks suspiciously reminiscent of somebody just wanting to argue for the sake of arguing...

                            We live in a world where people use different GPUs and CPUs. Only a 10% difference in frames can make the difference between enjoyable vs. unplayable.
                            Quite right - and 9 times out of 10 this 10% difference would come from non-game-logic areas...
                            So, you see... It's not about just "performance" in-the-abstract, it's about the question "where are most of the bottlenecks most of the times".
                            And when it relates to scripting, you would be very hard-pressed to demonstrate that "this is where most of the bottlenecks are most of the times"...
                            Which bring us back to the importance of profiling, and the dangers of premature-worries, that most of the times have everything to do with our poor intuitions, and nothing to do with reality.

                            Ultimately, it's all trade-off either way - the smart thing too do is make the best ones.
                            Most cases, you'd get much more game-improvements (and a better game by the end of the deadline), by being able to do make many more iterations for your ideas, and for most cases, the price you pay in run-time performance is negligible and completely justified - most run-time-costs would come from other areas most of the times - if you happen to be developing a game that is somehow outside of this curve, then you're out of luck - no rational game-engine-developer would optimize for your use-case - you're within what's-called "an outlier" in statistics, and you'll have to just live with that...

                            Comment


                              Originally posted by EruArnold View Post
                              ...IL2CPP...
                              Nowhere in this entire fiasco is "performance" ever mentioned as a major-factor...
                              So you can't claim that they currently have performance-issues with the current C# solution - that is said nowhere(!).
                              Performance is mentioned on Unity's site. It's also mentioned elsewhere on their site and forums. If I'm not mistaken, one of the Unite 2014 conference's keynote presentations also touted the performance benefits.

                              The benefits of IL2CPP, first item:
                              ---------------------------------------------
                              Performance

                              IL2CPP seeks to provide the ease of use and productivity of C# with the performance of C++.

                              It allows the current, productive scripting workflow to remain the same while giving an immediate performance boost. We’ve seen 2x-3x performance improvements in some of our script-heavy benchmarks. This performance boost is due to a few reasons.

                              C++ compilers and linkers provide a vast array of advanced optimisations previously unavailable.
                              Static analysis is performed on your code for optimisation of both size and speed.
                              Unity-focused optimisations to the scripting runtime.
                              While IL2CPP is definitely still a work in progress, these early performance gains are indicative of great things to come.
                              ---------------------------------------------


                              Originally posted by EruArnold View Post
                              I have seen many treatments on this phrase - yours is the first I encounter.
                              ...
                              I don't even know what to label such an attitude... Looks suspiciously reminiscent of somebody just wanting to argue for the sake of arguing...
                              Those are only my thoughts. They don't apply to everyone and shouldn't be construed as such. I don't post for the sake of arguing. It would verge on irony to suggest otherwise. "Premature" optimization isn't good. Indeed. My point is that I've noticed more people over the years invoking that statement incorrectly, as if to suggest that taking steps to improve speed should be relegated to an afterthought. Apologies for any misunderstanding if this doesn't apply to you. For me and many others, achieving high performance starts from very beginning considerations, choosing wisely, over a continual process. "Premature" is relative. We'll agree on that. One person's gain could be seen as worthless or "premature" to another person.

                              Originally posted by EruArnold View Post
                              Quite right - and 9 times out of 10 this 10% difference would come from non-game-logic areas...
                              So, you see... It's not about just "performance" in-the-abstract, it's about the question "where are most of the bottlenecks most of the times".
                              And when it relates to scripting, you would be very hard-pressed to demonstrate that "this is where most of the bottlenecks are most of the times"...
                              Thank you for your thoughts. However, I'm fairly sure no one's claiming that [most bottlenecks are related to language itself]. The language/platform is a major factor nevertheless. Everything is potentially a bottleneck to older devices. Portability is very important too. I agree. Naturally, any language can potentially be as fast as C++. As far as .NET Native is concerned, it's a wonder (no, not really) why Microsoft didn't strive for that 7+ years ago. It's better late than never for them.

                              Comment


                                Originally posted by newbprofi
                                C# is dead language
                                http://jobsearch.monster.com/search/c__23_5?
                                http://jobsearch.monster.com/search/c__2B__2B_5?

                                For being dead, it is doing pretty well. Better than c++ anyway.

                                Anyone making statements as rash as this has little understanding of programming and/or how it's applied in the real world.

                                Comment

                                Working...
                                X