-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!wsisiz.edu.pl!newsfeed2.atman.pl!newsfe
ed.atman.pl!goblin2!goblin3!goblin.stu.neva.ru!de-l.enfer-du-nord.net!feeder1.e
nfer-du-nord.net!feeder2.enfer-du-nord.net!tudelft.nl!txtfeed1.tudelft.nl!multi
kabel.net!newsfeed20.multikabel.net!news.glorb.com!border3.nntp.dca.giganews.co
m!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.
giganews.com!nntp.giganews.com!npeer01.iad.highwinds-media.com!news.highwinds-m
edia.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.goog
legroups.com!not-for-mail
From: Adam Klobukowski <a...@g...com>
Newsgroups: pl.comp.programming
Subject: Re: reczne rotowanie bitmap
Date: Fri, 30 Mar 2012 06:30:31 -0700 (PDT)
Organization: http://groups.google.com
Lines: 98
Message-ID: <28126835.1452.1333114231971.JavaMail.geo-discussion-forums@vbai14>
References: <jl3rs6$kbq$1@inews.gazeta.pl>
NNTP-Posting-Host: 89.74.53.149
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1333114632 3154 127.0.0.1 (30 Mar 2012 13:37:12 GMT)
X-Complaints-To: g...@g...com
NNTP-Posting-Date: Fri, 30 Mar 2012 13:37:12 +0000 (UTC)
In-Reply-To: <jl3rs6$kbq$1@inews.gazeta.pl>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=89.74.53.149;
posting-account=mvBzhgoAAADiziO82aLj4VEpjexQv3Cn
User-Agent: G2/1.0
X-Received-Bytes: 4263
Xref: news-archive.icm.edu.pl pl.comp.programming:196568
[ ukryj nagłówki ]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
Najnowsze wątki z tej grupy
- 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??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
Najnowsze wątki
- 2025-01-29 "Zorganizowana Grupa Przestępcza" poczeka na decyzję o ekstradycji z UK na wolności [RARS]
- 2025-01-29 Ostrów Wielkopolski => Area Sales Manager OZE <=
- 2025-01-29 Warszawa => Architekt rozwiązań (doświadczenie w obszarze Java, AWS
- 2025-01-29 Poznań => Konsultant wdrożeniowy Comarch XL/Optima (Księgowość i
- 2025-01-29 Poznań => Specjalista ds. Employer Brandingu <=
- 2025-01-29 Warszawa => Developer Microsoft Dynamics 365 Finance & Operations (D36
- 2025-01-29 Warszawa => Junior Rekruter <=
- 2025-01-29 Warszawa => Mid IT Recruiter <=
- 2025-01-29 Białystok => UX Designer <=
- 2025-01-29 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2025-01-29 Warszawa => Expert Recruiter 360 <=
- 2025-01-29 Zdalny podpis
- 2025-01-29 Nazbyt "muzyczne" słuchawki
- 2025-01-29 Warszawa => QA Engineer <=
- 2025-01-29 Prawo jak je [nie]rząd rozumie.