Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

    #46
    Originally posted by MinionPhil View Post
    .Net is way to reversible.
    This is very true, managed code languages are ridiculously easy to decompile compared to native binaries.

    .Net is slower
    This however is not. In-fact, Java and C# is often as fast as, or faster in real-world applications. jvm/clr's self-optimizers are amazing, you rarely see C/C++ in web services for this reason, once the self-optimization reaches its peak, jvm/clr starts beating C by a pretty wide margin. C's strength for an engine isn't necessarily its speed, it's its consistency. Managed code platforms trade consistency for raw speed(functions get faster the more often they're called, but the first time and the first few thousand times they're significantly slower). So for a game engine they're a poor choice for the rendering pipeline, but a valid choice for game logic.

    .Net is not multi-platform friendly
    True to an extent, Mono alleviates some of this, but Mono has its own licensing issues, until there's a truly free and open source equivalent of .net I wouldn't use it personally.

    Ultimately I support as many language choices for UE4 as the community wants to support, I'd rather program game logic in LISP or Clojure personally, and I like that I have the freedom to write plugins to do so.

    Comment


      #47
      Yeah on this one title I shipped we were using an in-house scripting language that compiled down to byte code. It was pretty bad. Our designers couldn't debug and it was kind of unfinished, since no one wanted to spend time making it 'pro'.

      To get to the point, being the C# lover I am, I suggested replacing that monster with C#. At least then our technical designers could debug. But no one wanted to bother with looking into Mono licensing for PS3/Xbox360 platforms. Plus we knew our boss wouldn't go for it anyways, since he was the one that wrote the scripting language anyways

      Eventually, we started looking into the WiiU and noticed our scripts were too slow. Not sure how detailed I can describe this on a public forum but surely everyone knows the specs for it these days? Anyways, it was looking like we were going to have to toss our designers at C++. A few of them had programming degrees. They've just never used them

      I ended up leaving that studio for another opportunity but since then they've ripped out the scripts due to switching engines and the Designers are programming in C++.

      So if these guys can do it I know you guys can!
      Godz for UT '99 / UT 2003

      Comment


        #48
        Originally posted by Tim Sweeney View Post
        This isn't to say that C++ is the ideal language for simple gameplay code. It is more complex and more dangerous than UnrealScript, C#, and JavaScript. But that is another way of saying that it's more powerful.

        By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish, whether it involves debugging your entire codebase in-context, interfacing to low-level engine systems, modifying them, or talking to the operating system or advanced third-party libraries.
        Dear Tim Sweeney & any Epic Devs reading this thread,

        I have created a thread thanking you for the awesomeness that is UE4 C++!


        Thank you for sharing your Heart with the World!


        I hope you know how many of us are ever so grateful to you for giving us this opportunity!


        https://forums.unrealengine.com/show...nots-(for-fun)



        Rama

        PS: There is an easy resolution to this thread

        Infinite Power = C++

        Consider being grateful that you are being offered such power for such a small fee, with such an incredible code base to work with!

        I am excited that there are some community projects to introduce support for other langauges, but I really think Epic deserves more thanks and appreciation for what they have offered all of us.
        Last edited by Rama; 04-12-2014, 04:29 PM.
        100+ UE4 C++ Tutorials on the UE4 Code Wiki, including UE4 Multi-Threading!

        UE4 Marketplace: Melee Weapon Plugin & Compressed Binary Save System Plugin | Rama's C++ AI Jumping Videos | Vertex Snap Editor Plugin

        Visit www.ue4code.com to see lots of videos about my C++ Creations! ♥ Rama

        Comment


          #49
          Personally, I find C++ to be very... likeable. It's fast, it's powerful, and it makes life miserable for people who just don't know how to code, which can really help lower the number of crappy games we see on the market these days, or at least keep them from having a "Powered by Unreal" logo attached, which would just be awful.

          However, there are a few downsides as well. One is the super-slow performance of Intellisense. It struggles and almost always fails to keep up with me when I code. Second is the fact that with C++, an error means instant termination of the entire engine. I was kinda getting used to the error logs in UDK and Unity, and it just hurts to see the entire editor crash because of as simple a bug as a null pointer being dereferenced. There is also the fact that, at least on windows and with MS's implementation, C# tends to do a well enough job of keeping up with the speed of 'native' programs using JIT compiling, so it can be fast enough for games, but never safe enough.

          All in all, for all the various reasons mentioned by others, the decision to move to C++ is definitely a good decision in my eyes. After all, C++ is the language upon which almost everything is built.

          Comment


            #50
            Why are so many ppl hating on c++? When you have an existing library like UE4 to work with c++ is as easy as c#, its not like you are going to be needing the complex c++ features to build from scratch anyway.

            Comment


              #51
              Originally posted by Arshia001 View Post
              However, there are a few downsides as well. One is the super-slow performance of Intellisense.
              This is Visual's Studio problem not C++. Visual Studio is written in C# and C# cannot cope. Intellisense lag in Visual Studio 2010 and onward has nothing to do with C++. Try Visual Studio 2008 which is written in C++ and you'll see no intellisense lag at all.

              Comment


                #52
                Originally posted by VFe View Post
                This is very true, managed code languages are ridiculously easy to decompile compared to native binaries.
                In-fact, Java and C# is often as fast as, or faster in real-world applications. jvm/clr's self-optimizers are amazing, you rarely see C/C++ in web services for this reason, once the self-optimization reaches its peak, jvm/clr starts beating C by a pretty wide margin.
                This is not a fact. This is fairy tale and you should really get your facts straight.
                Best way is to provide some evidence to what you're saying.

                Comment


                  #53
                  Originally posted by cman View Post
                  Why are so many ppl hating on c++? When you have an existing library like UE4 to work with c++ is as easy as c#, its not like you are going to be needing the complex c++ features to build from scratch anyway.
                  You are absolutely right.

                  Comment


                    #54
                    Originally posted by Rama View Post


                    Infinite Power = C++
                    I'm not sure if that's your intention, are you sure you didn't mean

                    Infinite Power == C++

                    Just trying to be lighthearted so please don't shoot me

                    Comment


                      #55
                      Tim,
                      thanks for explaining. But let me tell what I'm thinking about it.
                      With the recent price change for UE4 it's clear that Epic is now aiming @ indies and not at AAAs only. Those small devs (it's me, ha!) are very used to the simplicity of Unity and easy [scripting] languages. So, it's great that UE4 enables us to do everything with the power of C++. BUT.. For the new devs, it's simply too much. On the other side, blueprints are cool, but not as power enough to create an entire game.
                      My proposal: please provide a lot more tutorials and documentation. Especially for "switchers". There's still a very steep learning curve ahead.
                      Thanks!

                      Comment


                        #56
                        These debates are bound to happen and they get emotional because the choice of language is often based on "what you are comfortable with". I can tell a lot of people here are coming from a Unity background and appreciate its accessibility from C# through the documentation etc. My background: 15 years in professional game development as an engine programmer, I've used C++, C#, Java, extensively.

                        First off all, I think there is a misconception and people are latching too much onto C++. Epic has a far more elegant solution to scripting: Blueprints. Anyone who is comparing Unity C# to UE4's C++ has missed the entire boat. Unity is also written in C++, they just don't give you the source code. Any criticism leveled at UE4 because of C++ is equally applicable to Unity.

                        Secondly, everyone who is coming from Unity and is used to C# should be looking at Blueprints not at the C++ engine source. UE4's C++ source code is not for people who are used to scripting GameObjects and MonoBehaviours in C# in Unity.

                        And the final much more heated debate are the merits of C# vs C++.

                        Let's start with the "language" part of C# vs C++ and ignore the performance aspects of the situation first:

                        As a language, C# and all languages built around the IL specifications are inferior to C++ because they lack several major features: compile time const-ness, a true Turing complete template meta programming solution, pre-processor macros that support substitution and reduction, the ability to do full static analysis, and multiple inheritance.

                        For the beginning programmer what does this all really mean? Let's take a good example with const: multi-threading. In C++, because of const, it is much easier for me to produce a set of classes or an API that effectively communicates threading semantics between two classes that is enforced at compile time. If I have two systems A and B and they need to share an object, (where A can modify and B should only read) then it can simply be done by passing a "const" (cannot modify) version of that object to B. B can no longer ever call a method on the object that will modify its contents. This is enforced at compile time: if you tried to modify it it would fail with an error when compiling. That alone eliminates an entire class of thread synchronization bugs.

                        There are equally powerful cases for all of the other C++ language features. They range from convenience, to extraordinarily important if you want to be able to do something truly the right way.

                        C# has some superior language features as well but they don't tip the scale in its favor:

                        C# has anonymous functions and closures: This is incredibly powerful. C++ added this in C++ 11 and it is arguable more powerful there but there is an elegance that C# has because it is GC'ed that C++ does not. If I truly had a wish though C# would have first class methods like Lua.

                        C# has (at least on windows) has windows forms. Not a language feature but it's nice for tools.

                        C# has reflection, which is awesome. UE4 also has a reflection system as well, but it's not a language feature of C++.

                        Now let's discuss performance in C++ vs C#. This is arguable more important than the language features (at least from some perspectives).

                        I will begin with some follow up information if anyone really wants to get into this: http://www.codeproject.com/Articles/...-Csharp-vs-NET

                        The bottom line on this point is that C# is slower than C++. And if you use mono to compile your C# (like Unity does) then it is significantly slower. Using the microsoft class of IL compilers C# at its peak can almost match the speed of C++, but those are during its best cases. Generally C++ outperforms C# by a significant margin.

                        The types of optimizations that C++ goes through are more advanced and more significant than what are possible with C#. For example, did you guys know that every time you index an array in C# there is a bounds check in the array? Also C# has its own set of issues and concerns, specifically with mono: Almost all Generic.Collection<> classes in the C# runtime return structs from their IEnumerator interface (as they should). However, mono does not compile this correctly: and it converts structs to object types on the heap causing boxing/unboxing overhead on each iteration. Bottom line: foreach() is slow in Unity so it can't be used as efficient alternative to avoiding the overhead of indexing in C#.

                        C# also makes it impossible to modify a value type without indexing because it lacks reference-to-value-types. Example:

                        void DoSomethingWithArray(MyStruct[] arrayofvalues)
                        for (int i = 0; i < arrayofvalues.Count; ++i) {
                        if (arrayofvalues[i].shouldBeModified) {
                        arrayofvalues[i].modifyValue = calculateNewValue();
                        }
                        }

                        The above requires two indexes into arrayofvalues, requires two out of bounds checks. Can this be optimized out? No it can't, the compiler has no guarantee that arrrayofvalues won't be modified on another thread during the if() and the assignment inside the if.

                        People say C# bad because it is garbage collected, but isn't UE4 also garbage collected?

                        This is a blessing and curse for C# and all GCed languages. Generally speaking GC (managed languages) are a net positive for the programmer.

                        The reasons aren't always really what people think: yes in C# you don't have to explicitly free memory, but that not the biggest win. The big win is that when I'm writting 50,000 lines of C# I don't have to arbitrate what system is responsible for any given allocation. Because I don't have to do that for literally thousands of places where an allocation occurs you eliminate a massiave swath of common mistakes: freeing a memory multiple times, overwritting free'd memory, overwritten memory you thought was yours but was free'd and then reallocated and given out to someone else. There are lots of expressions of these types of errors that can happen in a large project. They all lead to terrible issues: one of your objects gets overwritten by random garbage, you get a crash when you try to allocate or free memory because someone overwrote memory and stomped on the internal C++ heap house keeping structures. All kinds of nastiness.

                        GC is probably the best thing C# really has going for it. BUT it's not all roses either: let's not gloss over some realities that all managed (Unity) programmers have dealt with as well: Memory leaks. In C# you either get nullrefexceptions or you leak memory. Because its a managed language, a programming mistake can often lead to leaks instead of crashing. Both behaviors are arguably wrong. And C++ doesn't really have clear win.

                        However, if you make a mistake the behavior in both cases (managed/unmanaged) it is still incorrect, just differently bad.

                        Why C#'s garbage collection is bad, and why UE4's GC is better.

                        Both C# and UE4's UObject and blueprints and gamecode generally are all GC'ed as well. So why did Epic do this? Because there is one major pitfall with C#'s GC: performance and predictability. Anyone who has done anything of complexity in Unity knows the bane of the GC hitches. You're crusing along just fine and then BAM, a 500 ms pause hits you. Or the lovely continous stutter step every 2-3 seconds.

                        These are garbage collection spikes and there is no way to control when they happen or for how often, in other words there is no predictability.

                        UE4 is garbage collected but the way their object system is reclaimed and disposed is designed to be predictable and have a flat performance profile. C#'s GC is designed to work for spreadsheet applications and database front ends. It's a general purpose GC. It's not designed from the ground up to be a GC for a real-time application where a flat performance profile is the most important requirement.

                        Adding C# to UE4 is redundant and not a good idea

                        So for the above reasons C# is not a wise addition to UE4, UE4 already has a scripting system: Blueprints. Use blueprints for everything you want to do with C#. Use C++ to extend and modify UE4 in any way you want to. You can't extend or modify Unity at all, unless you want to fork over the cost of a source license. And Epic has made it clear from their Twitch broadcasts that they are working towards an integrated system with github to provide instant access to checkins on the main source branch as they happen.

                        Epic actively wants the community to dig into the engine and extend and improve it. That's why they've given us the C++ source code.

                        Aside from Blueprints, GC, and C++ UE4 is superior to Unity in every other way

                        Point for point, system by system, Unity is not competitive with UE4 (except it exceeds in documentation). Not even the slated features of Unity 5 matches UE4, it only narrows the gap a little bit.

                        There are major systems in UE4 that Unity totally lacks, and they are not trivial things, they are systems that it takes expertise in to replicate. They could be done in Unity of course, and the Unity community has provided addons to fill in some of the short comings, but they aren't done in an integrated system like in UE4. Here's some of those missing things that UE4 has but are lacking an integrated solution in Unity:

                        * A real networking solution with client side prediction and authoritative network architecture.
                        * Built in platform agnostic online subsystems and match making with support for Steam, Game Center etc.
                        * Behavioral trees and AI systems: Unity has no system for you to create and produce AI or NPC login. You have to start at the lowest level and write your own code to move objects around. Then pathfinding etc.
                        * Unity's mechanim system is not as robust or sophisticated as UE4's.
                        * Unity has no material node graph. Unity's renderer (even Unity 5's) is inferior.
                        * Unity's built in GUI is terrible, but there are replacements like NGUI and Diakon Forge. UE4 is about to get Coherent UI and I'm sure the community will fill this void unless Epic gets to it first.

                        There's more than this but it's just an example of the really hard stuff you still have to implement yourself in Unity or buy piecemeal solutions for on the Asset store. And the asset store solutions aren't always the quality needed to actually ship something.

                        TL;DR

                        * If you are upset that UE4 uses C++ you are missing the bigger picture: UE4's Blueprints are the equivalent to Unity's C#, but blueprints are superior.
                        * C# is slower than C++ in almost all cases, and much slower when compiled with mono which Unity uses.
                        * UE4's method of garbage collection is better than C#'s generic GC.
                        * UE4 is superior to Unity. It's not merely an equal or an alternative.

                        Comment


                          #57
                          Originally posted by cocoapriest View Post
                          Tim,
                          On the other side, blueprints are cool, but not as power enough to create an entire game.
                          Thanks!
                          That is patently false. Blueprints are capable of doing a complete game, you just need to learn more about them. Watch this video, it's a full hour of someone explaining their entire game is done in blueprints:

                          Comment


                            #58
                            Originally posted by zoid View Post
                            Blueprints are capable of doing a complete game, you just need to learn more about them.
                            I agree with Zoid!

                            Having played with both BP and C++ quite extensively,

                            I am actually quite sure that the limits of BP are currently unknown, and they are an amazingly powerful tool you should dive deeply into and see how powerful they are!


                            Originally posted by smallB View Post
                            I'm not sure if that's your intention, are you sure you didn't mean

                            Infinite Power == C++

                            Just trying to be lighthearted
                            Hee hee!!!

                            Great to hear from you SmallB!

                            ~~~

                            UE4 C++ Update

                            Thanks to UE4 C++ I can now generate complex shapes at runtime, UV map them, and then give them collision!

                            Check out one of my player characters standing inside a complex uv-mapped shape!

                            I just now generated this shape and took the picture, in-game the whole time, editor was never opened!





                            Rama
                            Last edited by Rama; 04-13-2014, 02:25 PM.
                            100+ UE4 C++ Tutorials on the UE4 Code Wiki, including UE4 Multi-Threading!

                            UE4 Marketplace: Melee Weapon Plugin & Compressed Binary Save System Plugin | Rama's C++ AI Jumping Videos | Vertex Snap Editor Plugin

                            Visit www.ue4code.com to see lots of videos about my C++ Creations! ♥ Rama

                            Comment


                              #59
                              Originally posted by zoid View Post
                              ...
                              Secondly, everyone who is coming from Unity and is used to C# should be looking at Blueprints not at the C++ engine source. UE4's C++ source code is not for people who are used to scripting GameObjects and MonoBehaviours in C# in Unity.
                              ...
                              This is where you missed the mark. C# programmers should not be looking for blueprint nor the source code (provided through github). The Equivalent of Unity's C# in this case is the C++ API provided with the engine (not talking about performance or anything like that here). The amount of features that both engines provide are huge, Unity is more straight forward (simple) and Unreal Engine 4 is a little weird a first but has insane amount of out of the box features. Like some said, the amount of stuff in UE4 library makes this as easy as C#. Makes absolutely no sense to compare a high-level and powerful language like C# (and C++) with blueprints.

                              Personally I prefer C++, but I'm still learning UE4 since it's a little different from what I've done and used in the past (there's no way that I will port from Unity to Unreal without knowing it first). People that created a engine before (from scratch) probably created something that looks similar to Unity (entities, game objects, raycast, ...), that's why UE4 looks very alien to some (pawns, traces, overall syntax, ...).
                              Dumont Studios - www.dumontstudios.com

                              Comment


                                #60
                                Originally posted by Rama View Post
                                Thanks to UE4 C++ I can now generate complex shapes at runtime, UV map them, and then give them collision!
                                And it's so promising! For example, now we can implement dynamic slicing as it was done in Metal Gear Solid. Or ingame terramorphing.. so many opportunities!
                                Developer. Bass player. Cats owner. Unreal Engine addicted. Check my.alyamkin.com
                                [Plugin] VaRest - REST API with blueprintable JSON plugin
                                [Plugin] VaTexAltas - simple way to use texture atlases for UMG

                                Comment

                                Working...
                                X