fir kenobi <f...@g...pl> napisał(a):

> 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.
Czy jest szybsza metoda to nie wiem. Ale artefaktów można pozbyć się przez
potraktowanie każdego pixela jak kwadratowego obszaru, a nie jako punktu.
Wtedy na jeden pixel docelowy składają się maksymalnie 4 inne pixele źródłowe.
Wpływ pikseli źródłowych jest proporcjonalny do pola jakie zajmują w
pixelu docelowym. To tak wymyśliłem w 5 minut... pewnie są lepsze sposoby i
właśnie szybsze :)
Pozdrawiam











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


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