A teljesítményprobléma megoldása vakuval

Kezdetben a "Mushroom" játék munkája gyorsan és fokozatosan ment végbe. Nagyon elégedett voltam a Flash nemesi technológiájával a könnyű használhatóság érdekében, és tele volt az optimizmussal. De később megrémültem, hogy kiderül, hogy a Flash aligha adja ki a keretek megfelelő számát, ha az objektumok több mint százra kerülnek.

És a játékban egy 20x20 cellás méretű térképnek kell lennie, és még több réteggel is. Vagyis az objektumok a térképen csak egy rétegben legfeljebb 300 darabosak lehetnek. Néhány objektum is animált, ami még rosszabb a teljesítménynél, mert a Motion és Shape Tween animációk programozhatók. És ez azt jelenti, hogy az egyes képkockák nem csak rendereltek, hanem sok számítást végeznek a kódomon kívül, hogy kiszámítsam a MovieClips köztes képkockáit. És még egy ravasz render a Flash-ben, amely csak a képernyő frissített szakaszát redukálja - nem mentette el a helyzetet.

Itt - akkor az optimizmusom kissé elhalványult. Nagyon ideges voltam. Olyan csodálatos technológia, mint a Flash, csak bannerek és primitív játékok számára!

Maga a vektor grafika nagyon bonyolult dolog. Bárki, aki legalábbis ismeri a vektor grafikát, teljesen értenie kell, hogy minden görbét komplex matematikai képletekkel számolnak. És amikor az animációról van szó, akkor nemcsak a pontok tömbjét kell megjeleníteni, hanem görbéket kell rajzolni közöttük, hanem a görbék közbülső pozícióját is meg kell találni a kulcskeretek között. Ezeket a számításokat legalább 25-szer másodpercenként kell végrehajtani a játékhoz. Vagyis kiderül, hogy a számítások költségei maximálisak, és az eredmény nagyon középszerű.

A kimenet minden bizonnyal ott van - elhagyni a vektor grafikák használatát, mindent bitképgrafikákká alakítani. A rasztergrafika segítségével a számítógépek számára könnyebb elvégezni a számításokat és a renderelést, hiszen ez csak egy sor pixel, a legegyszerűbb információkkal. Elkapva magam ezt a gondolatot, féltem egy pillanatra: "Ezért ment el, és végül eljött." Elkezdtem elképzelni, hogyan exportálhatom mindezt egy raszterbe, majd vissza, hogy kézi forgatással készítsem el a MovieClip-et. Ez az, ahol a vektoros grafika összes fő előnye: bármilyen méretű minőség és az adattárolás minimális helyzete - elkezd elhalványulni. De a döntésnek biztosan meg kell lennie.

A Flash van egy speciális lehetőség «cache bitmap», amelyet be lehet állítani az egyes klipek - ez azt jelenti, hogy a klip valahol a memóriában tárolt bitmap, és már nem újratervezi a vektoros képet. Kísérleteim azt mutatták, hogy ez növeli a termelékenységet, de a teljes boldogsághoz nyilvánvalóan nem elegendő. Ennek oka valószínűleg időről időre ezek a "gyorsítótáras" klipek újra frissülnek, ami fékekhez vezethet. És a tárgyak száma továbbra is ugyanaz, ami továbbra is teljesítményproblémákat okoz.

Bevallom, gyakorlatilag nem ismerem a belső Flash eszközt, de a gyakorlati kísérletek során kiderült, hogy a Flash alkalmazásoknál gyorsabban dolgozik egy nagy kép, mint sok apró klip. Gondolom, ez így van, de nem fogom leírni, mert unalmas és unalmas lesz, és talán tévedek a találgatásomban. Csak egy ilyen nagy kép nem tartalmazhat beágyazott klipek tömegét, hanem egy nagy bitképet. Egyszerűen fogalmazva, ha a játék a tervek szerint számos különböző objektumok (klipek), ki kell őket csoportokra osztjuk (előtér, háttér, dinamikus objektumok, és így tovább), majd ha mindegyik „render” egyetlen nagy bitmap, hogy ezt követően háttérként használták, és az összes eredeti objektumot eltávolították.

A teljesítményprobléma megoldása vakuval

Készítsen raszterképet egyszerűen a klipek tömegéből. Azt, hogy az összes klipet a fontossági sorrendben, és ha kell, majd mintha a kamera készít egy képet, ahol egy bitmap, amelyet majd egy anyag formájában a játék szinten. A műveletről részletesen elmondható a Heath példabeszédében.

Ez minden bizonnyal remek, és a hangulatom már javult, mert a teljesítmény nem ravasz módszerek tudna emelni csaknem kettő. De a probléma nem teljesen megoldott, mivel a termelékenység oroszlánrészét még mindig "vektor animáció" fogyasztja. Már kezdtem azt hinni, hogy mi, ha valami, mint az azonos, de formájában egy tömb bitmapek mentse egyes képkockáját MovieClip`ov, aztán, mint a régi szép időkben megjelennek a megfelelő helyen a megfelelő keretet. És nem volt időm arra, hogy ezt a gondolatot a végére emeljék, mivel rájöttem, hogy ez a "kerékpár" már korábban már feltalált, csak a "pedálokat" és a "sidushka" -t kell beállítania.

Vagyis több olyan osztályt találok, amelyek teljesen megoldják a vektoros animáció problémáját, és a megadott klip minden egyes keretét raszteres képek sorozataként konvertálják. És mindent úgy hajtanak végre, hogy végül eljutunk a MovieClip leszármazottaihoz, és együtt dolgozunk vele, mint a megszokott MovieClip, csak a tartalma teljesen raszteres.

A nagyon klasszikus a vektoros animáció átalakítása AS3-as raszterbe való átültetésével itt tölthető le. A forrásarchívumban van egy példa arra, hogyan kell használni.

Hasznos dolog AS3 Bitmap gyorsítótáras animációk :) Köszönöm.
Szeretném megjegyezni, hogy a gyorsítótár bitmapként szerepel.
Az ilyen objektumokat nagyon gyorsan tekintik, de sok korlátozás van a használat során. Ne használja, ha:
változik a film tartalma (belső animáció), a film újra lesz rajta.
A filmet elforgatják vagy kicsinyítik, a film újra lesz rajta.
ha a tárolt kép nagy, és a vektor, ahonnan készült, nagyon egyszerű (egy csomó RAM-ot fog készíteni a bitkép újraépítésére).

Kísérleteznie kell az animációval :)

By the way, heathy egy témát erre.
És adok egy linket ugyanarra a webhelyre, mint amit csak ott adtál, akkor láthatja a tesztet, hogyan működnek a különböző technikák.
1. szétválasztva
2. Keretes képként tárolva
3. gyorsítótárba helyezve

Az első kettő egyértelmű, de a harmadik nem értette. De ez mutatja az átlagos sebességet, mert valószínűleg nem érdemes zavarni.

var someArray: Array = új Array ();
a (var i: int = 0; i .
írunk:
var someArray: Array = új Array ();
var len: int = valamiArray.hossz;
a (var i: int = 0; i .

levelet:
someConditions. eredményt. eredmény

vagy
i = i + 1; változás i ++ -re;

vagy i = i + someVal; Változás i + = someVal;

és így tovább. Azt hiszem, megértettem :)))
)

@ Sasha, a gyorsítótár bitmap - ez így van, alkalmi lehetőség háziasszonyok :) By elve a grafikus és animációs bittérképekre kézzel kell irányítani a RAM használni, mivel anélkül, hogy bármilyen módon ezekben az esetekben. Ha pedig az animációk és a grafikák nagyok, akkor valószínűleg csak a grafika szükséges, amely az aktuális szinthez szükséges, ez a memória és a várakozási időt a játékos számára a játék indításakor;)

@VirtualMaestro, csak ebben a példában csak egy ravasz ajánlatok átalakítani grafika kézzel, amit egyszer van két probléma: ideje váltani bármikor javításokat és súlya a bot.

Bevallom, hogy a spritesheet a gyorsítótárban van, de nem értettem meg teljesen. De úgy tűnt számomra, hogy ez a módszer minden kockát megtörik. Miért nem értettem ezt. Mivel a recepció teljesítménye valóban kétséges, én személy szerint nem zavartam :)

A kód technikai optimalizálását illetően örömmel adok néhány érdekes linket a kód legjavításához:
- Az AS3 alkalmazások teljesítményének növelése
- Hatékony programozási gyakorlatok
Persze csak azt kell szem előtt tartani, hogy ha az összes kódot figyelembe vesszük ezekkel a technikákkal, akkor nem tény, hogy valójában legalább 1-2 fps-t kapunk. Mivel mindentől függ az alkalmazás összetettsége és az egyszerű játékokban / alkalmazásokban, az ilyen trükkök semmilyen hatással sem lehetnek. Ez egyszerűen követi ezeket a technikákat, hogy emlékezzenek és használják a szabványos megközelítés a munkájuk;)

Köszönöm a linkeket különösen a második (az első, ahogy telt el :)), igazán tanultam új módszereket (gondoltam, hogy mindent tudok a tömbökről :) naiv).
Jó munkahelyi kód optimalizálása írt Kris Kaspersky (ott nem csak az optimalizálás művei nem a vaku -. Az alábbiakban a feldolgozók (AFM)) jutott, különösen dolgozni ciklus (söpörni csodák, stb.)
Úgy tűnik számomra, hogy a ciklusok az összes kritikus (és nem csak) alkalmazás egyik legnagyobb problémája.

Ha a konverziós folyamatot flash meghajtóvá konvertálja, a felhasználó nem észlel semmit :)
Szinte minden játékban, a Nitrome így tett :)

Kapcsolódó cikkek