Miért használják a storyboardokat a 2d játékban, ahelyett, hogy az animációs verem túlcsordulna az orosz nyelvben?

• nagyon korlátozott színpaletta: általában 256 szín, rossz simítással. (igen, több mint 256 színt használhat, de ezek nagyon ritkák)
• A GPU-k nem támogatják a tömörítési (tömörítési) GIF-t. és ez azt jelenti, hogy az egyik vagy másik módon ki kell csomagolni és ugyanakkor a CPU (CPU)
• Az átláthatóság érdekében csak ONE színt használhat (hacsak nem hajtja végre az egyéni feldolgozást)
• nincs véletlen hozzáférés: a helyes GIF keret eléréséhez - el kell olvasni és dekompressálni az előzőt
• a kódban speciális funkcióval kell rendelkeznie a dekompresszióhoz. Nem választhat más (jobb) tömörítési algoritmusokat (igen, tömörítetlen GIF-ek is léteznek, de ezek nagyon ritkák)
• nem támogatja a vektoros grafikákat.

Ha együttműködik a formátummal, akkor minden probléma gyorsan megoldódik. A képformátum, a minőség, az átláthatóság, a véletlen hozzáférés és a tömörítés (beleértve a GPU-t támogató DXT-t is) nagyobb mértékben szabályozható. Ezenkívül meghatározhatja a szükséges funkciók prioritásait.

Egyesek úgy vélik, hogy a GIF-nek előnye van a sprite lapoknál, látszólag nem kell aggódnia, hogy a keret túl gyors vagy túl lassú lesz, és megpróbálja kiegyenesíteni a kód sebességét. De ez nem így van. A GIF animáció és szinkronizálás képkockájának szinkronizálása a sprite lapok animációjával nem sok más. Mindkét esetben ismerni és manipulálni kell a keretek listáját, beállítani a kívánt képsebességet és együttműködni a renderelési eseményekkel (renderelés). GIF - nem teremt mágiát, a cél elérése érdekében mindenképpen ki kell csomagolnod a GIF-t a sprite-listára.

Talán az egyetlen hely, ahol nem kell aggódnia a felvételekről a HTML / CSS GUI. de nagyon ritkán is használják őket. Nos, erőforrás-igényesek

És ha a karakter gyorsan mozog, akkor lassan (például lassú mo). És ha a karakter ami egy sor támadások (kombók) és a stop minden egy sor fúj, és az egyes animációs megszakította kombinációja saját (például a kombináció: UMK3 végső - Liu Kang - 4-D rúgások lábak visszaút Animáció - más.). Kérdés: vágj mindenféle GIF kombinációt.

Továbbá, hol kell megtenni a hyphal animáció reprodukcióját? A játékban van egy folyamat, amely átírja a jelenetet. Kb. 60-szor másodpercenként (plusz / mínusz). Hol kell elhelyezni a GIF-t. hogy elindítsa az animációt ugyanarra a pontra, ahonnan a jelenet renderelése után megszakadt? Vagy hogyan kell szinkronizálni? Mindez nagyszerű fejfájásba kerül.

egy kis fordítás gamedevSE-vel

A kérdés helytelen. Nincs kölcsönösen kizáró mód a "storyboarding" és a "GIF-animáció" számára. Nincs "de nem". Ezek ortogonális fogalmak. Helyesen tette fel a kérdést:

Miért nem tárolja a 2D-s storyboardok egy forgatókönyvet GIF formátumban?

A storyboard több kép (általában animációs képkockák), amelyek mind ugyanabból a textúrából (egy "bájt" síkból) és egyebekből állhatnak. A grafika elrendezése egy textúránál opcionális, de van néhány előnye, például a racionálisabb hardver-optimális textúrák méretezésére.

A GIF a lemezen tárolt adatok tárolására szolgáló formátum. Feltételesen kereteket és késleltetéseket tartalmaz köztük, de általában véletlen formátumú, line-by-line adattárolással és különböző keretek közötti váltáshoz (pl. Ez a formátum semmi köze ahhoz, hogy a modern hardverek modern számítógépein megjelenjenek adatok.

Néha úgy tűnik, hogy a GIF "csak működik". Ez nem így van. A programok belsejében vannak olyan összetevők, amelyek kivonják a képkockákat a hardver nézetbe és az algoritmusok szerint az időzítőn megjelenik a képernyőn.

Amikor játékot írsz, magad mindent irányítasz. Nincs több különálló "animáció", minden objektumnak egyértelmű állapota van, az elemek összes képkockája mellett minden egyes ponton minden egyes keretben. Teljes ellenőrzés alatt áll, hogy az animáció melyik keretét jeleníti meg, amikor elindul a futás után.

Jelenleg a GIF animáció használható a storyboards-hoz, de ez ritkán történik a GIF formátum szörnyű korlátai miatt. amelyek szerepelnek egy másik válaszban.

A mai világban a formátumokat általában használják, hogy a grafikákat közvetlenül a hardveren tárolják. Ez lehetővé teszi, hogy a letöltés nagyon gyors legyen, de elég sok memóriát igényel, mert a tömörítés gyenge. Néhány játék alternatív módon is megy, például a Braid tárolja a JPEG grafikát és az átláthatósági csatornát egy külön fájlban. Ha szeretné optimalizálni a lemezterületet a feltöltési idő feláldozásával, és a grafika a legjobb tömörítés a GIF-vel, és veszteség nélkül, akkor a GIF használatával az animációs keretek tárolása racionális lehet.

Külön figyelmet kell fordítani a HTML alapú motorokra. A GIF tényleg ki van kapcsolva a dobozból. Azonban még a GIF korlátozások továbbra is érvényesek: mind a formátum korlátozása korlátozott paletta formájában, mind pedig a korlátozások nyomon követése a gibleteknek a jelenlegi kereten belüli hiánya miatt stb. Még a HTML-ben is, a GIF használatával nagyon korlátozott esetekben van értelme: ha a kép tökéletesen illeszkedik a formátumkorlátokhoz, és pontos ellenőrzésre nincs szükség. Ez ritkán történik, összetett játékokban - soha.