On 11/14/23 14:36, Bald Eagle wrote:
> With regard to the current shader, I've run into quite a number of stumbling
> blocks that highlight the deeply ingrained problems and limitations of the
> function parser.  I'm not saying that Thorsten didn't do a good job - it's just
> that what we have isn't really adequate to the tasks I would (reasonably) like
> to accomplish, and isn't conducive to moving forward toward 4.0.
> 
> When evaluating a pattern, things need to be coded in a certain "static" way.
> What one might do in a macro - declaring variables to store intermediate
> calculation results - isn't possible with functions.
> Vector components are scalar values, but using Vector.x in a function argument
> isn't allowed.
> Fundamental computer graphics functions like inbuilt vlength () doesn't work.
> Dot product?  Cross product?  c'mon.
> We have "matrix" transforms, but we don't really have actual matrices that do
> matrixy things.  At the very least we ought to have a projection matrix, simple
> matrix multiplication, transpose, diagonal elements of square matrix, and a
> determinant function.

Jerome's response reminded your post was on my - respond to it 
eventually lists (along with your select() bug report).

I agree with a lot of what you wrote and to the degree I'm able to push 
yuqk in some of those directions - near term - and within the confines 
of the current VM(a) I will (or perhaps already have).

I've implemented an f_length() inbuilt function for example.

What I've not gotten around to since adding the 3 x 21 bit float 
encoding / decode inbuilt functions is a set of inbuilt dot, cross, 
length 21 bit inbuilt functions. I'll bump those up my to do list. It 
would enable certain kinds of vector play withing the confines of the 
current VM and 'function compiler'. The 21 bit float accuracy is plenty 
of accuracy for most color work, for example - though not of course for 
other work.

(a) - The current VM has limits sure, but I've also found it to be solid 
code. I'm comfortable building on top of it with now a large amount of 
work which didn't require some completely new VM implementation.

Aside: A couple years ago I spend some time looking into and thinking 
about alternate 'simple' VMs (of the C++ template driven kind which has 
been used to enable old game collections on VMs emulating ancient 
hardware) along with some sort of accompanying assembler. The latter 
would solve solve issues with respect to lack of user accessible 
intermediate storage, for example, with minimal perturbation of the 
current parser and SDL. Thought was the SDL parser bit would be very 
roughly #declare Fn = fasm { ... }. I also had the thought there is no 
real reason we could not have multiple VM implementations going at the 
same time too - perhaps some for very specialized work / existing work 
based upon certain existing alternate architectures. Yes, now thinking 
aloud / dreaming a bit. :-)

Bill P.

Post a reply to this message