-
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
From: " " <f...@g...pl>
Newsgroups: pl.comp.programming
Subject: Re: reczne rotowanie bitmap
Date: Fri, 30 Mar 2012 09:38:50 +0000 (UTC)
Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
Lines: 191
Message-ID: <jl3uva$p5j$1@inews.gazeta.pl>
References: <jl3rs6$kbq$1@inews.gazeta.pl> <jl3t3f$c0u$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 1333100330 25779 172.20.26.236 (30 Mar 2012 09:38:50 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Fri, 30 Mar 2012 09:38:50 +0000 (UTC)
X-User: fir
X-Forwarded-For: 79.162.71.107
X-Remote-IP: localhost
Xref: news-archive.icm.edu.pl pl.comp.programming:196437
[ ukryj nagłówki ]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/
Następne wpisy z tego wątku
- 30.03.12 12:25 M.M.
- 30.03.12 13:29 bartekltg
- 30.03.12 15:13 Adam Wysocki
- 30.03.12 15:13 Adam Wysocki
- 30.03.12 17:33
- 30.03.12 18:18
- 30.03.12 18:20 bartekltg
- 30.03.12 18:27
- 30.03.12 18:37 bartekltg
- 30.03.12 19:10
- 30.03.12 19:59
- 30.03.12 21:23 Michoo
- 30.03.12 21:26 Michoo
- 31.03.12 01:12
- 31.03.12 08:25
Najnowsze wątki z tej grupy
- 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??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
Najnowsze wątki
- 2024-05-20 Fiat 125p wer. pikup - w PRL moszna było, w III Reczy [pospolitej] nie moszna
- 2024-05-19 Pożar salonu z chińskimi elektrykami
- 2024-05-18 LED
- 2024-05-19 ceny nieruchomości
- 2024-05-18 Szczecin => UX/UI Designer <=
- 2024-05-18 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-18 Warszawa => Software .Net Developer <=
- 2024-05-18 Warszawa => Mid/Senior QA Engineer <=
- 2024-05-18 Ulm => Solution Architect (sichere Kommunikation und IoT-Loesungen <=
- 2024-05-18 Katowice => Head of Virtualization Platform Management and Operating S
- 2024-05-18 Warszawa => SAP WM Consultant / Execution <=
- 2024-05-18 Wrocław => Consultant/Implementer Comarch ERP XL <=
- 2024-05-18 Gdańsk => Head of International Freight Forwarding Department <=
- 2024-05-18 Warszawa => Account Manager (Recruitment Services) <=
- 2024-05-18 Łódź => Salesperson - CRM Systems <=