W dniu 2012-03-30 19:10, f...@g...pl pisze:
> bartekltg<b...@g...com> napisał(a):
>
>> W dniu 2012-03-30 18:27, f...@g...pl pisze:
>>
>>>>
>>> nie tak samo szybkie tylko tak samo wolne (zobacz jak to dziala pod
>>
>> No widzisz, pozbędziesz się artefaktów a szybkość (którą jak
>> naprawić też mówiłem) pozostanie osobnym problemem.
>>
>>> linkiem wyzej) - pod drugim linikiem jest dyskusja nt czegos co
>>> w demoscenie nazywa sie rotozoomer - bede musiec sie troche
>>> pomeczyc i zobaczyc czy uda mi sie to zmusic do dzialania
>>
>> Zerknąłem. Robią tak jak mówiłem:
>>
>> "
>> ARGB_Img1[ti] = ARGB_Img0[(y0>>10)*ImW+(x0>>10)];
>> "
>>
>> ti to "iterator" jadący po obrazku odcelowym.
>> Obliczane wspolrzędny y0 i x0 na obrazie-źródle
>> uaktualniane są przez dodawanie i trzymane jako stały przecinek.
>>
>>
>
> to albo niezbyt wyraznie albo jednak nie o tym, bo to nie
> jest po prostu transformacja na cos sin /-sin cos tylko w druga
> strone -

Transformacją odwrotną do obrotu jest obrót w drugą stronę.
Sin -> -sin,
cos-> cos


> tutaj sie transformuje tylko narozne punkty i liczy proste dx dy ,

Bo to transformacja liniowa. A taki zapis ładnie tworzy nam
wszelkie transformacje liniowe, nie tylko obroty.



> zaczyna mi dzialac - co prawda tylko na floatach a w oryginale jest
> na intach (na intach nie chialo zadzialac a nie petrzylem wiecej)
> i bede sie musiec nabiedzic nad tym ze ja mam podwojna
> translacje-rotacje a nie tylko pojedyncza (z lekka mnie glowa
> rozbolala wiec moze jutro) - ale chyba powinno dzialac i raczej
> powinno byc zbacznie szybciej przez te dx/dy

_Zrozum_ najpierw ten algorytm, albo prostrzą wersję którą
opisywałem. Potem pisz. Nie rozumiejąc algorytmu nie masz
po co go pisać, namęczysz się tylko.

pzdr
bartekltg