FImageWriteTask now accepts TArray64 as data instead of a TArray. If you have a regular TArray, pass it in like this:
TArray<FColor> OutBMP;
// Fill OutBMP somehow
TUniquePtr<TImagePixelData<FColor>> PixelData = MakeUnique<TImagePixelData<FColor>>(DestSize);
PixelData->Pixels = OutBMP;
ImageTask->PixelData = MoveTemp(PixelData);
[HR][/HR]2)
Shaders no longer have an explicit
virtual bool Serialize(FArchive& Ar) override
method to serialize.
This is now instead achieved by wrapping all shader parameters in a LAYOUT_FIELD macro.
FShaderResourceParameter ReadBuffer // Old declaration
LAYOUT_FIELD(FShaderResourceParameter, ReadBuffer); // New declaration
For the LAYOUT_FIELD macro to work, the shader needs to be declared with the DECLARE_SHADER_TYPE macro (which most shaders probably have, see side note below). [HR][/HR]2b)
Side note for people using inheritance with shaders (probably not a huge subset of people) :
Using the normal macros for shader declare/implement breaks inheritance with virtual functions in shaders.
Got this to work - if you have a shader that’s intended only as a parent shader (not to be implemented) with virtual methods, you have to call
DECLARE_EXPORTED_TYPE_LAYOUT(FYourShaderName, YOUR_API, Virtual);
within the shader declaration and in a .cpp somewhere do
IMPLEMENT_UNREGISTERED_TEMPLATE_TYPE_LAYOUT(, FYourShaderName);
And in shaders with virtual methods (where the shader will be implemented), you have to call
INTERNAL_DECLARE_SHADER_TYPE_COMMON(FYourSecondShaderName, Global, YOUR_API);
DECLARE_EXPORTED_TYPE_LAYOUT(FYourSecondShaderName, YOUR_API, Virtual);
in the class declaration and standard IMPLEMENT_GLOBAL_SHADER in a cpp somewhere.
With this setup, it seems the serialization of shaders works fine with virtual methods too.
Not sure why Epic decided that you won’t ever need a virtual memory layout with shaders (their regular macros assume it, see DECLARE_EXPORTED_SHADER_TYPE). [HR][/HR]