eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingreczne rotowanie bitmap › Re: reczne rotowanie bitmap
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!wsisiz.edu.pl!newsfeed2.atman.pl!newsfe
    ed.atman.pl!goblin2!goblin3!goblin.stu.neva.ru!de-l.enfer-du-nord.net!feeder1.e
    nfer-du-nord.net!feeder2.enfer-du-nord.net!tudelft.nl!txtfeed1.tudelft.nl!multi
    kabel.net!newsfeed20.multikabel.net!news.glorb.com!border3.nntp.dca.giganews.co
    m!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.
    giganews.com!nntp.giganews.com!npeer01.iad.highwinds-media.com!news.highwinds-m
    edia.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.goog
    legroups.com!not-for-mail
    From: Adam Klobukowski <a...@g...com>
    Newsgroups: pl.comp.programming
    Subject: Re: reczne rotowanie bitmap
    Date: Fri, 30 Mar 2012 06:30:31 -0700 (PDT)
    Organization: http://groups.google.com
    Lines: 98
    Message-ID: <28126835.1452.1333114231971.JavaMail.geo-discussion-forums@vbai14>
    References: <jl3rs6$kbq$1@inews.gazeta.pl>
    NNTP-Posting-Host: 89.74.53.149
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: quoted-printable
    X-Trace: posting.google.com 1333114632 3154 127.0.0.1 (30 Mar 2012 13:37:12 GMT)
    X-Complaints-To: g...@g...com
    NNTP-Posting-Date: Fri, 30 Mar 2012 13:37:12 +0000 (UTC)
    In-Reply-To: <jl3rs6$kbq$1@inews.gazeta.pl>
    Complaints-To: g...@g...com
    Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=89.74.53.149;
    posting-account=mvBzhgoAAADiziO82aLj4VEpjexQv3Cn
    User-Agent: G2/1.0
    X-Received-Bytes: 4263
    Xref: news-archive.icm.edu.pl pl.comp.programming:196568
    [ ukryj nagłówki ]

    On Friday, 30 March 2012 10:45:58 UTC+2, fir kenobi wrote:
    > 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
    > podobienstwo bressenhama, moze jest jakas metoda nie transformowania
    > kazdego pixela z osobna tylko wykorzystania danych z malego pixelbufora
    > by wyrenderowac obroconego sprite'a szybciej jakby hurtem)
    >
    > tak naprawde transformacj jakiej uzywam by przetransformowac kazdy
    > pixel jest troche bardziej zlozona bo chce miec mozliwosc rysowania
    > spriteow jakby w postaci wirtualnej na wielkim 'logicznym' wirtualnym
    > ekranie-mapie, np
    >
    > DrawSprite(/*x*/10000,/*y*/1500,/*angle*/33);
    > DrawSprite(/*x*/8000,/*y*/-150,/*angle*/73);
    >
    > i te duze wirtualne wspolrzedne spritow sa pozniej transformowane
    > przy pomocy wspolrzednych okna obrazu na ekran, wiekszosc oczywiscie
    > wypada ale reszta jest jeszcze obracana o kat angle i rysowana -
    >
    > kod roboczy - na brudno
    >
    >
    > inline transformByXYA(float *x, float *y)
    > {
    > (*x)=(*x)-(transform_x+transformation_center_point_x
    );
    > (*y)=(*y)-(transform_y+transformation_center_point_y
    );
    >
    > float xprim= transform_alfa_cos*float(*x)+transform_alfa_sin*floa
    t(*y);
    > float yprim=-transform_alfa_sin*float(*x)+transform_alfa_c
    os*float(*y);
    >
    > (*x)=xprim+(transformation_center_point_x);
    > (*y)=yprim+(transformation_center_point_y);
    >
    > }
    >
    > inline void SetPixelInDib(float x, float y, unsigned color)
    > {
    > if(useTransform)
    > {
    > transformByXYA(&x,&y);
    >
    > //////////
    >
    > float xx = x - sprite_centre_x;
    > float yy = y - sprite_centre_y;
    >
    > float xxprim = sprite_alfa_cos*float(xx)+sprite_alfa_sin*float(yy);
    > float yyprim = -sprite_alfa_sin*float(xx)+sprite_alfa_cos*float(yy)
    ;
    >
    > x = xxprim + sprite_centre_x;
    > y = yyprim + 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;
    >
    > }
    >
    > jak to poprawic ? (zmiana calego algorytmu na taki
    > ktory nie transformowalby kazdego pixela oddzielnie
    > bylaby wazna, ale przepisanie chocby tego co wyzej
    > na szybsza forme tez by bylo ciekawe)

    Najlepiej zacząć od 'drugiej strony'. Czyli ba podstawie pikseli obróconej bitmapy,
    wyliczać który piksel oryginalnej jest jego odpowiednikiem.

    AdamK

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj

Najnowsze wątki z tej grupy


Najnowsze wątki

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: