-
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
From: " " <f...@N...gazeta.pl>
Newsgroups: pl.comp.programming
Subject: Re: dalsza optymalizacja
Date: Sun, 1 Apr 2012 20:50:22 +0000 (UTC)
Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
Lines: 183
Message-ID: <jlaf2e$cim$1@inews.gazeta.pl>
References: <jl73ie$b6f$1@inews.gazeta.pl> <jl9aaf$326$1@inews.gazeta.pl>
<jl9al3$ee7$1@inews.gazeta.pl> <jla81e$krd$1@inews.gazeta.pl>
NNTP-Posting-Host: localhost
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit
X-Trace: inews.gazeta.pl 1333313422 12886 172.20.26.235 (1 Apr 2012 20:50:22 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Sun, 1 Apr 2012 20:50:22 +0000 (UTC)
X-User: fir
X-Forwarded-For: 178.56.43.180
X-Remote-IP: localhost
Xref: news-archive.icm.edu.pl pl.comp.programming:196524
[ ukryj nagłówki ]<f...@N...gazeta.pl> napisał(a):
> <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)
>
jeszcze poprawilem, i znowu nawet wyraznie przyspieeszylo
int fy = from_y - yAfizInt;
int fx = from_x - xAfizInt;
int logX = ( dxdx_ * fx - dxdy_ * fy);
int logY = (-dydx_ * fx + dydy_ * fy);
int dj_logX = ( ( -dxdy_) - ( dxdx_)*(to_x-from_x));
int dj_logY = ( ( dydy_) - (-dydx_)*(to_x-from_x));
for(int j=from_y; j<to_y; j++)
{
for(int i=from_x; i<to_x; i++)
{
int xx = logX>>16;
int yy = logY>>16;
if(!( yy<0 || yy>=sprite_height || xx<0 ||
xx>=sprite_width ))
{
unsigned color = sprites_buf_[sprite_bitmap_posy + yy]
[sprite_bitmap_posx + xx];
if(!color==0) //SetPixelInDibInt(i, j, color);
((unsigned*)pBits)[((CLIENT_Y-1-j)*CLIENT_X+i)] = color;
}
logX += ( dxdx_) ;
logY += (-dydx_) ;
}
logX += dj_logX;
logY += dj_logY;
}
}
moze nawet troche mniej narzekam na plynnosc, te szarpania sa glownie
chyba tylko temporalne - kiedys by trzeba pocwiczyc wyrownywanie czasow
ramek - finalnie od wersji z poczatku watku o rotowaniu bitmap
przyspieszylo prawie 10 razy
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Następne wpisy z tego wątku
- 01.04.12 23:56 M.M.
- 01.04.12 23:59 bartekltg
- 02.04.12 00:11 M.M.
- 02.04.12 00:13 M.M.
- 02.04.12 01:20 bartekltg
- 02.04.12 02:58 M.M.
- 02.04.12 08:25
- 02.04.12 10:40 zażółcony
- 02.04.12 10:46
- 02.04.12 11:46
- 02.04.12 14:58 bartekltg
- 02.04.12 15:00 bartekltg
- 02.04.12 15:22 M.M.
- 02.04.12 15:55 M.M.
- 02.04.12 16:16 bartekltg
Najnowsze wątki z tej grupy
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
Najnowsze wątki
- 2025-02-09 Ster w trolejbusie.
- 2025-02-09 Jebany POPiS. Mamy się cieszyć że rząd Tuska naprawił spierdolone porozumienie z UE?
- 2025-02-08 W zyciu warto miec szczescie
- 2025-02-08 Elektryki
- 2025-02-08 Alg. kompresji LZW
- 2025-02-08 Kraków => Key Account Manager <=
- 2025-02-08 Warszawa => Java Developer <=
- 2025-02-09 Cenzura netu
- 2025-02-08 Re: Historyczny sukces tuskistanu: groźna cyber-przestępczyni emerytka Iza błyskawicznie ujęta!
- 2025-02-08 Re: Historyczny sukces tuskistanu: groźna cyber-przestępczyni emerytka Iza błyskawicznie ujęta!
- 2025-02-08 Re: Historyczny sukces tuskistanu: groźna cyber-przestępczyni emerytka Iza błyskawicznie ujęta!
- 2025-02-08 Lokaty na nowe środki
- 2025-02-07 Jaki silikon lub może klej?
- 2025-02-07 Gdańsk => iOS Developer (Swift experience) <=
- 2025-02-07 Warszawa => Starszy Programista C <=