Change when ImageNtHeader is called to PreInitPostStartupScreen. This is after some hidden DbgHelp initialization is done so future calls to SymFromAddr succeed. There is not a clear answer for when ImageNtHeader can be called but where it was before was too early.
This is potentially an issue with large PDBs
This issue only was seen to reproduce in monolithic exes
[REVIEW] [at]Bob.Tellez [at]Devin.Doucette [at]Robert.Millar [at]Gary.Yuan [at]Joe.Kirchoff
#preflight 636c0f617c2b505190240d9b
[CL 23071975 by eric knapik in ue5-main branch]
Moved GetTypeHash function to be hidden friend instead of put directly in global namespace.
Note that the function/operator needs to be fully inlined in the type or placed in the cpp. If the function is added as friend but then implemented outside the type then hidden friend optimization won't work.
This should improve compile time somewhat according to msvc devs.
#rb Steve.Robb
#preflight 6360b7052b5338aceb26471b
[CL 22889837 by henrik karlsson in ue5-main branch]
Starting the thread allows it to flush buffered lines, which is problematic if it happens before the default output devices have been initialized. Wait until after they are initialized by AppInit before starting the dedicated thread.
#jira UE-168823
#preflight 63603ed866696ca050784407
#rb Matt.Peters
#rnx
[CL 22882224 by Devin Doucette in ue5-main branch]
Moved MMV exit code to it's own function
#rb robert.srinivasiah, Arciel.Rekman #preflight 22486450 #jira UE-168613
[CL 22820432 by juliet dipietro in ue5-main branch]
NOTE: Restoring CL 22626782 after it was backed out in CL 22658209. Resolved the problem by using a different FParse::Token overload.
Previously, it was assumed that the first parameter was the project path (.uproject) or the game name. The next one was optionally a map override name or a commandlet. While this expectation makes sense, it was difficult to comply given that on some platforms and some launch modes we combine command-line parameters provided to the executable (e.g. from Visual Studio) with ones in uecommandline.txt script. We had some conflicting requirements and because of that certain launch scenarios didn't work.
Modified the code to look for the game name / project path withing all the parameters, regardless of the position. Other than that, I've tried to preserve the preexisting behavior. In a few places I've updated the code to allow other switches at arbitrary location withing the command line.
Testing done:
* Editor: no parameters (project selector); running commandlets (short and long names and/or -run=) with different sets of parameters; running the editor with different parameters; running the game (-game)
* Game (cpp + bp): running commandlets (short and long names) with different parameters; running the game with different combonations of project, map and other switches.
#preflight
#rb David.Harvey
#jira UE-99467 UE-159599
#rn fix core Allowed more flexibility when looking for the project name command-line parameter. Previously, it was expected to be always the first parameter. Now, we check all the provided parameters. It fixes some launch scenarios (e.g. launching blueprint-only projects with additional command-line parameters) that didn't work due to the fixed order in which we combine command-line parameters with the contents of uecommandline.txt script.
[CL 22666957 by wojciech krywult in ue5-main branch]
#fyi Wojciech.Krywult
Original CL Desc
-----------------------------------------------------------------
Command line: EngineLoop: Reworked the way we handle command-line parameters during initialization to allow more flexibility (project/game name).
Previously, it was assumed that the first parameter was the project path (.uproject) or the game name. The next one was optionally a map override name or a commandlet. While this expectation makes sense, it was difficult to comply given that on some platforms and some launch modes we combine command-line parameters provided to the executable (e.g. from Visual Studio) with ones in uecommandline.txt script. We had some conflicting requirements and because of that certain launch scenarios didn't work.
Modified the code to look for the game name / project path withing all the parameters, regardless of the position. Other than that, I've tried to preserve the preexisting behavior. In a few places I've updated the code to allow other switches at arbitrary location withing the command line.
Testing done:
* Editor: no parameters (project selector); running commandlets (short and long names and/or -run=) with different sets of parameters; running the editor with different parameters; running the game (-game)
* Game (cpp + bp): running commandlets (short and long names) with different parameters; running the game with different combonations of project, map and other switches.
#preflight
#rb David.Harvey
#jira UE-99467 UE-159599
#rn fix core Allowed more flexibility when looking for the project name command-line parameter. Previously, it was expected to be always the first parameter. Now, we check all the provided parameters. It fixes some launch scenarios (e.g. launching blueprint-only projects with additional command-line parameters) that didn't work due to the fixed order in which we combine command-line parameters with the contents of uecommandline.txt script.
[CL 22658209 by wojciech krywult in ue5-main branch]
Previously, it was assumed that the first parameter was the project path (.uproject) or the game name. The next one was optionally a map override name or a commandlet. While this expectation makes sense, it was difficult to comply given that on some platforms and some launch modes we combine command-line parameters provided to the executable (e.g. from Visual Studio) with ones in uecommandline.txt script. We had some conflicting requirements and because of that certain launch scenarios didn't work.
Modified the code to look for the game name / project path withing all the parameters, regardless of the position. Other than that, I've tried to preserve the preexisting behavior. In a few places I've updated the code to allow other switches at arbitrary location withing the command line.
Testing done:
* Editor: no parameters (project selector); running commandlets (short and long names and/or -run=) with different sets of parameters; running the editor with different parameters; running the game (-game)
* Game (cpp + bp): running commandlets (short and long names) with different parameters; running the game with different combonations of project, map and other switches.
#preflight
#rb David.Harvey
#jira UE-99467 UE-159599
#rn fix core Allowed more flexibility when looking for the project name command-line parameter. Previously, it was expected to be always the first parameter. Now, we check all the provided parameters. It fixes some launch scenarios (e.g. launching blueprint-only projects with additional command-line parameters) that didn't work due to the fixed order in which we combine command-line parameters with the contents of uecommandline.txt script.
[CL 22626782 by Wojciech Krywult in ue5-main branch]
- Should be handled in MessageBoxExt function itself but it is not yet implemented across all platforms.
#rb Brandon.Schaefer
[REVIEW] [at]Zousar.Shaker, [at]Brandon.Schaefer, [at]Robert.Srinivasiah
#jira none
#preflight none
[CL 22284259 by arciel rekman in ue5-main branch]
This change includes significant refactor work performed in //UE5/Dev-ParallelRendering. A brief summary of the work is as follows:
Refactored RHI command lists
- Removal of the "immediate" async compute command list
- Introduced an "active pipe" on each command list, allowing RHICmdLists to record work for either graphics or async compute. Pipes can be selected using the SwitchPipeline() function, or the FRHICommandListScopedPipeline helper.
- New explicit command list submission RHI API (RHIFinalizeContext, RHISubmitCommandLists). The IRHICommandContextContainer type has been removed.
- Explicit GPU submission is automatically appended to the immediate command list when it is dispatched to the RHI thread.
Platform RHI implementations
- The new submission API has been implemented across all platforms. Some platforms required a significant refactor.
#rb Mihnea.Balta,Kenzo.Terelst
#jira UE-139550
#preflight 6332e3641003050806d802ef
[CL 22239063 by luke thatcher in ue5-main branch]
- Assume support during the cook, do the actual check in runtime and exit if not supported.
- This slightly increases the minspec for PC projects that ship ISR to D3D 11.3 (2014-2015 level hardware).
#rb Jules.Blok, Robert.Srinivasiah
#review @Jules.Blok, @Robert.Srinivasiah
#jira UE-162244
#preflight 632b4d6cb4515b7e2272620d
[CL 22207954 by Arciel Rekman in ue5-main branch]
- Also, only issue the warning if we waited at least 1ms in that call.
#rb Kenzo ter Elst, Jason Nadro
#jira UE-163502
#review @Kenzo.Terelst, @Jason.Nadro
#preflight 632b0f15b40000c8f0c4705a
[CL 22116865 by Arciel Rekman in ue5-main branch]
- Fix for some DeviceProfiles not reading in their parent TextureLODGroups
- Remove the call to UDeviceProfileManager::Get() that was being called too early, before object subsystem is ready, so it was unable to load all the other platform DeviceProfiles
[REVIEW] [at]elizabeth.bunner, [at]josh.adams
#tests preflight 631258e02b7fe03eb6d9d725
[CL 21774577 by mickael gilabert in ue5-main branch]
