Announcement

Collapse
No announcement yet.

Wondering if I can even do this

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

    #16
    Originally posted by Jared Therriault View Post
    Thank you very much for your response! Can you be a little more specific about what you mean by that? Again, I'm a C++ noob, so this language is a bit outside my wheelhouse. My benchmarks were with the Code Side Scroller template, do you know if that uses just the libraries? Are you referring to using the Unreal VS extension and choosing just your game from the drop-down list?

    In the end though your fast compile times might have something to do with having 12 CPUs lol
    Hello what i mean is that if you only install the engine, and do not download the full source code.
    You stile have access to the full API of the engine,"What do this mean?"

    When Epic ship a version it has new DLL files and .lib files and the header files (.h).
    This way code is pre-compiled for you when you start a code project,
    it will use .lib files and/or link DLLs and use the headers for knowing about the compiled code. (Any project you create use these.)
    This is how your project should look in Visual Studio.
    Click image for larger version

Name:	project.JPG
Views:	1
Size:	29.8 KB
ID:	1052546If you have a UE 4 Solution there as well you are using the full source code.

    Some reson you may have to use the full source code is to change engine code, make plugins, fix bugs or contribute.
    Hope this helps, let me know if somthing is not clear.

    Also take a look at Programming Guide > Development Setup > Setting Up Visual Studio for UE4

    And yes HEX core also helps hehe
    Last edited by WCode; 07-10-2014, 08:30 PM. Reason: Spelling

    Comment


      #17
      Originally posted by WCode View Post
      Hello what i mean is that if you only install the engine, and do not download the full source code.
      You stile have access to the full API of the engine,"What do this mean?"

      When Epic ship a version it has new DLL files and .lib files and the header files (.h).
      This way code is pre-compiled for you when you start a code project,
      it will use .lib files and/or link DLLs and use the headers for knowing about the compiled code. (Any project you create use these.)
      This is how your project should look in Visual Studio.
      [ATTACH=CONFIG]6573[/ATTACH]If you have a UE 4 Solution there as well you are using the full source code.

      Some reson you may have to use the full source code is to change engine code, make plugins, fix bugs or contribute.
      Hope this helps, let me know if somthing is not clear.

      Also take a look at Programming Guide > Development Setup > Setting Up Visual Studio for UE4

      And yes HEX core also helps hehe
      So if we use the version with the source code, then we will have slower compile times? Is there a way to avoid compiling the Engine every time?

      Comment


        #18
        The simplest way is just not download the source code from GitHub.
        And just start a new code project from the launcher.

        That way you are only compiling the game module(s).
        Last edited by WCode; 07-10-2014, 10:58 PM. Reason: spelling

        Comment


          #19
          Originally posted by WCode View Post
          The simplest way is just not download the source code from GitHub.
          And just start a new code project from the launcher.

          That way you are only compiling the game module(s).
          I want to corroborate this. I downloaded the compiled editor from the unreal site and compiled the same game code again and got a cool 13 seconds from VS to editor. That's extremely reasonable, though I'd love any more improvements that could be made, of course.

          I should point out that

          MinFilesUsingPrecompiledHeaderOverride = 1;
          bFasterWithoutUnity = true;

          still made no appreciable difference in compile times for this particular project, in case anyone was wondering.

          -Jared
          Procedural, modular, on-the-fly animation - iTween For UE4
          - Actors - Components - UMG - Ease In - Ease Out - Path-constrained Animation - $0

          Runtime Datatable
          -All the fun of DataTables dynamically loaded from text or Google Sheets while your game is running!

          Comment


            #20
            Using a SSD should speed up compile times significantly.

            When I was compiling something i could never see my CPU at 100% it was
            always the HDD limiting the speed, cause of it's bad access times and the
            overall lower speed.

            Comment


              #21
              Originally posted by Ignite View Post
              So if we use the version with the source code, then we will have slower compile times? Is there a way to avoid compiling the Engine every time?
              No, that shouldn't be the case at all. When you compile from source, the UE4 codebase is only compiled once, unless you make changes to it which is unlikely if you're still learning how to use it. If you were to recompile everything, that would take much longer than 30 seconds. The compiler will just link with the libraries directly without a recompile, which is exactly the same as the precompiled libraries Epic supplies with their binary distribution.

              So I'm not sure what WCode meant by that.

              Generally if you make changes to headers it's going to take more time to compile. For reference ShooterGame takes 43 seconds to compile after a smaller change in a CPP file (headers usually take longer) on my rig. (i7 Quad, mechanical HDD)

              With that said, they're working on decreasing build times and they've said 4.3 is a little bit faster than 4.2. The difference between 4.2 and 4.0 was huge. So hopefully it'll only get better. I try to avoid making smaller changes in C++ and try to expose those to the editor as variables. This way iteration is much faster, but if you're changing gameplay code then I guess you'll have to live with it or buy an SSD. It should help some.

              Edit: I also try to stay away from hot recompilation. It usually breaks for me (even if I'm only changing a variable), and isn't much faster.

              Comment


                #22
                What i meant was just avoid the full source if you dont need it.
                As OP is stile lerning C++ i tought it best to leave out any "vierd" words/ names.
                And just help OP got setup with the binarys and start from there.

                But i think Stefan Lundmark did a better job of explaining it.

                Comment


                  #23
                  Agreed, using the source binaries is a better start even if it isn't any faster to compile against.

                  Out of curiosity, what version are you guys testing on? I haven't gotten around to try 4.3 yet but the improvements between 4.0 and 4.2 are huge, so hopefully they're not done yet.

                  Comment


                    #24
                    Originally posted by Stefan Lundmark View Post
                    Agreed, using the source binaries is a better start even if it isn't any faster to compile against.

                    Out of curiosity, what version are you guys testing on? I haven't gotten around to try 4.3 yet but the improvements between 4.0 and 4.2 are huge, so hopefully they're not done yet.
                    I'm holding off for the official 4.3 release rather than the preview, so I'm using 4.2.1. I see what you're saying, Stefan. But it is fact that compile times for the same game using compiled-by-me UE4 source VS UE4 binary amount to 36 seconds and 13 seconds, respectively. Whatever the case may be, my compile times with the binary are much, much faster.
                    Procedural, modular, on-the-fly animation - iTween For UE4
                    - Actors - Components - UMG - Ease In - Ease Out - Path-constrained Animation - $0

                    Runtime Datatable
                    -All the fun of DataTables dynamically loaded from text or Google Sheets while your game is running!

                    Comment


                      #25
                      Originally posted by Jared Therriault View Post
                      I'm holding off for the official 4.3 release rather than the preview, so I'm using 4.2.1. I see what you're saying, Stefan. But it is fact that compile times for the same game using compiled-by-me UE4 source VS UE4 binary amount to 36 seconds and 13 seconds, respectively. Whatever the case may be, my compile times with the binary are much, much faster.
                      I hear you Jared, and it's very interesting since there shouldn't be any difference. I know the optimization stage takes a lot of time when building release, so maybe there are differences there. Not sure what's going on, maybe someone can chime in from Epic.

                      Comment


                        #26
                        We are working on compile times a lot right now here at Epic! There is a big push for faster iteration, you will see some of these changes in 4.3 but we have a lot of work yet to do. I'd be happy to go into detail for those who are interested, but in short we are dramatically shrinking the number of engine header files that need to be included in every game source file as well as optimizing Unreal Build Tool startup times. We're also working with Microsoft to profile compile times with UE4 and hope to further optimize build performance using that data.

                        Meanwhile, incremental compile times when changing only a few game source files should actually be very fast (6 seconds or less). This is because the precompiled header that was generated for your game module was cached and will be reused on subsequent compiles. The only code that that compiler will redigest is your actual game source file, not the included header files, which usually completes very quickly! (less than a second.)

                        If you go and change a "global" header file for your game, then Unreal Build Tool will need to recompile the precompiled header for your game, and you can expect a slower build that time. It can help to only use #includes in the .cpp files that actually need them, and to avoid creating a massive game header file that includes all of your other header files. Even though that will be convenient for a programmer, it can demolish your productivity if you are constantly changing game header files.

                        We also have some baseline overhead as Unreal Build Tool starts up, which is scanning your hard drive for source files and building the dependency graph. If you are working with a build from GitHub, the dependency scanning will take longer because Unreal Build Tool will try to determine if the engine itself needs to be recompiled. We are working to optimize this UBT startup time, but it should still not be more than a few seconds for a normal game project.

                        For example, if I rebuild VehicleGame (from the Vehicle sample on the Marketplace), make a change to VehicleGameMode.cpp, then perform a normal build (Development Editor configuration), the average time to complete is only 6 seconds.

                        If you're using the source from GitHub, rebuilding the entire Unreal Engine obviously takes a lot longer. I can rebuild 4.3 on my MacBook Pro in 16 minutes. In order to achieve this, I set my ProcessorCountMultiplier setting (in BuildConfiguration.xml) to 2.5. This setting will control how many translation units can be compiled at the same time. By default ProcessorCountMultiplier defaults to 1.0, which means 100% of your total number of processors (one compiler invocation per processor.) However, many computers have multiple hyperthreaded cores, which means it can be advantageous to set ProcessorCountMultiplier to 2.0 or higher to get the fastest possible rebuild times. This will of course use more battery life and make multitasking slower, so it is a trade off that you need to experiment with.

                        Computer specs will of course be a factor and having an SSD or RAID will help if your disk cache is cold, but in general the iterative compile times are mostly affected by what I described above, and more RAM or a new HDD will not help much. More cores can help for rebuilds, but not for iterative builds.


                        Originally posted by Jared Therriault View Post
                        MinFilesUsingPrecompiledHeaderOverride = 1;
                        bFasterWithoutUnity = true;

                        still made no appreciable difference in compile times for this particular project, in case anyone was wondering.
                        I wanted to also point out that the information above (originally from my AnswerHub post) is now out of date. Unreal Build Tool will force generation of precompiled headers and non-unity builds for "smaller" game projects (as configurable with MinGameModuleSourceFilesForUnityBuild) in your BuildConfiguration.xml. I set it up this way so that you wouldn't have to worry about tweaking out settings to get fast iterative compiles on small projects or sample games. Larger projects usually see the real benefits of unity-based compiles and no-PCH compiles, so we tried to make it automatic.


                        --Mike
                        Last edited by Dark-Veil; 07-15-2014, 02:39 PM.

                        Comment


                          #27
                          Thank you so much for chiming in, Mike! I really appreciate it.

                          I should clarify that now the biggest stop-gap in the pipeline isn't compile times, but rather the editor's loading sequence. I count them together because it's necessary to close the editor to make changes to the code. To be honest, the compile times with the binary build amount to about 5 seconds. The load is just under 10 seconds. At this point, I'm pretty satisfied with how long the process takes, though I would of course prefer faster times if you can muster them!

                          I gotta say, I'm loving Epic's community outreach. Punches UT square in the jaw.
                          Procedural, modular, on-the-fly animation - iTween For UE4
                          - Actors - Components - UMG - Ease In - Ease Out - Path-constrained Animation - $0

                          Runtime Datatable
                          -All the fun of DataTables dynamically loaded from text or Google Sheets while your game is running!

                          Comment


                            #28
                            Originally posted by Jared Therriault View Post
                            Thank you so much for chiming in, Mike! I really appreciate it.

                            I should clarify that now the biggest stop-gap in the pipeline isn't compile times, but rather the editor's loading sequence. I count them together because it's necessary to close the editor to make changes to the code. To be honest, the compile times with the binary build amount to about 5 seconds. The load is just under 10 seconds. At this point, I'm pretty satisfied with how long the process takes, though I would of course prefer faster times if you can muster them!

                            I gotta say, I'm loving Epic's community outreach. Punches UT square in the jaw.
                            I agree! I love how transparent they are.

                            So there IS a difference between source builds and binary builds, like Mike mentioned above. So you were right, Jared.

                            Comment


                              #29
                              My biggest issue with build times (after initial builds of course ) is the check for UBT changes prior to compilation. I cannot complain as my compilation times are between 11 and 25 seconds. Full Iteration times, including editor load times, are not that important to me. If I have a problem it shows in compilation errors(syntax) and not logic errors.

                              Comment

                              Working...
                              X