On 30.03.2012 19:59, f...@g...pl wrote:
> <f...@g...pl> napisał(a):
>
>> 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 -
>>
>> tutaj sie transformuje tylko narozne punkty i liczy proste dx dy ,
>>
>> chyba bedzie dzialac bo
>>
>> float dxdx = (Bx-Ax)/200.0,
>> dydx = (By-Ay)/200.0,
>> dxdy = (Cx-Ax)/200.0,
>> dydy = (Cy-Ay)/200.0;
>>
>> long offs = 0;
>>
>> // loop for all lines
>>
>> for (int j=0; j<200; j++)
>> {
>> Cx = Ax;
>> Cy = Ay;
>> // for each pixel
>> for (int i=0; i<200; i++)
>> {
>>
>> unsigned color = sprites_buf_[(int)Cy][(int)Cx];
>>
>> int adr = ((50+j)*CLIENT_X+i+50);
>>
>> ((unsigned*)pBits)[adr] = color;
>>
>> // interpolate to get next texel in texture space
>> Cx += dxdx;
>> Cy += dydx;
>> }
>> // interpolate to get start of next line in texture space
>> Ax += dxdy;
>> Ay += dydy;
>> }
>> }
>>
>> 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
>>
>>
>>
> czyli (?) -
>
> musze przepuscic (logiczne) rogi
> sprite'a przez oryginalna (podwojna)
> transformacje (na sinusach) -
Transformację robisz RAZ. Potem robisz mnożenie przez współczynniki.
>
> - bede miec wierzcholki A B C w
> koordynatach fiz - sprawdzic czy
> to lezy w zakresie widzialnym -
Dlatego liczy się w 2 stronę - iterujesz tylko po zakresie widzialnym i
uwzględniasz co zrobić jak wychodzisz poza teksturę - zawinięcie,
przycięcie, odbicie.


--
Pozdrawiam
Michoo