Announcement

Collapse
No announcement yet.

Unreal Engine 4.6 Released!

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

    #61
    I have been a professional software engineer for nearly two decades and I cringe when I see stuff like this:
    "TSubobjectPtr<> has been deprecated, along with all public subobject properties which will be made private in the 4.7 release. Going forward, classes should be designed so that all subobject properties are private and can only only be accessed through public Get*() functions."

    There is very little reason to make anything private in a class, you should be using protected instead of private. The base classes that inherit from the engine source will use the variables and if you require them to access the member variables through Get*() functions then that will add additional stack processing overhead. The only way to do that would be to make them inline, but at that point why not just make them protected and make the Get*() functions inline? Then you will have the best of both worlds. Restricted use for other classes via the Get*() functions, children classes can still use the member variables or the Get*() accessors (their choice), and you'll reduce stack overhead. Even though computers are faster nowadays I hate to see unnecessary overhead in an industry that is performance driven.

    I have worked on real-time distributed systems where performance and optimization were key otherwise people would get killed. Please consider the above as it comes with a lot of experience in designing software.

    Comment


      #62
      with FSlateApplication::OnControllerButtonPressed(FKey, int32, bool) changed to FSlateApplication::OnControllerButtonPressed(EControllerButtons::Type, int32, bool) in 4.6, what is the correct way to implement input mapping for custom keys in 4.6?
      Plugins: Node.js - TensorFlow - Socket.io Client - ZipUtility - Leap Motion - Hydra - Myo - RealSense

      Comment


        #63
        Hi Kory,

        I'm wondering if perhaps Epic's explanation is incomplete, which is leading to a misunderstanding. Epic can't really control the visibility that we provide for our own subobjects, so I interpreted their explanation as, "In our efforts to implement 'information hiding', we will no longer provide developers with direct access to the properties in our base classes. Instead, developers will have to access these properties via getters/setters so that we can better manage future upgrades to our engine classes without breaking existing user code." Long-winded, but that's how I read it.

        - Dean

        Originally posted by Kory View Post
        I have been a professional software engineer for nearly two decades and I cringe when I see stuff like this:
        "TSubobjectPtr<> has been deprecated, along with all public subobject properties which will be made private in the 4.7 release. Going forward, classes should be designed so that all subobject properties are private and can only only be accessed through public Get*() functions."

        There is very little reason to make anything private in a class, you should be using protected instead of private. The base classes that inherit from the engine source will use the variables and if you require them to access the member variables through Get*() functions then that will add additional stack processing overhead. The only way to do that would be to make them inline, but at that point why not just make them protected and make the Get*() functions inline? Then you will have the best of both worlds. Restricted use for other classes via the Get*() functions, children classes can still use the member variables or the Get*() accessors (their choice), and you'll reduce stack overhead. Even though computers are faster nowadays I hate to see unnecessary overhead in an industry that is performance driven.

        I have worked on real-time distributed systems where performance and optimization were key otherwise people would get killed. Please consider the above as it comes with a lot of experience in designing software.

        Comment


          #64
          With regard to the references to our subobjects, would this:

          TSubobjectPtr<class USkeletalMeshComponent> Body;
          become:

          USkeletalMeshComponent* Body;
          If yes, I wonder how they garbage collect these. Perhaps they can do it because we would still use PCIP to create the object.

          -Dean

          Originally posted by rcapote View Post
          The way I understand it is you only need to have a constructor with FObjectInitializer if you use "PCIP" to create a component. If you don't need the PCIP object, then you don't have to specify it as an argument in the constructor.



          The new constructors don't effect this at all. You still have to create components and spawn actors the same way as before.
          Last edited by DM_Actual; 12-05-2014, 01:03 PM.

          Comment


            #65
            You mark them as UPROPERTY()
            Anything that have UPROPERTY() macro is GC'd.
            https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

            Comment


              #66
              That makes sense. Thank you.

              Originally posted by iniside View Post
              You mark them as UPROPERTY()
              Anything that have UPROPERTY() macro is GC'd.

              Comment


                #67
                Is it normal I can't package my game for Linux? I get automatically an error.

                Comment


                  #68
                  FYI

                  I just download the new version of ShooterGame for 4.6 and when I compiled it and tried to run it, all I get is a black screen.

                  Comment


                    #69
                    Originally posted by onlycalvin View Post
                    how to use WebBrowser in Blueprint?
                    I'm afraid we don't support it in blueprints yet. Just to clarify its usage too, since it is a developer module, it's intended to be used in the editor and other programs rather than games. That makes it something we will largely be using internally but you could still make use of it.

                    The small controls help pop up in the bottom left of editor viewports uses it to display a html file and there is an example of its use as a web browser in the slateviewer example. The main class of interest is SWebBrowser.

                    Comment


                      #70
                      Originally posted by getnamo View Post
                      with FSlateApplication::OnControllerButtonPressed(FKey, int32, bool) changed to FSlateApplication::OnControllerButtonPressed(EControllerButtons::Type, int32, bool) in 4.6, what is the correct way to implement input mapping for custom keys in 4.6?
                      I'm interested in this as it broke that functionality in one of my custom plugins and I'd like to use Input Mappings instead of binding Delegate's in BPs as a workaround

                      Originally posted by Kory View Post
                      I have been a professional software engineer for nearly two decades and I cringe when I see stuff like this:
                      "TSubobjectPtr<> has been deprecated, along with all public subobject properties which will be made private in the 4.7 release. Going forward, classes should be designed so that all subobject properties are private and can only only be accessed through public Get*() functions."

                      There is very little reason to make anything private in a class, you should be using protected instead of private. The base classes that inherit from the engine source will use the variables and if you require them to access the member variables through Get*() functions then that will add additional stack processing overhead. The only way to do that would be to make them inline, but at that point why not just make them protected and make the Get*() functions inline? Then you will have the best of both worlds. Restricted use for other classes via the Get*() functions, children classes can still use the member variables or the Get*() accessors (their choice), and you'll reduce stack overhead. Even though computers are faster nowadays I hate to see unnecessary overhead in an industry that is performance driven.

                      I have worked on real-time distributed systems where performance and optimization were key otherwise people would get killed. Please consider the above as it comes with a lot of experience in designing software.
                      I agree on optimization should always come first and most people nowadays don't program with that in mind. It's possible since they have their own custom compiler that it specifically looks for the different UProperties and their respective accessor methods (ie Get*() const) and maybe does automatic inlining of those functions behind the scenes, but let's not forget Unreal Engine 3 won awards for most optimized game engine so I'm sure they know what they are doing on this one but it does sound iffy. I'm looking forward to hearing what they say about this one but yes, it absolutely would add an additional call in many cases where it wouldn't be needed.
                      Last edited by MC Stryker; 12-05-2014, 06:34 PM.

                      Comment


                        #71
                        What are the limitations of using shared samples? I heard the format must be the same for all textures, but do all the textures need to be the same size?

                        Comment


                          #72
                          Hey guys

                          I bought a subscription back in the days if v 1.1 and cancelled my subscription the same month due to performance absolutely sucking on my system. My CPU and RAM were both far over the recommended limit but my GPU seemed to be the problem. I have heard that UE4 has undergone massive improvements on the Mac end but don't want to buy a subscription again only to find my system is still not capable of more than 7 FPS when everything set to it's lowest setting and all lights turned off (all except one but with no shadows)

                          Can someone please confirm for me how well UE4 runs nowadays on a 2011 model iMac, please?
                          2.7Ghz i5
                          12GB Ram
                          AMD Radion HD 6770M 512Mb

                          Will I be wasting my time getting UE4 again or how well does it run on these specs nowadays?

                          Thanks in advance for any feedback

                          Comment


                            #73
                            Originally posted by DM_Actual View Post
                            Hi Kory,

                            I'm wondering if perhaps Epic's explanation is incomplete, which is leading to a misunderstanding. Epic can't really control the visibility that we provide for our own subobjects, so I interpreted their explanation as, "In our efforts to implement 'information hiding', we will no longer provide developers with direct access to the properties in our base classes. Instead, developers will have to access these properties via getters/setters so that we can better manage future upgrades to our engine classes without breaking existing user code." Long-winded, but that's how I read it.

                            - Dean
                            Hi Dean,
                            Yes, if they are purposefully trying to do this to protect the state of the engine I can understand that from an Public API perspective. I guess all of the projects I have ever worked on were written by top-notch developers so we all knew what we should and shouldn't be doing. If anything, I hope they at least inline them for things like GetMesh() and GetCapsuleComponent(), it was quite annoying to change all of those to remove the DEPRECATED warnings.

                            Comment


                              #74
                              I have long thought that inheritance is one of the best things in C++ - however, my real experiences has slowly taught me otherwise. Inheritance will cause member variables which are protected before, exposed. And this can cause bugs and frustrations and probably you will need to change the ancestor to suit the inheritor (which are double whammy problems).
                              It is better to make it private of every member variables because you will want the inherited classes not to abuse them (ie using them in undocumented manners, or use them which cause crash and then blame UE4 - technical headache everyone).

                              Anyway, I do support composition over inheritance and therefore, I support the private over protected member variables.

                              Comment


                                #75
                                Neat stuff.
                                Now to try and finally get a working context menu in umg, through actor component...

                                Comment

                                Working...
                                X