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:)

pzdr
bartekltg