Adam Wysocki wrote:
> fir kenobi <f...@g...pl> wrote:
>
>> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
>> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)
>
> Czy to muszą być bitmapy? Na grafice wektorowej byłoby to dużo
> prostsze.

No chyba, że on to robi dla sportu. Najprostszym sposobem rotowania bitmapy
jest wykonanie szeregu klatek tejże bitmapy co ileś tam stopni i ich
animacja a nie zaprzęganie do tego "wyższej" matematyki.
yamma

do góry

yamma <y...@w...pl> napisał(a):

> Adam Wysocki wrote:
> > fir kenobi <f...@g...pl> wrote:
> >
> >> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
> >> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)
> >
> > Czy to muszą być bitmapy? Na grafice wektorowej byłoby to dużo
> > prostsze.
>
> No chyba, że on to robi dla sportu. Najprostszym sposobem rotowania bitmapy
> jest wykonanie szeregu klatek tejże bitmapy co ileś tam stopni i ich
> animacja a nie zaprzęganie do tego "wyższej" matematyki.
> yamma
A co jeśli duszków jest dużo? Warto zapychać pamięć w kompie i potem
gdy się przełączamy na inny program to czekać aż się wczytają z
pliku wymiany?
Pozdrawiam




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

do góry

On 2012-03-31 11:58, M.M. wrote:
> yamma<y...@w...pl> napisał(a):
>
>> Adam Wysocki wrote:
>> > fir kenobi<f...@g...pl> wrote:
>> >
>> >> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
>> >> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)
>> >
>> > Czy to muszą być bitmapy? Na grafice wektorowej byłoby to dużo
>> > prostsze.
>>
>> No chyba, że on to robi dla sportu. Najprostszym sposobem rotowania bitmapy
>> jest wykonanie szeregu klatek tejże bitmapy co ileś tam stopni i ich
>> animacja a nie zaprzęganie do tego "wyższej" matematyki.
>> yamma
> A co jeśli duszków jest dużo? Warto zapychać pamięć w kompie i potem
> gdy się przełączamy na inny program to czekać aż się wczytają z
> pliku wymiany?

1. cache
2. RAM jest bardzo tani
3. albo chcesz, żeby szybko działało, albo żeby było proste i małe. często nie
da się tego połączyć

--
MB

do góry

Marcin Biegan <a...@u...lama.net.pl> napisał(a):

> On 2012-03-31 11:58, M.M. wrote:
> > yamma<y...@w...pl> napisał(a):
> >
> >> Adam Wysocki wrote:
> >> > fir kenobi<f...@g...pl> wrote:
> >> >
> >> >> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
> >> >> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)
> >> >
> >> > Czy to muszą być bitmapy? Na grafice wektorowej byłoby to dużo
> >> > prostsze.
> >>
> >> No chyba, że on to robi dla sportu. Najprostszym sposobem rotowania bitmapy
> >> jest wykonanie szeregu klatek tejże bitmapy co ileś tam stopni i ich
> >> animacja a nie zaprzęganie do tego "wyższej" matematyki.
> >> yamma
> > A co jeśli duszków jest dużo? Warto zapychać pamięć w kompie i potem
> > gdy się przełączamy na inny program to czekać aż się wczytają z
> > pliku wymiany?
>
> 1. cache
> 2. RAM jest bardzo tani
> 3. albo chcesz, żeby szybko działało, albo żeby było proste i małe. często nie
> da się tego połączyć

Weźmy z 30 duszków na prostą grę 2D. Aby animacja była płynna to dajmy
klatkę co 3 stopnie, czyli 30x120 obiektów. Duszek niech ma średnio 70x70
pixeli, da to po obrocie obiekty około 100x100. Czyli w RGBA
30x120x100x100x4 =~ 140MB na prostą grę 2D :D

Pozdrawiam



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

do góry

M.M. <m...@g...pl> napisał(a):

> Marcin Biegan <a...@u...lama.net.pl> napisał(a):
>
> > On 2012-03-31 11:58, M.M. wrote:
> > > yamma<y...@w...pl> napisał(a):
> > >
> > >> Adam Wysocki wrote:
> > >> > fir kenobi<f...@g...pl> wrote:
> > >> >
> > >> >> powiedzmy ze mam maly pixelbufor (np 200x200) z danymi sprite'a
> > >> >> i duzy pixelbufor (z pixelami dla calego ekranu np 2000x1600)
> > >> >
> > >> > Czy to muszą być bitmapy? Na grafice wektorowej byłoby to dużo
> > >> > prostsze.
> > >>
> > >> No chyba, że on to robi dla sportu. Najprostszym sposobem rotowania
bitma
> py
> > >> jest wykonanie szeregu klatek tejże bitmapy co ileś tam stopni i ich
> > >> animacja a nie zaprzęganie do tego "wyższej" matematyki.
> > >> yamma
> > > A co jeśli duszków jest dużo? Warto zapychać pamięć w kompie i potem
> > > gdy się przełączamy na inny program to czekać aż się wczytają z
> > > pliku wymiany?
> >
> > 1. cache
> > 2. RAM jest bardzo tani
> > 3. albo chcesz, żeby szybko działało, albo żeby było proste i małe.
często ni
> e
> > da się tego połączyć
>
> Weźmy z 30 duszków na prostą grę 2D. Aby animacja była płynna to dajmy
> klatkę co 3 stopnie, czyli 30x120 obiektów. Duszek niech ma średnio 70x70
> pixeli, da to po obrocie obiekty około 100x100. Czyli w RGBA
> 30x120x100x100x4 =~ 140MB na prostą grę 2D :D
>

pc (chocby moj prosty wypracowywany obecnie framework) potrafi uciagnac
znacznie wiecej sprite'ow - naraz na ekranie to chyba nawet pare tysiecy
(jesli male, zalezy od rozmiaru) a naraz w grze (z odrzucaniem tych
spoza wievportu) to zdaje sie nawet wielokroc wiecej - 30 spritow to
sklala gier ze starej epoki (choc dokladnie nie mierzylem ale teraz
wydaje sie moze smigac znacznie wiecej)





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

do góry

W dniu 2012-03-30 19:10, f...@g...pl pisze:
> bartekltg<b...@g...com> napisał(a):
>
>> W dniu 2012-03-30 18:27, f...@g...pl pisze:
>>
>>>>
>>> nie tak samo szybkie tylko tak samo wolne (zobacz jak to dziala pod
>>
>> No widzisz, pozbędziesz się artefaktów a szybkość (którą jak
>> naprawić też mówiłem) pozostanie osobnym problemem.
>>
>>> 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
>>
>> Zerknąłem. Robią tak jak mówiłem:
>>
>> "
>> ARGB_Img1[ti] = ARGB_Img0[(y0>>10)*ImW+(x0>>10)];
>> "
>>
>> ti to "iterator" jadący po obrazku odcelowym.
>> Obliczane wspolrzędny y0 i x0 na obrazie-źródle
>> uaktualniane są przez dodawanie i trzymane jako stały przecinek.
>>
>>
>
> to albo niezbyt wyraznie albo jednak nie o tym, bo to nie
> jest po prostu transformacja na cos sin /-sin cos tylko w druga
> strone -

Transformacją odwrotną do obrotu jest obrót w drugą stronę.
Sin -> -sin,
cos-> cos


> tutaj sie transformuje tylko narozne punkty i liczy proste dx dy ,

Bo to transformacja liniowa. A taki zapis ładnie tworzy nam
wszelkie transformacje liniowe, nie tylko obroty.



> zaczyna mi dzialac - co prawda tylko na floatach a w oryginale jest
> na intach (na intach nie chialo zadzialac a nie petrzylem wiecej)
> i bede sie musiec nabiedzic nad tym ze ja mam podwojna
> translacje-rotacje a nie tylko pojedyncza (z lekka mnie glowa
> rozbolala wiec moze jutro) - ale chyba powinno dzialac i raczej
> powinno byc zbacznie szybciej przez te dx/dy

_Zrozum_ najpierw ten algorytm, albo prostrzą wersję którą
opisywałem. Potem pisz. Nie rozumiejąc algorytmu nie masz
po co go pisać, namęczysz się tylko.

pzdr
bartekltg

do góry

W dniu 2012-03-30 21:23, Michoo pisze:
> On 30.03.2012 18:37, bartekltg wrote:
>> ti to "iterator" jadący po obrazku odcelowym.
>> Obliczane wspolrzędny y0 i x0 na obrazie-źródle
>> uaktualniane są przez dodawanie i trzymane jako stały przecinek.
> Swoją drogą aż dziwne, że nie robią tego na SSE.

Przecież to java;)

pzdr
bartekltg

do góry

W dniu 2012-03-31 01:12, f...@g...pl pisze:
> niestety po wyrugowaniu transformacji dla kazdego pixela,
> czyli przepisaniu petli rysujacej mw z 1 na 2
>
>
> //////////////////////2
>
>
>
> for(int j=0; j<sprite_height; j++)
> {
>
> for(int i=0; i<sprite_width; i++)
> {
>
> unsigned v = sprites_buf_[sprite_bitmap_posy+j]
> [sprite_bitmap_posx+i];
>
>
> 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;
>
>
> x+=dxdx;
> y+=dydx;
>
> }
>
> x -= (xBfiz-xAfiz);
> y -= (yBfiz-yAfiz);
>
> x += dxdy;
> y += dydy;
>
>
> }
>
> ///////////////

Nic z tego nie rozumiem. Nie będę siedzieć i dekodować:)
słyszałeś o komentarzach? Co jest wejściem, co jest wyjściem?

Jakiego typu są x i y? przypadkiem ine float? W poscie
dalej widzę, ze floaty i stały przecinek poprawił sytuację.


Z tego, co zgaduję, dalej robisz od 'dupy strony'.
To źródło ma mieć obliczany adres, a indeksowanie biec
po docelowym obrazie. Uparcie robisz odwrotnie.

pzdr
bartekltg

do góry

On 2012-03-30 10:45, fir kenobi wrote:
> potrzebuje odrysowywac sprite'a na ekranie z rotacją i translacja,

Slowo kluczowe: zoomrotator.

Przykład:

http://hem.passagen.se/miclaes/OldApplets/ZoomRot/Zo
omRot.html

do góry

W dniu 2012-03-31 12:03, Marcin Biegan pisze:

> 2. RAM jest bardzo tani

I myśli tak każdy twórca największej pierdółki. I nagle ejst zdziwienie,
że na kompie z 8GB RAMu jest tych pierdółek więcej niż jedna, wszytkie
tak samo napisane;)

> 3. albo chcesz, żeby szybko działało, albo żeby było proste i małe.
> często nie da się tego połączyć

4. Takie rzeczy powinno teraz robić GPU. Radzi sobie idealnie:)

pzdr
bartekltg

do góry