bartekltg <b...@g...com> napisał(a):

> W dniu 2012-03-30 17:33, f...@g...pl pisze:
> > bartekltg<b...@g...com> napisał(a):
> >
> >> W dniu 2012-03-30 10:45, fir kenobi pisze:
> >>> 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
> >>
> >>
> >> Bo robi sie to odwrotnie.
> >>
> > kojarze ze mozna robic odwrotnie - ale odwrotnie tez bedzie niedobrze
> > - transformacje tysiecy punktow oddzielnie- powinien byc jakis szybki
>
> Głupoty opowiadasz. Obie wersje są tak samo szybkie. W obu wersjach,
> jeśli masz obrót bez skalowania iterujesz po podobnej liczbie pikseli.
>
> Mówiłem, nie transformuj ich oddzielnie. Transformacje wyliczasz raz.
> potem robisz tylko dodawania i ewentualnie średnie.
> Nawet sin i cos mozesz nie trzymać jako zmiennoprzecinkowe,
> ale jako stały przecinek i robić odpowiednie przesunięcia bitów.
>
> Robiąc 'od dupy strony' będziesz miał czarne (czy jakiego tam koloru
> masz tło) plamy i nic na to niskim nakładem nie poradzisz:)
>
nie tak samo szybkie tylko tak samo wolne (zobacz jak to dziala pod
linkiem wyzej) - pod drugim linikiem jest dyskusja nt czegos co
w demoscenie nazywa sie rotozoomer - bede musiec sie troche
pomeczyc i zobaczyc czy uda mi sie to zmusic do dzialania


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