4.0 release

[soywiz]

The objective of 4.0 is to fix important current bugs, decouple non-core functionality to kproject, ensure testing that detect regressions we had and ensure source-level public API stability for rendering (stabilise uniform buffers) and math (use immutable data classes so when MFVC classes are ready the API is there; this might lead to performance regressions until that happen, but will increase compatibility from day 1 without having to migrate kproject later)

• Fix current bugs
  • Rewrite event & component system
• Decouple non-core functionality to kproject
• Ensure testing that detect graphical regressions (screenshot testing and e2e tests)
• Future-proof rendering - [WIP] Start using AGUniformBlockValues (UniformBlockBuffer + indices) in AG #1175
• Unmix uniforms & texture units Handle Texture units outside Uniforms #1400
• Math compatible with MFVC - Evaluate MFVC for KorGE 4.0 #1257
• Remove deprecated APIs
• Rename packages

[soywiz]

If WASM is going to be available soon ™, should we start using floats for Point, Matrix, etc.?

[soywiz]

So in the end regarding MFVC:

• Removed IPoint
• Renamed Point -> MPoint
• Keeping MPoint as mutable using Double
• Created immutable version of Point, using two Floats. Wrapping Long in JVM/K/N and a custom class in JS (since JS engines are updated and have advanced escape anallisys), and since WASM will be available not too far away
• Done the same for Size, Scale, Anchor
• Created a Half (16-bit Float) and Short version for packing 4 values
• Used Half4Pack in RectCorners since the values are usually small, but still floating point
• For Matrix and other classes required MFVC, mark them as an annotation with a warning to know it allocates

This will be available since alpha-4

[soywiz]

Proposal for package renames:

• klock -> korlibs.time
• korinject -> korlibs.inject
• kds -> korlibs.datastructure
• kmem -> korlibs.memory
• korte -> korlibs.template
• kbignum -> korlibs.bignumber
• krypto -> korlibs.crypto
• ktruth -> korlibs.test
• korio -> korlibs.io
• korma -> korlibs.math
• korim -> korlibs.image
• korau -> korlibs.audio
• korgw -> korlibs.render
• korge -> korlibs.korge

[soywiz]

When using uniform buffers, we should generate something like this in the shader:

#version 300 es

layout(std140, binding = 2) uniform u_testBlock
{
    mediump vec4 v0;
    mediump vec4 v1;
};

By using 300 es, we should use in, out etc. instead of the old syntax. We should be sure that the generated layout matches std140 spec: https://www.oreilly.com/library/view/opengl-programming-guide/9780132748445/app09lev1sec2.html

      (1) If the member is a scalar consuming <N> basic machine units, the
          base alignment is <N>.

      (2) If the member is a two- or four-component vector with components
          consuming <N> basic machine units, the base alignment is 2<N> or
          4<N>, respectively.

      (3) If the member is a three-component vector with components consuming
          <N> basic machine units, the base alignment is 4<N>.

      (4) If the member is an array of scalars or vectors, the base alignment
          and array stride are set to match the base alignment of a single
          array element, according to rules (1), (2), and (3), and rounded up
          to the base alignment of a vec4. The array may have padding at the
          end; the base offset of the member following the array is rounded up
          to the next multiple of the base alignment.

      (5) If the member is a column-major matrix with <C> columns and <R>
          rows, the matrix is stored identically to an array of <C> column
          vectors with <R> components each, according to rule (4).

      (6) If the member is an array of <S> column-major matrices with <C>
          columns and <R> rows, the matrix is stored identically to a row of
          <S>*<C> column vectors with <R> components each, according to rule
          (4).

      (7) If the member is a row-major matrix with <C> columns and <R> rows,
          the matrix is stored identically to an array of <R> row vectors
          with <C> components each, according to rule (4).

      (8) If the member is an array of <S> row-major matrices with <C> columns
          and <R> rows, the matrix is stored identically to a row of <S>*<R>
          row vectors with <C> components each, according to rule (4).

      (9) If the member is a structure, the base alignment of the structure is
          <N>, where <N> is the largest base alignment value of any of its
          members, and rounded up to the base alignment of a vec4. The
          individual members of this sub-structure are then assigned offsets 
          by applying this set of rules recursively, where the base offset of
          the first member of the sub-structure is equal to the aligned offset
          of the structure. The structure may have padding at the end; the 
          base offset of the member following the sub-structure is rounded up
          to the next multiple of the base alignment of the structure.

      (10) If the member is an array of <S> structures, the <S> elements of
           the array are laid out in order, according to rule (9).

      layout(std140) uniform Example {

                      // Base types below consume 4 basic machine units
                      //
                      //       base   base  align
                      // rule  align  off.  off.  bytes used
                      // ----  ------ ----  ----  -----------------------
        float a;      //  1       4     0    0    0..3
        vec2 b;       //  2       8     4    8    8..15
        vec3 c;       //  3      16    16   16    16..27
        struct {      //  9      16    28   32    (align begin)
          int d;      //  1       4    32   32    32..35
          bvec2 e;    //  2       8    36   40    40..47
        } f;          //  9      16    48   48    (pad end)
        float g;      //  1       4    48   48    48..51
        float h[2];   //  4      16    52   64    64..67 (h[0])
                      //                    80    80..83 (h[1])
                      //  4      16    84   96    (pad end of h)
        mat2x3 i;     // 5/4     16    96   96    96..107 (i, column 0)
                      //                   112    112..123 (i, column 1)
                      // 5/4     16   124  128    (pad end of i)
        struct {      //  10     16   128  128    (align begin)
          uvec3 j;    //  3      16   128  128    128..139 (o[0].j)
          vec2 k;     //  2       8   140  144    144..151 (o[0].k)
          float l[2]; //  4      16   152  160    160..163 (o[0].l[0])
                      //                   176    176..179 (o[0].l[1])
                      //  4      16   180  192    (pad end of o[0].l)
          vec2 m;     //  2       8   192  192    192..199 (o[0].m)
          mat3 n[2];  // 6/4     16   200  208    208..219 (o[0].n[0], column 0)
                      //                   224    224..235 (o[0].n[0], column 1)
                      //                   240    240..251 (o[0].n[0], column 2)
                      //                   256    256..267 (o[0].n[1], column 0)
                      //                   272    272..283 (o[0].n[1], column 1)
                      //                   288    288..299 (o[0].n[1], column 2)
                      // 6/4     16   300  304    (pad end of o[0].n)
                      //  9      16   304  304    (pad end of o[0])
                      //  3      16   304  304    304..315 (o[1].j)
                      //  2       8   316  320    320..327 (o[1].k)
                      //  4      16   328  336    336..347 (o[1].l[0])
                      //                   352    352..355 (o[1].l[1])
                      //  4      16   356  368    (pad end of o[1].l)
                      //  2       8   368  368    368..375 (o[1].m)
                      // 6/4     16   376  384    384..395 (o[1].n[0], column 0)
                      //                   400    400..411 (o[1].n[0], column 1)
                      //                   416    416..427 (o[1].n[0], column 2)
                      //                   432    432..443 (o[1].n[1], column 0)
                      //                   448    448..459 (o[1].n[1], column 1)
                      //                   464    464..475 (o[1].n[1], column 2)
                      // 6/4     16   476  480    (pad end of o[1].n)
                      //  9      16   480  480    (pad end of o[1])
        } o[2];
      };

[soywiz]

Renamed packages from @ygdrasil-io :

• Package renamed #1441
• rename script applied #1467

[soywiz]

I have merged the separation of samplers, and changed all the code to use uniform blocks.
So now we have: attributes, varyings, uniforms inside uniform blocks and samplers.

[soywiz]

Even if it can improve a lot yet. I believe we are in a good shape already to be future-proof. All geometry is already immutable (though not using value classes yet since they are not available), and the AG API is decent enough for typical scenarios to be fast enough.

I'm going to fix bugs, mouse/touch events work as expected, and ensure the code-base use immutable geometry everywhere. And let's start the Beta & RC. And update all kprojects to the new versions + publish the store + update the intellij plugin.

[jobe-m]

I will take over updating korge-fleks kproject to korge 4.0. I was just waiting until 4.0 gets out from alpha state :)

[soywiz]

4.0.0-beta published. Now API is almost final. I'm going to update all kprojects, fix/add small pending stuff, and go for RC & release in the coming ~2 weeks.