Syntax for defining input and output about pyshader HOT 10 CLOSED

... because it relies on a string format convention

Good point. It seems nice and simple, but it introduces new conventions to remember.

from pyshader.

I also like the 3-tuple, but the first component is just a limited set of choices (like the third component) so it is a little awkward that it's a string? How about:

    index: (INPUT, "VertexId", i32),
    outpos: (OUTPUT, "Position", vec4),
    outcolor: (OUTPUT, 0, vec3),

Just using constants or an enum? The options are then easy to discover with auto completing IDEs and REPLs, especially when scoped/namespaced properly

from pyshader.

Leaning towards the last option.

from pyshader.

I think this needs more time to sink in and refine. And I want to write a few more shaders (also a compute shader) before making a decision.

from pyshader.

Just adding a flavor for you to consider (haven't really got a clue about the internals at play here so please consider it just a brainfart)

@python2shader(inputs={"VertexId": i32}, outputs={"Position": vec4, "0": vec3})
def vertex_shader(inputs, outputs):
    positions = [vec2(+0.0, -0.5), vec2(+0.5, +0.5), vec2(-0.5, +0.7)]
    p = positions[inputs.VertexId]

    outputs.Position.xyzw = vec4(p, 0.0, 1.0)
    outputs.0.rgb = vec3(p, 0.5)

from pyshader.

I think I want the io definitions to be part of the function object, so putting it in the decorator might be a bit too far "up" :)

I put more examples above, basically flavors of using type annotations. I think I like the 2-tuple most; a normal type annotation tells "what the data is". We need to know "what the data is", and "where it comes from". We can fit the latter into a single string object relatively easily ...

from pyshader.

"Put definitions in the function signature - as object" looks most natural to me - the signature is very predictable Type(Key, DataType) :) love these new ideas!

I don't like this very much, because it relies on a string format convention rather than normal Python syntax:

    offset: ("input:SomeBuiltinIndex", i32),
    pos3dArray: ("buffer:0", Array(vec3)),
    avgArray: ("buffer:1", Array(f32)),

from pyshader.

Nice one, discoverability is indeed another plus for the "object-version", and using an enum brings that to the tuple-version. mmm ...

from pyshader.

Yeah or just predefined constants, like i32, vec4 etc are as well

from pyshader.

With #19 both the object-version and 3-tuple version are supported. We still need to decide on one (or e.g. a namedtuple) and refine it a bit.

from pyshader.