I have to say, the as2 documentation _never_ made any sense to me, because they
don't ever tell you what the actual formula is for computing the new value.
What the heck does a negative percent mean? The as3 interface seems much more
sensible, more like a compositing operation.
On 2010-06-23, at 14:27, André Bargull wrote:
> Just for clarification what these 'a' and 'b' values are all about:
>
> ActionScript2 docs:
>>
>> Sets color transform information for a Color object. The
>> |/colorTransformObject/| parameter is a generic object that you create from
>> the |new Object| constructor. It has parameters specifying the percentage
>> and offset values for the red, green, blue, and alpha (transparency)
>> components of a color, entered in the format 0xRRGGBBAA.
>>
>> The parameters for a color transform object correspond to the settings in
>> the Advanced Effect dialog box and are defined as follows:
>>
>> * |/ra/| is the percentage for the red component (-100 to 100).
>> * |/rb/| is the offset for the red component (-255 to 255).
>> * |/ga/| is the percentage for the green component (-100 to 100).
>> * |/gb/| is the offset for the green component (-255 to 255).
>> * |/ba/| is the percentage for the blue component (-100 to 100).
>> * |/bb/| is the offset for the blue component (-255 to 255).
>> * |/aa/| is the percentage for alpha (-100 to 100).
>> * |/ab/| is the offset for alpha (-255 to 255).
>>
>
> ActionScript3 docs:
>> The ColorTransform class lets you adjust the color values in a display
>> object. The color adjustment or /color transformation/ can be applied to all
>> four channels: red, green, blue, and alpha transparency.
>>
>> When a ColorTransform object is applied to a display object, a new value for
>> each color channel is calculated like this:
>>
>> * New red value = (old red value * |redMultiplier| ) + |redOffset|
>> * New green value = (old green value * |greenMultiplier| ) +
>> |greenOffset|
>> * New blue value = (old blue value * |blueMultiplier| ) +
>> |blueOffset|
>> * New alpha value = (old alpha value * |alphaMultiplier| ) +
>> |alphaOffset|
>>
>> If any of the color channel values is greater than 255 after the
>> calculation, it is set to 255. If it is less than 0, it is set to 0.
>>
>
>
>
>> + obj.ra = parseInt(color.substring(1, 3), 16),
>> + obj.ga = parseInt(color.substring(3, 5), 16),
>> + obj.ba = parseInt(color.substring(5, 7), 16)
>
> parseInt(color.substring(n, m), 16) is in range [0, 255], whereas the
> multiplier value is in range [-100, 100] (as2) resp. [0, 100] (as3) [1,2].
> That change is just wrong.
>
> Why is {set,get}ColorTransform() deprecated at all? "tintcolor" does seem to
> be a fully compatible replacement. "tintcolor" just sets the offset, it's no
> longer possible to affect the multiplier value. (LPP-9124)
>
>
>
> [1] the multiplier range is different between as2 and as3 because we're using
> the deprecated Color class instead of ColorTransform in as2.
> [2] the actual range for ColorTransform is [0, 1] in as3, but see
> LzSprite#setColorTransform
>
>
> On 6/22/2010 1:08 PM, P T Withington wrote:
>> Not approved yet.
>>
>> Issues:
>>
>> 1) I don't follow what you are trying to do in LzUtils. It might be more
>> straightforward to say:
>>
>>
>>> var color =
>>> ((parts[0]& 255)<< 16) +
>>> ((parts[1]& 255)<< 8) +
>>> (parts[2]& 255);
>>>
>> `&` being a bit operator will force the strings to be 32-bit ints, and `255`
>> will force them to be in range, solving 2 problems at once.
>>
>> 2) I don't understand your color math. setColorTransform implies that a
>> tint color is made solely of the 'b' components of a transform, yet
>> $lzc$set_tintcolor uses a transform that is made solely of 'a' components.
>> In converting the basecomponent tint code from using a transform to a tint,
>> you've used yet a third computation (via hsv). Shouldn't these all be the
>> same conversion? Shouldn't they be invertible?
>>
>> 3) It seems to me we ought to have a test that ensures that
>> $lzc$set_tintcolor computes a transform matrix, which if I hand to
>> setColorTransform computes the original tintcolor. I don't believe the code
>> in your change does that.
>>
>> 4) If the basecomponent code is really setting a tint, why is their so much
>> math required to compute the color to set as the tint? I'd like to see
>> another test that verifies the old and new code result in the same sprite
>> transform for a range of inputs. I can't deduce from inspection that this
>> is going to be the case.
>>
>> On 2010-06-21, at 19:36, Max Carlson wrote:
>>
>>
>>> Change 20100621-maxcarlson-i by maxcarl...@friendly on 2010-06-21 16:31:42
>>> PDT
>>> in /Users/maxcarlson/openlaszlo/trunk-clean
>>> for http://svn.openlaszlo.org/openlaszlo/trunk
>>>
>>> Summary: Fix warnings with basecomponent tinting
>>>
>>> Bugs Fixed: LPP-9132 - Regression:
>>> examples/animation/animation.lzx?lzr=swf8&debug=true failing to start up
>>>
>>> Technical Reviewer: ptw
>>> QA Reviewer: hminsky, mdemmon
>>>
>>> Details: LzUtils - Ensure LzColorUtils.fromrgb() returns integers when no
>>> alpha component is supplied.
>>>
>>> LaszloView - Update docs, update deprecation warning to not include 'this'
>>> which caused swf8 to fail to start up. Updatei tintcolor setter
>>> implementation to actually tint.
>>>
>>> basecomponent - Use LzView.tintcolor instead of setColorTransform().
>>>
>>> Tests: examples/animation/animation.lzx runs in swf8 debug mode, runs as
>>> before in swf10 also - but without warnings.
>>>
>>> Files:
>>> M WEB-INF/lps/lfc/services/LzUtils.lzs
>>> M WEB-INF/lps/lfc/views/LaszloView.lzs
>>> M lps/components/base/basecomponent.lzx
>>>
>>> Changeset:
>>> http://svn.openlaszlo.org/openlaszlo/patches/20100621-maxcarlson-i.tar
>>>
>>
>>
>>
