<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) -

- bede miec wierzcholki A B C w
koordynatach fiz - sprawdzic czy
to lezy w zakresie widzialnym -
jesli tak policzyc dxdx dydx dydx
dydy



nie do konca rozumiem jedna
rzecz - powiedzmy ze przepuszcze
logiczne rogi sprite'a przez swoja
pierwotna zlozona transformacje -
dostane koordynaty fizyczne tych
rogow

dxdx, dydx, dxdy, dydy
rozumiem jako

dx(logiczne)/dx(fizyczne)
dy(logiczne)/dx(fizyczne)
dx(logiczne)/dy(fizyczne)
dy(logiczne)/dy(fizyczne)

mimo ze sama transformacja jest
skomplikowana (uwzglednia dwa
obroty i translacje) to samo
dxdx dydx dxdy dydy mozna obliczyc
z prostego wzorku

dxdx = (Bx(log)-Ax(log))/(Bx(fiz)-Ax(fiz)); (?)

pewnie dzieki temu ze ta transformacja jest liniowa

trzeba wtedy w podwojnym for()
przeiterowac blok po j,i
i siegac do tekstury przy pomocy
logicznych dxdx dydx dxdy dydy

(nie wiem czy ze rozumowanie
do tego momentu jest poprawne
bo sam kawalek kodu tego rotozooma
to nie calkiem pokazuje)

- jak wtedy ustalic zakresy j,i
- mozna ew zaczac od fizycznego
srodka i iteroeac od minus polowy
przekatnej do plus polowy
przekatnej na obu indeksach
- (nie wiem czy tamten kawalek
kodu jest uproszczony bo chyba tak
bo tam nic o tym nie ma, jest tylko
iterowanie po bloku rozmiaru
sprita) czy ew jest jakas sztuczka
ktora dobralaby ten obszar dla forów
automatycznie?


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/