---
Enable Metal RHI runtime virtual texture support.
#rb matt.collins
#jira UE-81243
[FYI] rolando.caloca
#ROBOMERGE-SOURCE: CL 12475213 in //UE4/Release-4.25/... via CL 12475219 via CL 12475222
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v672-12450963)
[CL 12475231 by will damon in Main branch]
Add SSE and AVX defines to allow specifying availability on PC, MAC, and Linux.
SSE and AVX defines have ALWAYS_HAS and MAYBE_HAS variants to distinguish between available to compile and available to run without the need to check cpuid.
Add templated base classes TUnrealPlatformMathSSEBase and TUnrealPlatformMathSSE4Base to remove the boilerplate overrides added by each of the platformmaths that use the sse overrides.
#rb Steve.Robb
#rn Minor
[CL 10942197 by Matt Peters in Dev-Core branch]
#rnx
#rb none
#ROBOMERGE-OWNER: ryan.durand
#ROBOMERGE-AUTHOR: ryan.durand
#ROBOMERGE-SOURCE: CL 10869210 via CL 10869511 via CL 10869900
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870549 by ryan durand in Main branch]
#rb Brandon.Schaefer
#ROBOMERGE-SOURCE: CL 10310653 via CL 10310659 via CL 10310665
#ROBOMERGE-BOT: (v593-10286020)
[CL 10310671 by michael trepka in Main branch]
Most UE4 platforms use a 2-byte TCHAR, however some still use a 4-byte TCHAR. The platforms that use a 4-byte TCHAR expect their string data to be UTF-32, however there are parts of UE4 that serialize FString data as a series of UCS2CHAR, simply narrowing or widening each TCHAR in turn. This can result in invalid or corrupted UTF-32 strings (either UTF-32 strings containing UTF-16 surrogates, or UTF-32 code points that have been truncated to 2-bytes), which leads to either odd behavior or crashes.
This change updates the parts of UE4 that process FString data as a series of 2-byte values to do so on the correct UTF-16 interpretation of the data, converting to/from UTF-32 as required on platforms that use a 4-byte TCHAR. This conversion is a no-op on platforms that use a 2-byte TCHAR as the string is already assumed to be valid UTF-16 data. It should also be noted that while FString may contain UTF-16 code units on platforms using a 2-byte TCHAR, this change doesn't do anything to make FString represent a Unicode string on those platforms (ie, a string that understands and works on code points), but is rather just a bag of code units.
Two new variable-width string converters have be added to facilitate the conversion (modelled after the TCHAR<->UTF-8 converters), TUTF16ToUTF32_Convert and TUTF32ToUTF16_Convert. These are used for both TCHAR<->UTF16CHAR conversion when needed, but also for TCHAR<->wchar_t conversion on platforms that use char16_t for TCHAR along with having a 4-byte wchar_t (as defined by the new PLATFORM_WCHAR_IS_4_BYTES option).
These conversion routines are accessed either via the conversion macros (TCHAR_TO_UTF16, UTF16_TO_TCHAR, TCHAR_TO_WCHAR, and WCHAR_TO_TCHAR), or by using a conversion struct (FTCHARToUTF16, FUTF16ToTCHAR, FTCHARToWChar, and FWCharToTCHAR), which is the same pattern as the existing TCHAR<->UTF-8 conversion. Both the macros and the structs are defined as no-ops when the conversion isn't needed, but always exist so that code can be written in a portable way.
Very little code actually needed updating to use UTF-16, as the vast majority makes no assumptions about the size of TCHAR, nor how FString should be serialized. The main places were the FString archive serialization and the JSON reader/writer, along with some minor fixes to the UTF-8 conversion logic for platforms using a 4-byte TCHAR.
Tests have been added to verify that an FString representing a UTF-32 code point can be losslessly converted to/from UTF-8 and UTF-16, and serialized to/from an archive.
#jira
#rb Steve.Robb, Josh.Adams
#ROBOMERGE-SOURCE: CL 8676728 via CL 8687863
#ROBOMERGE-BOT: (v421-8677696)
[CL 8688048 by jamie dale in Main branch]
- This allows for Confidential platforms to exist outside of the engine, and insert themselves in as needed
- Directory structure is, where .... mirrors the directory structure for Engine and projects
- /Platforms/XXX/....
- Moving to more data driven approach for ShaderPlatforms and PlatformInfo, where they can be read from DataDrivenPlatformInfo.ini files that live in the platform config folders
- Removed platform mentions from UBT, by way of changing some enums to partial classes with static members (see UnrealTargetPlatform)
- Various other UBT/UAT modifications to allow for looking in other locations for files
- THIS IS NOT A COMPLETE AND FINAL SOLUTION. WE WILL CONTINUE WORK IN DEV-BUILD BEFORE ITS READY FOR PRIMETIME
#rb ben.marsh
[CL 6271418 by Josh Adams in Dev-Build branch]
