=?ISO-8859-2?Q?_genera=B3_kenobi?= <f...@W...gazeta.pl> napisał(a):

> ten sposob rysowania rotowanej bitmapy jest fenomenalny
> swoja prostota
>
> for(int j=0; j<sprite_height; j++)
> {
> for(int i=0; i<sprite_width; i++)
> {
> SetPixel( x>>20, y>>20, sprite[j][i] );
>
> x += dxdx; // skosy/ poprawki dla ruchu pixele na fiz ekranie
> y += dydx; // dla ruchu po tekselach x++
> }
>
> x += dxdy; // skosy dla y++
> y += dydy;
> }
>
> tu raczej nie da sie nic poprawic - ale chcialbym jakos moze
> poprawic sama funkcje stawiania pixela
>
> inline void SetPixelInDibInt(int x, int y, unsigned color)
> {
>
> 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;
>
> }
>
> mam tutaj cala mase warunkow, zabezpieczajacych wprost przed
> postawieniem pixela poza pamiecia ekranu - samo filtrowanie
> sprite'ow robie bardzo zgrubne (odrzucam sprity o srodku iles tam
> dalej poza ekranem ) tak ze przez to przechodzi cala masa
> pixeli ze sprite'ow ktore sa tylko czesciowo w ekranie --
>
> jak przerobic kod tej funkcji by bylo szybciej?
>
wychodzi na to ze wlasnie nalezaloby odwrocic proces - o ile
teraz jake po calej tekturze (a duza tekstura w prog2.exe ma 1000x1000
pixeli ) i czestokroc wypadam poza ekran to po obroceniu mozna
iterowac bez problemu po obruconej teksturze tylko w tym kawalku
ktory lezy w ekranie - tak ze to mogloby nawet przyspieszyc

(choc sa dodatkowe koszty albo zapisywania tych krawedzi dla sylwetki
albo iterowania po wiekszych kwadratach) - tak ze zarazem moze przyspieszyc
jak i moze zwolnic


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