Привет, использую алгоритм, описанный древними в DEMO.DESIGN FAQ. bpp - 32, esi - массив 640x480x4, ecx: (640*460)*4 Код (Text): @@1: mov eax, [esi-4] mov edx, [esi+4] and eax, 0fcfcfcfch and edx, 0fcfcfcfch shr eax, 2 shr edx, 2 add eax, edx mov ebx, [esi-640*4] and ebx, 0fcfcfcfch mov edx, [esi+640*4] shr ebx, 2 and edx, 0fcfcfcfch shr edx, 2 add esi, 4 add eax, edx add eax, ebx sub ecx, 4 mov [esi-4], eax jne @@1 Дело в том, что этот алгоритм срезает цвета. Более честный алгоритм должен быть примерно такой: Код (Text): @1: xor eax,eax mov bl,[edi-4] add eax,ebx mov bl,[edi-640*4] add eax,ebx mov bl,[edi+640*4] add eax,ebx mov bl,[edi+4] add eax,ebx shr eax,2 mov [edi],al inc edi loop @1 Но естественно, что он адово тормозит. Интересует простой вопрос - можно ли как-то убыстрить второй вариант? Напрмер использую MMX/SSE расширения?
Можно попробовать использовать mmx, но тут всплывает распаковка/запаковка... Код (Text): mov esi,src;адрес исходного массива mov edi,dst;адрес массива назначения mov ecx,640*(480-2);для верхней и нижней строчек размытие не делаем add edi,640 add esi,640;пропускаем первую строку @1: ;[esi] - текущий пиксел punpcklbw mm0, [esi-4];теперь старшие байты 4-х слов регистра mm0 содержат цветовые ;компоненты соседнего левого пиксела psrlw mm0, 8;переводим их в младшие байты, т.е. теперь 4 слова mm0 содержат цветовые ;компоненты соседнего левого пиксела punpcklbw mm1, [esi+4];аналогично загоняем соседний правый в mm1 psrlw mm1, 8 paddw mm0, mm1;складываем покомпонентно, результат накапливаем в mm0 punpcklbw mm1, [esi+640*4];добавляем туда же верхний и нижний psrlw mm1, 8 paddw mm0, mm1 punpcklbw mm1, [esi-640*4] psrlw mm1, 8 paddw mm0, mm1 psrlw mm0, 2;покомпонентно делим на 4 packuswb mm0, mm0;теперь 4 младших байта mm0 содержат результирующий пиксел movd [edi], mm0;записываем результат add esi,4 add edi,4 loop @1 Можно, конечно, один массив пикселей использовать как исходный и результирующий одновременно, но это не совсем корректно.
Tronix Motion Blur это размытие в движение когда предыдущие и последующие кадры размываются. Тут просто Blur. Правда странная разновидность. С перекосом. Да [esi] не использует. Видимо за скорость боролись. Насколько сильно тормозит и насколько быстро надо? Надеюсь, ты не с видео памятью работаешь?
Ravager Спасибо, попробую разобраться... А вы не могли бы пару-тройку комментов к коду привести, был бы признателен. С MMX я просто не знаком, понять бы просто логику основную.. Ну или буду пробовать читать маны )) Спасибо еще раз. Pavia Эээ, да, наверное неправильно выразился. Это простое размытие по четырем окружающим точкам, ну вы и сами это уже поняли. Ну на современных компьютерах конечно не тормозит, а вот на процессорах уровня Celeron 433Mhz подтормаживает. Нет, работаю конечно не с видеопамятью напрямую, просто с буфером в памяти работаю. Чтобы не быть голословным прикреплю сейчас мою программку (win32) - вращает тор из точек и размывает его. Blur 1 - это первый алгоритм, Blur 2 - это второй алгоритм. В заголовке окна выводится количество FPS...
Tronix Ну вот, подредактировал немного. Дожно быть всё же побыстрее, чем побайтовое усреднение. Неужели 2 срезанных бита дают столь отчётливо видимое различие? Потрясающе.
Ravager "Всего" 2 бита увеличивают глубину цвета в 4 раза ) это всё равно что сравнивать 10 и 1000 где "всего-то два нуля" приписалось )
Y_Mur Тем не менее, разницу между изображением с глубиной цвета, к примеру, в 16 и 24 бит заметить довольно непросто.
Ravager О, спасибо, теперь все понятно. Буду пробовать. А действительно, этот алгоритм (первый который срезает биты), наверное для 24-битной палитры был задуман, там разница не будет так отчетливо видна.
Да, с MMX стало работать побыстрее. Демку с тремя алгоритмами прикладываю. Единственное пока нет проверки на cpuid, поэтому если вдруг кто-то решит затестить на чем-то вроде 486 с галкой на Blur MMX, получит соответственно ексепшен.
