4.25 Transition Guide

Development Programming & Scripting C++
3

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]

2 Likes