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 type Color4 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.

    See also