Najbolje da uradish "test" a to je da "izsilujesh" flash sa bar 50 takvih objekata koji se krecu na sve strane (ili na jednu stranu) svaki za sebe. Mozda najbolje sa vise razlicitih bitmapa.

Onda preko trace()-a trejsujesh milisekunde svakog frejma (koliko je vremena proslo izmedju svakog frejma) a da u funkciji enterFrame() dodash updateAfterEvent() sto ce silovati flash da updejtuje frame posle svakog frejma (koliko go je to moguce brzo)

Pritom proverish preko task menagera koliko CPU-a i memorije troshi flash prilikom izvrshavanja takvog filma.

Zatim probash i ovu drugu tehnologiju i samo uporedish merenja.

Mmmmmm, lepa ideja.
Znaci da napravim 50 bitmapa i da ih mrdam na razne strane.
U pravu si!! Jedino tako ce to trajati dovoljno dugo da mogu da ga merim milisekundama! Odlicno, hvala :)


A kako da koristim updateAfterEvent() u ActionScript3?
Ja i helpu nasao da je to moguce samo za mouse i keyboard event-e.

Googlao sam nesto i procitao da "tearing" odnosno kidanje slike pri brzim animacijama nastaje jer Flash player NE moze da uradi vertical sysc trace!!!
Nego da samo ko mazga upisuje bmp vrednosti. Nekako mi to deluje neozbiljno.

A možeš i ovo da probaš
http://www.flashextension.net/...tid=16167&cat=4&page=1

Pa mislim da flash sada pokusava da sto je moguce bolje zadrzi konstantan framerate. Ranije se flash usporavao na sporijim mashinama. Ne bi me cudilo da sve to moze da se podeshava.

Tako sam ja ranije pravio neke igrice, pa su neki ljudi razvaljivali rekorde dok smo se mi ostali muchili, dok nisam shvatio da oni imaju mnogo slabije kompove i sa im sve ide mnogo sporije. :)

Ja sada praktikujem da ako ide neka super-brza animacija (pogotovu sa dosta fejdova i menjanje _alpha) ja napishem:
_quality = "madium";
Na kraju animacije samo vratim na
_quality = "autohigh";

VENGEANCE MX se kune u scrollRect rutinu.

Sa moje tacke gledista, skoro da je sve jedno da li koristim scrollRect ili copyPixel...
Velike bmp se ocigledno moraju razloziti na vise malih, pa tek onda ide njihov prikaz.
A ja bas zapeo za 20000 x 15000 px bmp...

Hvala mnogo za ideje.


I dalje ne znam kako da koristim updateAfterEvent za enterFrame u AS3.
I dalje mi je muka sto Flash nema vsync(). Valjda ce to staviti u narednoj verziji.

Pa dobro, ti onda stavi updateAfterEvent() u onMouseMove() event-funkciju pa drndaj misha dok piche objekti po ekranu :) ili jednostavno stavi da ti film ima 100 FPS-a :)

Koliko ja znam, najoptimalnije za graficke kartice je koristiti slike koje su kvadratastog oblika i da su dimenzija a-power-of-two (takve slike graficke kartice najbrze obradjuju) to znaci: 64x64, 128x128, 256x256, 512x512, 1024x1024, 2048x2048...

To vazi za openGL i directX. Flash verovatno koristi openGL, ili neshto svoje...

Hola StarCrafte, to je vredna informacija!

Znam da je za xvid kompresiju vazno da se prave stranice deljive sa 16 ali nisam znao za stepen 2 za graficke!

Juce sam gledao i test koji pokazuje da je za 13% brze da se setPixel na BitmapData koji nije na ekranu (addChild).

Sto je i sasvim normalno, jer flash ne mora da trosi resurse rendanjem na stage.

Ajd da se i ja ukljucim, ako vec imas velike bmpe, jeste brze je da uzmes samo deo sa bitmap data, prebacis u neki sprite/bitmap, i nabacas i ostalo sto ti treba isto tako, i onda da ga prikazes na stageu.

to znaci da ces imati 3 stvari o kojima vodis racuna.
1. bitmape iz kojih vuces bitmap data (deo ili cele nema veze)
2. buffer bitmap u koji ces praviti composition, ovde moras obratiti paznju na redosled ubacivanja pixela itd.
3. bitmap na stageu u kome ces prikazati bitmap data iz buffer bitmapa kad zavrsis composition.

Ovo je naravno ugrubo, jer nisi do sada rekao sta radis, tako da moze da se desi, da ti je buffer bitmap mnogo veci od onog sto prikazujes na ekranu, pa mozes onda da prikazujes i samo delove buffer bitmapa, opet moze i da se desi da ti je buffer bitmap h/w isti kao i onaj na stageu.

huh, sada vidim da je StarCraft napisao da je to optimim za graficke kartice... Oce li biti primetni pomak za Flash ako koristim sliku velicine stepena 2?

Pitam jer mi je i 2880x2880 relativno malo.

Buffer BMP ce biti zestoko manji od BitmapData. Mozda oko 500c400px. A BitmapData bi trebao da bude sto veci da sto kasnije moram da pravim novi.

Pokusavam da napravim Flash igricu. Trke kola. Bird view. Pa to mora da bude malo brza animacija pozadine.

A vec sad vidim da nece biti naivno to seckanje velike slike i setPixel(). Snacicu se valjda nekako.
Ako zapne nesto, javljam se :)


Vranac, hvala ti jos jednom za onaj loader. Spasio si me, nemas pojma koliko :)

Rad Andre Michelle-a Uniroyal Fun Cup:
http://clients.wmteam.de/uniro...index_fmx.php?fileLanguage=eng

Treba da pogledas tile engines za as3

Aaaaaaaaaaauuuu! Lik je bas iskodirao sve to!

Dodao je i izometriju i kameru i svasta.

Zanima me kako je resio "tearing" slike za velike pomeraje.

Skiknuo sam neki mnogo dobar tutor za tile games AS2. Principi su mi najvazniji, za sada :)
http://www.tonypa.pri.ee

Isto to samo za AS3
http://www.tonypa.pri.ee/tbw/as3/start.html

Jedno glupo pitanje:

Zasto se ne koristi standardno x,y za pomeranje Bitmape? Mislim
slika.x = pomeraj;
slika.y = pomeraj;

Nekako imam osecaj da se to radi bas uz pomoc scrollRect, a da su stageWidth i stageHeight dimenzije tog rect koji se pomera. Gresim li?



p.s. Vranac stvarno si kralj! Ako ikad dodjem za NS, castim pice po izboru!

Pa moze da se koristi, ali u celoj ovoj prici su kljucne reci efikasnost i performanse.

Razmisli, ako imas jednu bitmapu koja je 5000x5000, i pomeris je po x i y, flash ce je pomeriti i krenuti da je renda, cak i onaj deo koji ti ne vidis, time se trosi mnogo resursa cpu i memorije.
Da pogorsamo stvari, ti tu bitmapu pocnes da pomeras na svakom enter frame-u, i masina ce poceti da skici od muke i da koci.
A celo vreme tebi od tih 5000x5000 px treba jedno parce od recimo 500x500.
zato lepo uzmes rect i namestis ga tamo gde ti treba sa sve velicinom 500x500, i samo se prikaze/renda to parce, manje trosi cpu, manje trosi memorije, i odjednom izgleda brze ;).

Opet, ovo je grubo objasnjeno, ali to je otprilike to.

Jasno, jasno, samo sam pomislio da flash mozda interno to optimizuje i da jednostavno koristi scrollRect sa stageWidth/Height.
Ovako su pravili dve zasebne funkcije koje rade istu stvar.

Ja sam mislio da je najveca bmp 2880x2880 za AS3! Tako pise u helpu. Da li je moguce ucitati vecu bmp od te? A da ta bmp nije u delovima naravno.

Napravio sam animaciju pomeranja 2200x1200bmp slike preko x i y i dosta je brzo. CPU jezgra su na 30% sa 120 fps.
Upravo radim copyPixel animaciju, pa javljam kolika ce biti opterecenost.

Mislis ovo http://laserpirate.com/flashblog/?p=12 ?

Covek je lepo istestirao sve moguce varijante :)

Hmmm, upravo sam zavrsio bmp stage sa copyPixels() :(
Bilo je mnogo lakse nego sto sam mislio.

stageBMP_bmd.lock();
stageBMP_bmd.copyPixels(staza_bmd, stageRect, stageBMP_ZeroPoint, null, null, false);
stageBMP_bmd.unlock();

Cak sam stavio i lock i unlock, da bi bilo kao bolje. Veruj mi kad je isto :( Mozda sada cak malo vise secka :(

Flash nije pravljen za brzinu. Ili ja ne umem da ga ukrotim...

Odoh da citam link. Hvala Vranac!

Od muke cu napraviti i scrollRect, ali vec sad gubim nadu da ce to biti ista bolje.

Procitao link, ali taj covek je merio setPixel. I lose je sto je postigao samo 20fps :(
Ja se zezam sa komadima bmp-a pa mi je i copyPixels potrebniji.

Elem, napravih svoja merenja. Nista nije onoliko precizno koliko bih ja to voleo, ali moze da posluzi.


stage.frameRate = 1000; // za sva merenja.

Debug Flash:

160 fps za scrollRect! veoma stabilno +-10

110-227 fps sa bmp.x ali izdrzava 1000fps bez ogranicenja i fps rapidno varira

100 fps sa copyPixel


FireFox iz html-a:

252 fps scrollRect

161 fps copyPixels , veoma stabilno

155-208 bmp.x,y


Jako je vazno da se ogranici copyPixel i scrollRect kad je Rect_pomerajXY = 0 a stage fps veci od 100! Flash CS3 se zakuca u suprotnom slucaju!

Znaci sada imamo crno na belo da je scrollRect ipak najbrzi. Mogao sam samo da verujem VENGEANCE MX ;)


Vranac, veceras radim load vise BMP-a i njihovo spajanje. Moja trenutna ideja je da napravim praklapanje BMP-a

Tj. da je jedna slika "duza" za stage-1px i da naravno ima sve pixele kao kraj prednodne slike. I onda da samo preskoci na drugu sliku kad Rect dodje do kraja prve.

A druga varijanta mi je da nekako smanjujem jedan Rect na prvoj slici i paralelno povecavam drugi Rect koji bi citao pixele sa druge slike i onda to nekako spojim na stageBMP...

Ima li nesto bolje a da ti znas?

(sto je dobro kad svi spavaju dok ja radim ;)