Shader classes, mixins and inheritance
- shader classes are the foundation of the code
- shader classes contain methods and members
member types can be shader classesXKSL uses an original way to handle multiple inheritance. Inheritance is performed through mixins, so the order of inheritance is crucial:
the order of inheritance defines the actual implementation of a method (the last override)
- if a mixin appears several times in the inheritance, only the first occurrence is taken into account (as well as its members and methods)
- to can call the previous implementation of a method, use
stage
: method and member keyword. This keyword makes sure the method or member is only defined once and is the same in the compositions.stream
: member keyword. The member is accessible at every stage of the shader. For more information, see .streams
: sort of global structure storing variables needed across several stages of the shader. For more information, see Automatic shader stage input/out.override
: method keyword. If this keyword is missing, the compilation returns an error.abstract
: used in front of a method declaration (without a body).clone
: method keyword. When a method appears several times in the inheritance tree of a shader class, this keyword forces the creation of multiple instances of the method at each level of the inheritance instead of one. For more information, see .- : for geometry and tessellation shaders. For more information, see Shader stages.
Input2
: for tessellation shaders. For more information, see .Constants
: for tessellation shaders. For more information, see Shader stages.
Abstract methods
Abstract methods are available in XKSL. They should be prefixed with the abstract
keyword. You can inherit from a shader class with abstract methods without having to implement them; the compiler will simply produce a harmless warning. However, you should implement it in your final shader to prevent a compilation error.
Like HLSL, annotations are available in XKSL. Some of the most useful ones are:
[Color]
for float4 variables. The ParameterKey will have the typeColor4
instead of . It also specifies to Game Studio that this variable should be treated as a color, so you can edit it in Game Studio.[Link(…)]
specifies which ParameterKey to use to set this value. However, an independent default key is still created.[Map(…)]
specifies which ParameterKey to use to set this value. No new ParameterKey is created.[RenameLink]
prevents the creation of a ParameterKey. It should be used with[Link()]
.
Example code: inheritance
You can also use a variable or call a method from a shader without having to inherit from it. To do this, use . It behaves the same way as a static call.
Note that if you statically call a method that uses shader class variables, the shader won't compile. This is a convenient way to only use a part of a shader, but this isn't an optimization. The shader compiler already automatically removes any unnecessary variables.