eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingreczne rotowanie bitmap
Ilość wypowiedzi w tym wątku: 36

  • 11. Data: 2012-03-30 18:20:16
    Temat: Re: reczne rotowanie bitmap
    Od: bartekltg <b...@g...com>

    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




  • 12. Data: 2012-03-30 18:27:54
    Temat: Re: reczne rotowanie bitmap
    Od: " " <f...@g...pl>

    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/


  • 13. Data: 2012-03-30 18:37:02
    Temat: Re: reczne rotowanie bitmap
    Od: bartekltg <b...@g...com>

    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


  • 14. Data: 2012-03-30 19:10:36
    Temat: Re: reczne rotowanie bitmap
    Od: " " <f...@g...pl>

    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/


  • 15. Data: 2012-03-30 19:59:34
    Temat: Re: reczne rotowanie bitmap
    Od: " " <f...@g...pl>

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


  • 16. Data: 2012-03-30 21:23:33
    Temat: Re: reczne rotowanie bitmap
    Od: Michoo <m...@v...pl>

    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


  • 17. Data: 2012-03-30 21:26:16
    Temat: Re: reczne rotowanie bitmap
    Od: Michoo <m...@v...pl>

    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


  • 18. Data: 2012-03-31 01:12:07
    Temat: Re: reczne rotowanie bitmap
    Od: " " <f...@g...pl>

    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/


  • 19. Data: 2012-03-31 08:25:26
    Temat: Re: reczne rotowanie bitmap
    Od: " " <m...@g...pl>

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


  • 20. Data: 2012-03-31 09:33:53
    Temat: Re: reczne rotowanie bitmap
    Od: " " <f...@g...pl>

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

strony : 1 . [ 2 ] . 3 . 4


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: