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

> 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 :)
>
>
mysle ze podwojna ilosc punktow by wystarczyla (bo sa to bledy jakby
miedzy pixelowe) ale to jest spowolnienie 2x - mi chodzi wlasnie o
te szybsze i poprawniejsze metody

1. jak zmienic algorytm na sprytniejszy
2. ew jak mozn podoptymalizowac chocby ta bledna procedure

(poprawilem troche nazwy:
transform to transformacja viewportu nad logicznym ekranem,
transform_alfa to kat obrotu viewportu,
transform_center_point to punkt w samym viewporcie
np srodek (CLIENT_X/2, CLIENT_Y/2) wokol ktorego jest obracane,
sprite_centre to punkt srodka sprite'a
sprite_alfa to kat obrotu sprite'a wokol wlasnego srodka)




inline void SetPixelInDib(float x, float y, unsigned color)
{
if(useTransform)
{
///// transformacja do wspolrzednych viewportu

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;

//// plus obrot punktu dookola srodka sprite'a

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;

}

/// postawienie na ekranie

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;

}

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