feat: WIP: extensible renderer

[dragoncoder047]

Is your feature request related to a problem? Please describe.

Already WIP by MF on the 3D branch but here so it can be discussed separately from 3D stuff although 3D is relevant here too.

• if we're going to add basic 3D support we need a way to control when to enable the z-buffer. It's off right now although I manually set it on and there's no z-fighting since everything is drawn with z=0 and 0 is exactly representable in floating point.

in terms of rendering components/primitives there are 2 things that need to happen:

1. the object need a source of vertices (e.g. the four corners of a quad, etc)
2. the object needs a texture

in the case of shape primitives (rect, circle, line, etc) the uv coordinates are all 1's to lie on the white-pixel. in the case of uvquad it's the entire texture, and in the case of sprite it's the subset quad of the pixels of the sprite frame

it would also be nice to add attributes to the existing renderer, for something like a normal map in nanopoison's lighting plugin (currently I have to either use uniforms, which are stupid slow, or monkeypatch the texture packer to put normal maps on a second texture in the exact same coordinates as the associated sprite, which is also not great). If I could just add fields to the attributes and have the vertex data buffers recompiled on draw, that would be pretty cool.

ref: #27

MF's Mesh works but it's a little janky and not optimal cause it has to change the vertex format and thus flush the batch every time it's drawn and assumes that the next thing drawn will be the usual kaplay format so it sets it back, but if the next thing is the same format it should be able to batch it with the previous mesh. It also stores the vertex data flattened so there's no way to add attributes after the mesh is constructed (e.g. to monkeypatch in normal map uv's).

Any more information?

We could go so far as to make everything based on drawMesh() and not drawRaw(). drawRaw() is pretty janky right now as well because it currently takes an Attributes object which still has partially-flattened buffers, and just zips them together.

MF proposed changing the stuff to take a single object with properties { x, y, u, v, r, g, b, a } and I particularly like that idea because you can just add new parameters to it such as z, nu, nv, etc. The Mesh would store a list of these objects, and drawMesh would flatten these based on the current vertex format which would store what fields to look for in the vertex for that attribute - what is now "size" would be implicitly defined as parts.length:

[
  { name: "a_pos", parts: ["x", "y"], fill: 0 },
  { name: "a_uv", parts: ["u", "v"], fill: 1 },
  { name: "a_color", parts: ["r", "g", "b", "a"], fill: 1 },
]