Цитата:
Сообщение от Волгоградец
Возможно дело с округлением альфы. Т.е. с цветами флэш нормально работает - а вот с прозрачностью - не очень.
|
Я тоже склонен считать, что дело в округлениях. Но, возможно, не из-за самой альфы, а из-за того, как НА САМОМ ДЕЛЕ храниться/записывается/считывается цвет в модели ARGB.
Цитата:
Сообщение от Волгоградец
Вот что выдает трейс при разных значениях цвета:
 Код:
var myBitmapData:BitmapData = new BitmapData(300, 200, true, 0x700100FF);
trace("getPixel = 0x"+myBitmapData.getPixel(10,10).toString(16));//0xff
|
Ну как раз прозрачность тут считается правильно:

Код:
trace("getPixel32>> = 0x"+(myBitmapData.getPixel32(10,10)>>24).toString(16)+(myBitmapData.getPixel32(10,10) & 0xFFFFFF).toString(16)) // 0x70ff
// т.е. на самом деле 0x700000ff
А ошибка только в красном канале: вместо 0х01 посчитано 0х00
Цитата:
Сообщение от Волгоградец
 Код:
0x990400FF
trace("getPixel = 0x"+myBitmapData.getPixel(10,10).toString(16));//0x300ff
|
Вот тут уже ошибка и в красном канале и в прозрачности:

Код:
//0x300ff т.е. на самом деле 0x0300ff
//getPixel32>> = 0x-67300ff
Итак getPixel опять ошибся на единицу в красном канале, а вот getPixel32 круто наврал...
Цитата:
Сообщение от Волгоградец
 Код:
0xFF0400FF
trace("getPixel = 0x"+myBitmapData.getPixel(10,10).toString(16));//0x400ff
|
Тут тоже забавно:

Код:
getPixel = 0x400ff т.е. на самом деле 0x0400ff - ошибки нет
getPixel32>> = 0x-1400ff т.е. на самом деле 0x-10400ff - ошибка только в альфа канале
Надо помнить, что мы трассируем через toString(16), поэтому при значении альфа канала более 0x7F toString(16) глючит (см. выше).
Хотя и непонятно почему - мы же проверили побитовый сдвиг вправо?
Но тождество налицо - до значения 0x7F определяется верно, более - ошибка.
Цитата:
|
Сообщение от Alex_beginner
Ну, я думаю, проблема здесь в конфликте попиксельного смешивания прозрачности цвета (параметр transparent) и альфа-составляющей значений маски и искомого цвета.
Грубо говоря, установите, параметр transparent в false, и данный пример заработает
|
Да, я писал, что это только для прозрачной битмапы такие глюки.
Цитата:
|
Сообщение от Alex_beginner
т.е.:
 Код:
myBitmapData = new BitmapData(300, 200, false, 0x705500FF);
Я, не совсем понимаю, зачем использовать transparent==true и при этом еще манипулировать альфа-каналом в кокретных используемых значениях. Практичнского значения это не имеет.
Используйте, лучше transparent==false и значения альфа-канала.
|
Не понял насчет transparent==false. Тогда же битмапа непрозрачная будет и параметр
A модели ARGB вообще роли не играет (как и метод getPixel32 теряет свой смысл).
А ведь битмапа с прозрачностью - наиболее востребованная, разве нет?
add:
Ступил с трейсом на getPixel32, там надо было побитовый сдвиг без знака делать, тогда toString(16) правильный альфа канал показывает ВСЕГДА!

Код:
trace("getPixel32>> = 0x"+(myBitmapData.getPixel32(10,10)>>>24).toString(16)+(myBitmapData.getPixel32(10,10) & 0xFFFFFF).toString(16))
add2:
вроде нашел причину
http://flasher.ru/forum/showpost.php...25&postcount=3
ПУстячок, а приятно, что я верно предположил, что все дело в том, как НА САМОМ ДЕЛЕ ХРАНИТЬСЯ цвет в модели ARGB.