William F Pokorny <ano### [at] anonymousorg> wrote:

> Perhaps such a mechanism could be extended to vector handling too as a
> way to pass (return?) vectors directly. Large sets of origin and
> direction vectors for use in cameras or whatever???

I was thinking about this, and we already have the internal pigment patterns
defined by functions.   You input a color_map, and presumably output a color
vector (rgbft?), but then have to choose a dot notation scalar component to pass
the result into another normal function. .r .g. b. f. t. .gray .hf

So maybe most of the mechanism is already lurking in there somewhere.

(It would also be SO much nicer to not need the (x,y,z) for plain-vanilla
functions - have it be optional/assumed.   It would save a lot of screen space
and redundant typing.)

Again, I haven't looked at the code, but if .gray and .hf are computed
internally, presumably without much extra code, then if a function can
"internally" output an rgb vector that can be operated upon to get a scalar
grayscale value, why then can we not say that .temp = .x, .x = .y, .y =. z. and
..z = .temp in order to swizzle on the fly in the compiled code?

Really just curious.  I conceived how to do it in SDL, but at that point I'm
probably using for something that may already be slow...  ;)

Post a reply to this message