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)









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

do góry

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/

do góry

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/

do góry

<f...@g...pl> napisał(a):
> 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

Tam cos gadali o tym:
http://forum.warsztat.gd/index.php?topic=5044.0
Moze cos Ci sie przyda.
Pozdrawiam


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

do góry

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.

Obliczasz zakres (prostokąt) na docelowej bitmapie na jaki przejdzie
obiekt i iterujesz po tych pikselach. Dla każdego obliczasz, z którego
miejsca małego obrazka pobrać kolor.

Przy okazji, bardzo łatwo robi się interpolacje (gdy np z obliczen
wychodzi współrzędna do pobrania 145.6, 45.4 to należałoby wziąć średnią
z kilku pikseli), co poprawia jakość, uniemożliwia zgubienie
szczegółów.

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

Użyj biblioteki. Nawet allegro. W dzisiejszych czasach optymalnym
rozwiązaniem jest chyba zrzucenie takich rzeczy na GPU.

>
> tak naprawde transformacj jakiej uzywam by przetransformowac kazdy
> pixel jest troche bardziej zlozona bo chce miec mozliwosc rysowania

Dopóki jesteś w stanie ja odwrócić, nie ma problemu.


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


Krótka pętla w której nie ma żadnych wywołań funkcji,
jedynie przerzucanie pikseli.
Wartości sin i cos nie obliczaj w pętli, tylko raz przed nią.

Dobrze wyznacz przekrzywiony prostokąt na obrazie docelowym,
pętla po jednej wspolrzednej w całym zakresie, po drugiej, tylko
to, co potrzeba.

Wewnętrzna pętla powinna iterować zgodnie z ułożeniem
pikseli w pamięci.


A jak chcesz wydajności, użyj biblioteki.
Albo chociaż popatrz, jak to napisali w allegro.

pzdr
bartekltg

do góry

<f...@g...pl> wrote:

> mysle ze podwojna ilosc punktow by wystarczyla (bo sa to bledy jakby
> miedzy pixelowe) ale to jest spowolnienie 2x

4x - są dwa wymiary.

Poczwórna ilość punktów da ci spowolnienie 16x.

--
Gof

do góry

fir kenobi <f...@g...pl> wrote:

> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)

Czy to muszą być bitmapy? Na grafice wektorowej byłoby to dużo prostsze.

--
Gof

do góry

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

do góry

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
algorytm - chyba pod linkiem do warsztatu zapodanym wyzej jest cos
ciekawego (jeszcze nie obejrzalem)



> Obliczasz zakres (prostokąt) na docelowej bitmapie na jaki przejdzie
> obiekt i iterujesz po tych pikselach. Dla kaĹźdego obliczasz, z ktĂłrego
> miejsca małego obrazka pobrać kolor.
>
> Przy okazji, bardzo łatwo robi się interpolacje (gdy np z obliczen
> wychodzi współrzędna do pobrania 145.6, 45.4 to należałoby wziąć
średni
> ą
> z kilku pikseli), co poprawia jakość, uniemożliwia zgubienie
> szczegółów.
>
> > 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)
>
> UĹźyj biblioteki. Nawet allegro. W dzisiejszych czasach optymalnym
> rozwiązaniem jest chyba zrzucenie takich rzeczy na GPU.
>
> >
> > tak naprawde transformacj jakiej uzywam by przetransformowac kazdy
> > pixel jest troche bardziej zlozona bo chce miec mozliwosc rysowania
>
> Dopóki jesteś w stanie ja odwrócić, nie ma problemu.
>
>
> >
> > 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)
>
>
> Krótka pętla w której nie ma żadnych wywołań funkcji,
> jedynie przerzucanie pikseli.
> Wartości sin i cos nie obliczaj w pętli, tylko raz przed nią.
>
> Dobrze wyznacz przekrzywiony prostokąt na obrazie docelowym,
> pętla po jednej wspolrzednej w całym zakresie, po drugiej, tylko
> to, co potrzeba.
>
> Wewnętrzna pętla powinna iterować zgodnie z ułożeniem
> pikseli w pamięci.
>
>
> A jak chcesz wydajności, użyj biblioteki.
> Albo chociaĹź popatrz, jak to napisali w allegro.
>
> pzdr
> bartekltg


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

do góry

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

> <f...@g...pl> napisał(a):
> > 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
>
> Tam cos gadali o tym:
> http://forum.warsztat.gd/index.php?topic=5044.0
> Moze cos Ci sie przyda.

tam pod linkami jest cos takiego

// compute deltas
int dxdx = (Bx-Ax)/320,
dydx = (By-Ay)/320,
dxdy = (Cx-Ax)/200,
dydy = (Cy-Ay)/200;
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&kt;320; i++)
{
// get texel and store pixel
page_draw[offs] = texture[((Cy>>8)&0xff00)+((Cx>>16)&0xff)];
// interpolate to get next texel in texture space
Cx += dxdx;
Cy += dydx;
offs++;
}
// interpolate to get start of next line in texture space
Ax += dxdy;
Ay += dydy;
}

nie calkiem to rozumiem i musialbym przepisac pixelsetowa linijke
( z drugiej strony wydaje sie proste - A B i C to zgaduje wierzcholki
quada w zrodle - zgadule ze A to lewy dolny B to prawy dolny a C lewy
gorny)

na rzie moje procedury z sinusami dzialaja tak

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

(trzeba rozpakowac do folderu )

- sa artefakty i dziala nie za szybko - gdyby sie udalo jednak
przy pomocy tego cholerstwa u gory spowodowac ze by przyspieszylo
pare razy i artefakty zniknely to bylbym zadowolony


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

do góry