<f...@N...gazeta.pl> napisał(a):

> <f...@N...gazeta.pl> napisał(a):
>
> > =?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
> >
>
> troche sie zmeczylem ale wieczorem moze sprobuje (z ciekawosci czy
> przyspieszy) uruchomic prostrsza wersji z odwrotna transformacja
> (tj bez sylwetek)
>
>

napisalem

int from_x = max( min(xAfiz,xBfiz,xCfiz,xDfiz), 0);
int to_x = min( max(xAfiz,xBfiz,xCfiz,xDfiz), CLIENT_X);
int from_y = max( min(yAfiz,yBfiz,yCfiz,yDfiz), 0);
int to_y = min( max(yAfiz,yBfiz,yCfiz,yDfiz), CLIENT_Y);


for(int j=from_y; j<to_y; j++)
{
int fy = j - yAfizInt;

int dxdy_fy = dxdy_ * fy;
int dydy_fy = dydy_ * fy;

for(int i=from_x; i<to_x; i++)
{
int fx = i - xAfizInt;

int logX = ( dxdx_ * fx - dxdy_fy)>>20;
int logY = (-dydx_ * fx + dydy_fy)>>20;

if( logY<0 || logY>=sprite_height || logX<0 ||
logX>=sprite_width );
else
{
unsigned color = sprites_buf_[sprite_bitmap_posy + logY]
[sprite_bitmap_posx + logX];

if(!color==0)
((unsigned*)pBits)[((CLIENT_Y-1-j)*CLIENT_X+i)] = color;

}

}

}


zniknely artefakty (choc one bywaly fajne jak kropki w druku
gazetowym ) i cholerstwo jeszcze troche przyspieszylo - przyspiesza na
wyraznych przypadkach clippingu bo w tę strone jest automatyczny i nie
stawia sie ani nawet jednego pixela poza ekranem,
moglbym jeszcze zrobic te sylwetki i przepisac petle z mnoznej na
dodawczą ale to moze kiedy indziej

martwi mnie teraz inna rzecz - plynnosc jest slaba bo czasy ramek
oscylują jak szum, przy tym nie mam pewnosci czy plynnosc przestrzenna
jest ok - tj np czy obracaniu nie kwantyzuje malych roznic miedzy katami
obrotu - trzebaby sie przyjrzec kodu - ale to tez ew raczej kiedy indziej
- dziala tylko rwie (nie jest oleiscie plynnie)




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