Announcement

Collapse
No announcement yet.

Is C++ in UE4 no longer worth learning?

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

  • #16
    Sorry, but i have to comment a few things just for fun

    Originally posted by Jamendxman3 View Post
    You can already generate C++ code from blueprints, and it produces terrible-to-read code. Your logic is a bit flawed, as we can't just automatically convert everything to C++ and continue on with perfect performance, as that's not quite how it works, or at least in my opinion.
    We can already generate C++ from Blueprints? How that, did i miss some experimental feature?

    And, generally speaking, i am always having fun when people are saying that you have far better performance with C++. This is true in an ideal world where you write perfect C++ code, but in the end it always depends on the person between keyboard and chair. I've already seen code that performs horribly simply because of some, lets call it "misunderstandings" on how to code correctly.
    And in fact, when you dont do dumb things like having masses of logic in actor-ticks, you will hardly notice performance drops with blueprints; If these people would do their stuff in C++, the performance would possibly be a bit better, but the concept of packing everything inside a tick is still ****.

    Originally posted by NegInfinity
    Said converter will be producing sub-par code. That code will work like blueprints, but I think readability will be bad compared to human-made program.
    I have seen code in my job that was handwritten and made me cry. But generally speaking i think you are right
    Usually i see it like this: Click image for larger version

Name:	wtf.png
Views:	1
Size:	38.2 KB
ID:	1093146

    Originally posted by HateDread
    you can rely on C++ being C++ because it's not a custom file format being parsed inside of an application that could crash out or corrupt your work at any point. UE4 can't corrupt your C++ files, but it can totally break your blueprints. C++ is a rock, a foundation
    With the number of Macros used in UE4-C++ and its memory management/gc its already like its own language (or, custom file format). And while it wont corrupt your C++ files, you will have a similar amount of fun in C++ and Blueprints when upgrading to newer releases of UE4 (sometimes)

    Cheers,
    Indy
    FinalCamera on Marketplace / Web Demo
    TopDown Toolkit on Marketplace / Web Demo

    Comment


    • #17
      These instructions are similar to what a staff member posted a while back:

      Originally posted by MattW View Post
      I'm not sure if you mean convert a blueprint to c++, or just to be able to select a blueprint as a base class.

      I think you just want to be able to select a base class, however if you mean convert a actual blueprint to c++, then in 4.6 if you change your engine.ini file so that it has "bNativeCodeGenerationTool=true" under the "[kismet]" section (by default bNativeCodeGenerationToo is set to false), then when you open a blueprint in the editor, at the bottom of the file menu will be a "Developer" option, click that and a side menu opens, and at the bottom of that is "Generate Native code" , click that and you get a window where you set where the c++ files will be saved to.

      Now currently not everything is converted properly and some of the blueprint function seem to be setup so that can't be called from external modules, so I am getting linking problems. However the classes can still be a good starting point if you want to convert a blueprint you have created into c++.
      Marketplace Assets

      Advanced Mobile Input: Marketplace Page | Support Thread ――― Easy Input Remapping: Marketplace Page | Support Thread
      Multiplayer Blueprint Chat System: Marketplace Page | Support Thread ――― Closing Credits System: Marketplace Page | Support Thread
      Minesweeper Template: Marketplace Page | Support Thread ――― Maze Creator: Marketplace Page | Support Thread

      Comment


      • #18
        Short answer, no, but it really depends what you're writing.

        I would say that if you're just write "C++ scripts" then there is absolutely very little reason to hand-write it in C++, converting from Blueprint will get you C++ code that's going to be 99% just as good. But here's the thing, if you want to control execution down to the register level, say you're optimizing an algorithm to use AVX or SSE, or AMP or OpenCL, or OpenMP, or you want to link code that hasn't been interfaced to Blueprint, you're going to need to hand-write it.

        Comment


        • #19
          As a general rule, algorithm development should be done in C++ and not the scripting language on top of it, or at least end up there, for "glue code" and such Blueprint is fine, simply because 10x "slower" doesn't matter if the time involved is insignificant. The difference between simple "code" an an algorithm is really just a matter of perception, a formality. One trick to identifying where the "algorithm's" are (it's not always clear-cut), if you're relying on nested or complicated loops in Blueprint you should think about formalizing them and porting them to C++. You formalize the algorithm simply by thinking of and/or commenting the code as an algorithm (and not simply "code"), after thinking about the problem you can optimize. However if you're not doing much but moving the execution pointer down to the next iteration or algorithm then blueprint is fine, especially if converted to C++ and compiled to native binary.

          That said Blueprint really does push the barrier. With the generic Async and Task Graph libraries, Futures, and a mind to factor your code properly into those paradigms you can get some really efficient Blueprints, especially if you convert them to C++. There is little to no penalty for calling your algorithms from Blueprint either, once the algorithm is called it is executed as C++ not a Blueprint, you just don't want it itself defined as one.

          Keep in mind, there is nothing preventing you from moving pieces of your Blueprint into C++ bit by bit. Say you have a Character Blueprint. You could later subclass the Character class, then change your Character Blueprint's base class to your C++ Character class, then just port the code over from Blueprint to it's new base (the C++ class you derived from Character), add the appropriate reflection markup to expose it to Blueprint, and as long as you kept the function's interface and behavior the same the rest of your Blueprint should work just as it did before. Very useful technique for moving a working Blueprint to C++, because you can do it piece by piece and debug just as granularly.
          Last edited by User-658380556; 11-12-2015, 02:08 PM.

          Comment


          • #20
            As far as the converter goes, you guys need to understand one thing about it. It literally copy-pastes the functions from the engine C++ into your own projects - there is no conversion or optimization, it's pure copy-paste.

            There will likely be at least one or two cases per FUNCTION where you don't need to do a certain something, or some variable can be const and isn't - or even where things can be passed by reference or cached and they aren't. It's not just going to produce 'bad' code, it will also be borderline unreadable and incredibly over complicated. Don't for one second think that you can rely on it in a real production pipeline. Like srsly please forget about it lol.

            The thing to understand about C++ being faster is that the optimization isn't just the fact that it's written in C++, but it's also the extra things you can actually DO in C++ that make it faster - but to take advantage of those things you have to be a competent programmer. Things like bitpacking and passing pointers by const reference etc, or using TMap's instead of TArrays, the list is practically endless. But the point is, just writing the same code you did in blueprint in C++ isn't the full way to take advantage of using C++ in the first place.

            In terms of algorithm development, unless you're computing the cure to cancer or the physical properties of dark matter, I seriously doubt anybody can write in Assembly better than the compiler can. For 99.999% of all games produced today, the need to write anything in Assembly by hand is practically null and void - UNLESS you're a graphics programmer, in which case those things do start to matter. Even then though, these modern compilers really know their stuff..
            Last edited by TheJamsh; 11-12-2015, 03:35 PM.

            Comment


            • #21
              According to Nick Whiting, the main thing that's slow about blueprints is the up and down in and out of the VM that happens with each node. So the more nodes you have, and obviously the more often these nodes are being hit, say on tick especially, or 1000 instances of the blueprint running simultaneously, the slower it will get. If you replace these nodes with even with sub par C++ code, no VM is involved anymore and chances are that any performance issues would be negligible in most circumstances. Of course there will always be cases where something is so performance intensive that only the absolute best C++ code could handle it, but then I'd wager that blueprints weren't an option to begin with.

              Comment


              • #22
                Haven't read all the posts, but as a moderater, who sees tons of posts in the Blueprint Section each day, i need to say the following:

                EVEN if you don't want to learn C++, because you think Blueprints are enough for your Game (It is possible to create certain Games without C++), you NEED to learn about Objective Orientated Programming!

                There are so many people that have no idea about Parent, Child, Casting, Pointers etc, that i really need to post this here.

                DO NOT think you can get around learning the logic behind C++ only because Blueprints aren't written Code! If you don't know how to use the standards of OOP, you will find yourself in a really bad position when
                facing BPs, because even in their Visual Form, they are C++! Way too many beginners ask for help, because they don't know why they're getting Accessed None errors or they don't understand what Casting is.

                Do yourself the favor and learn it. You don't need to be able to write C++ code. But learn about how inheritance etc works! It will speed up your BP learning a lot and
                you won't have so many depressing moments where you don't know how to create the things you have in mind with BPs.

                (All "You"'s above refer to everyone reading this, not willing to learn C++ at all!)
                Open for contracted work | Blueprints | UE4++/C++ | Training | VR | My Website

                My UE4 Blog/Page with Free Learning Projects and more: Hit me for ALL the things!

                BP Multiplayer Lobby System: [Released] Support Thread! | BP Multiplayer Crafting System: [Released] Support Thread!

                Comment


                • #23
                  Originally posted by eXi View Post
                  Haven't read all the posts, but as a moderater, who sees tons of posts in the Blueprint Section each day, i need to say the following:

                  EVEN if you don't want to learn C++, because you think Blueprints are enough for your Game (It is possible to create certain Games without C++), you NEED to learn about Objective Orientated Programming!

                  There are so many people that have no idea about Parent, Child, Casting, Pointers etc, that i really need to post this here.

                  DO NOT think you can get around learning the logic behind C++ only because Blueprints aren't written Code! If you don't know how to use the standards of OOP, you will find yourself in a really bad position when
                  facing BPs, because even in their Visual Form, they are C++! Way too many beginners ask for help, because they don't know why they're getting Accessed None errors or they don't understand what Casting is.

                  Do yourself the favor and learn it. You don't need to be able to write C++ code. But learn about how inheritance etc works! It will speed up your BP learning a lot and
                  you won't have so many depressing moments where you don't know how to create the things you have in mind with BPs.

                  (All "You"'s above refer to everyone reading this, not willing to learn C++ at all!)
                  I really wish someone would sticky this in the blueprint section of the forums lol.
                  Marketplace Assets

                  Advanced Mobile Input: Marketplace Page | Support Thread ――― Easy Input Remapping: Marketplace Page | Support Thread
                  Multiplayer Blueprint Chat System: Marketplace Page | Support Thread ――― Closing Credits System: Marketplace Page | Support Thread
                  Minesweeper Template: Marketplace Page | Support Thread ――― Maze Creator: Marketplace Page | Support Thread

                  Comment


                  • #24
                    Originally posted by Jamendxman3 View Post
                    I really wish someone would sticky this in the blueprint section of the forums lol.
                    I'm afraid, no one would read it ):
                    Open for contracted work | Blueprints | UE4++/C++ | Training | VR | My Website

                    My UE4 Blog/Page with Free Learning Projects and more: Hit me for ALL the things!

                    BP Multiplayer Lobby System: [Released] Support Thread! | BP Multiplayer Crafting System: [Released] Support Thread!

                    Comment


                    • #25
                      "Objective Orientated Programming!" haha you made my day !

                      Sorry to update an old post but i am at this point :
                      I have strong background in IT (use to be a software architect) but kind of noob on C++, ue4 C++ we could say.
                      My story is i started with blueprint and had a lot of fun (still noob).
                      Then i felt like maybe i miss a lot of the engine features doing only blueprint, so i started to create C++ object and create blueprint whith those class as parent (in case i need C++).
                      then i started code C++, (hey coder for life) thinking, "BP is fun but it is slow to write so basic loop, i could code faster in C++" and then BOOM.
                      Nobody mention one thing : The ****ing compilation time !!! it is very painfull !
                      I am still leaning the ue4 C++ and i can tell i am much more slower to progress than with the BP where i can try, change compile in 2 sec, have visual debug, test again.

                      For noob with basic OOP knowledge, i think starting with BP is more fun, let you lean about the ue4 API, before going to c++ compilation time and editor crashes (cause of your bad code) that can hurt you motivation.




                      Comment

                      Working...
                      X