W dniu 2012-03-30 17:33, f...@g...pl pisze:
> bartekltg<b...@g...com> napisał(a):
>
>> W dniu 2012-03-30 10:45, fir kenobi pisze:
>>> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
>>> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)
>>>
>>> potrzebuje odrysowywac sprite'a na ekranie z rotacją i translacja,
>>>
>>> mozna to zrobic przez jechanie w petli po calym pixelbuforze sprite'a
>>> i poddawaniu kazdego pixele transformacji w stylu
>>>
>>> cos sin
>>> -sin cos
>>>
>>> (i nawet nie jest to takie wolne) ale przy obracaniu powstają artefakty
>>> w postaci deseni czarnych kropek zaleznych od kata, no i moze ew jest
>>> jakas znacznie szybsza metoda - (przydalby sie jakis sprytny algorytm na
>>
>>
>> Bo robi sie to odwrotnie.
>>
> kojarze ze mozna robic odwrotnie - ale odwrotnie tez bedzie niedobrze
> - transformacje tysiecy punktow oddzielnie- powinien byc jakis szybki

Głupoty opowiadasz. Obie wersje są tak samo szybkie. W obu wersjach,
jeśli masz obrót bez skalowania iterujesz po podobnej liczbie pikseli.

Mówiłem, nie transformuj ich oddzielnie. Transformacje wyliczasz raz.
potem robisz tylko dodawania i ewentualnie średnie.
Nawet sin i cos mozesz nie trzymać jako zmiennoprzecinkowe,
ale jako stały przecinek i robić odpowiednie przesunięcia bitów.

Robiąc 'od dupy strony' będziesz miał czarne (czy jakiego tam koloru
masz tło) plamy i nic na to niskim nakładem nie poradzisz:)

pzdr
bartekltg

do góry

bartekltg <b...@g...com> napisał(a):

> W dniu 2012-03-30 17:33, f...@g...pl pisze:
> > bartekltg<b...@g...com> napisał(a):
> >
> >> W dniu 2012-03-30 10:45, fir kenobi pisze:
> >>> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
> >>> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)
> >>>
> >>> potrzebuje odrysowywac sprite'a na ekranie z rotacją i translacja,
> >>>
> >>> mozna to zrobic przez jechanie w petli po calym pixelbuforze sprite'a
> >>> i poddawaniu kazdego pixele transformacji w stylu
> >>>
> >>> cos sin
> >>> -sin cos
> >>>
> >>> (i nawet nie jest to takie wolne) ale przy obracaniu powstają
artefakty
> >>> w postaci deseni czarnych kropek zaleznych od kata, no i moze ew jest
> >>> jakas znacznie szybsza metoda - (przydalby sie jakis sprytny algorytm na
> >>
> >>
> >> Bo robi sie to odwrotnie.
> >>
> > kojarze ze mozna robic odwrotnie - ale odwrotnie tez bedzie niedobrze
> > - transformacje tysiecy punktow oddzielnie- powinien byc jakis szybki
>
> Głupoty opowiadasz. Obie wersje są tak samo szybkie. W obu wersjach,
> jeśli masz obrót bez skalowania iterujesz po podobnej liczbie pikseli.
>
> Mówiłem, nie transformuj ich oddzielnie. Transformacje wyliczasz raz.
> potem robisz tylko dodawania i ewentualnie średnie.
> Nawet sin i cos mozesz nie trzymać jako zmiennoprzecinkowe,
> ale jako stały przecinek i robić odpowiednie przesunięcia bitów.
>
> Robiąc 'od dupy strony' będziesz miał czarne (czy jakiego tam koloru
> masz tło) plamy i nic na to niskim nakładem nie poradzisz:)
>
nie tak samo szybkie tylko tak samo wolne (zobacz jak to dziala pod
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


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

do góry

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.


pzdr
bartekltg

do góry

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



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

do góry

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

do góry

On 30.03.2012 18:37, bartekltg wrote:
> 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.
Swoją drogą aż dziwne, że nie robią tego na SSE.


--
Pozdrawiam
Michoo

do góry

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

do góry

niestety po wyrugowaniu transformacji dla kazdego pixela,
czyli przepisaniu petli rysujacej mw z 1 na 2




///////////////////////1

for( int j=0; j<sprite_height; j++)
{
for(int i=0; i<sprite_width; i++)
{

unsigned v = sprites_buf_[sprite_bitmap_posy+j]
[sprite_bitmap_posx+i];




x= x - (transform_x + transform_center_point_x);
y= y - (transform_y + transform_center_point_y);

float x_prim = transform_alfa_cos * x + transform_alfa_sin * y;
float y_prim = -transform_alfa_sin * x + transform_alfa_cos * y;

x = x_prim + transform_center_point_x;
y = y_prim + transform_center_point_y;

x = x - sprite_centre_x;
y = y - sprite_centre_y;

x_prim = sprite_alfa_cos * x + sprite_alfa_sin * y;
y_prim = -sprite_alfa_sin * x + sprite_alfa_cos * y;

x = x_prim + sprite_centre_x;
y = y_prim + sprite_centre_y;


int yc = CLIENT_Y-y;

if(!pBits) return;

if(yc<0) return;
if(yc>=CLIENT_Y) return;
if(x<0) return;
if(x>=CLIENT_X) return;
int adr = (yc*CLIENT_X+x);
((unsigned*)pBits)[adr] = color;

}

}




//////////////////////2



for(int j=0; j<sprite_height; j++)
{

for(int i=0; i<sprite_width; i++)
{

unsigned v = sprites_buf_[sprite_bitmap_posy+j]
[sprite_bitmap_posx+i];


int yc = CLIENT_Y-y;

if(!pBits) return;

if(yc<0) return;
if(yc>=CLIENT_Y) return;
if(x<0) return;
if(x>=CLIENT_X) return;
int adr = (yc*CLIENT_X+x);
((unsigned*)pBits)[adr] = color;


x+=dxdx;
y+=dydx;

}

x -= (xBfiz-xAfiz);
y -= (yBfiz-yAfiz);

x += dxdy;
y += dydy;


}

///////////////
program przyspieszyl ledwie o jakies 25-30% :-(
nie rozumiem tego bo w wewnetrzenej petli masa dodawan i mnozen
zamienila sie na dwa dodawania :-/ - cos tu jest nie tak






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

do góry

<f...@g...pl> napisał(a):
> program przyspieszyl ledwie o jakies 25-30% :-(
> nie rozumiem tego bo w wewnetrzenej petli masa dodawan i mnozen
> zamienila sie na dwa dodawania :-/ - cos tu jest nie tak

A jak szybko działają z jakiś bibliotek? Może masz już w pobliżu optimum?
Pozdrawiam


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

do góry

<m...@g...pl> napisał(a):

> <f...@g...pl> napisał(a):
> > program przyspieszyl ledwie o jakies 25-30% :-(
> > nie rozumiem tego bo w wewnetrzenej petli masa dodawan i mnozen
> > zamienila sie na dwa dodawania :-/ - cos tu jest nie tak
>
> A jak szybko działają z jakiś bibliotek? Może masz już w pobliżu optimum?
> Pozdrawiam
>

po przerobieniu kilku centralnych floatow na inty (<<20 >>20)
przyspieszylo w koncu i to az 8 razy

for(int j=0; j<sprite_height; j++)
{
for(int i=0; i<sprite_width; i++)
{
unsigned v = sprites_buf_[sprite_bitmap_posy+j]
[sprite_bitmap_posx+i];

if(v==0)
{

}
else
{
SetPixelInDibInt(x>>20,y>>20,v);//v);
}

x+=dxdx_;
y+=dydx_;


}
x -= step_back_x;
y -= step_back_y;

x += dxdy_;
y += dydy_;
}




dl.dropbox.com/u/42887985/rotowanie%20bitmap.zip

(trzeba rozpakowac do folderu, przy trzymaniu spacji dziala stara
wersja u mnie jest ok 7 ms na nowej okolo 40 ms na starej)

tnx za linka - teraz szybkosc jest uwazam calkiem przyzwoita i
nawet wystarczajaca, nie wiem jak biblioteki i nie moge porownac
bo nie uzywam, ciekawie by bylo sie dowiedziec ale ktos
inny musialby sprawdzic, jest w kazdym razie ok (sa artefakty
bo to ta sama metoda tylko z dx/dy i fixedpointami (a nie
odwrocona) - na razie tak zostawie, kiedys ew poprawie





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

do góry