possible bug with adjustment parameters
Posted: Fri Jan 04, 2013 5:00 pm
This:
produces this
So it looks like any saturation/brightness/alpha values in a transform parameter are being pinned to [0,1]. I suppose it shouldn't do this without prior knowledge of this attribute of the shape it is applied to. As the code shows, it does this whether or not it is a valid adjustment to the parent shape.
Hue seems OK.
I haven't checked two-value versions of these adjustments.
I haven't dug into the source code.
I'm using Version 3.0.4 (36) on Mac OS X.
Code: Select all
startshape START[b .5]
shape START{
recurse([s .95 b .1],CIRCLE)[]
recurse([s .95 b -.1],TRIANGLE)[x 1]
recurse([s .95 h -5 r 3 a .05],SQUARE)[x 2 b 1 sat 1 a -1]
recurse([s .95 h -5 r -5 a -.05],NGON(5))[x 3 b 1 sat 1]
A[y -1.1]
B[y -1.1 x 1]
C[y -1.1 x 2 b 1 sat 1 a -1]
D[y -1.1 x 3 b 1 sat 1]
}
shape A{CIRCLE[] A[s .95 b .1]}
shape B{TRIANGLE[] B[s .95 b -.1]}
shape C{SQUARE[] C[s .95 h -5 r 3 a .05]}
shape D{NGON(5)[] D[s .95 h -5 r -5 a -.05]}
shape recurse(adjustment change, shape thingie)
{
thingie[] // invoke thingie with parameters already bound
recurse(=) [transform change] // can be abbreviated as trans
}
path NGON(number n){
MOVETO(0,.5)
loop n [r (360/n)] LINETO(0,.5)
CLOSEPOLY()
}
Hue seems OK.
I haven't checked two-value versions of these adjustments.
I haven't dug into the source code.
I'm using Version 3.0.4 (36) on Mac OS X.