JS uvádí - animace

Pro případné zájemce se zde pokusím popsat pár svých zkušeností s animací. Nevím zda všechno, o čem tu budu hovořit má obecnou platnost, neboť jsem dosud pracoval jen s CyberPaintem.

Po prvním, zevrubnějším seznámení s CyberPaintem (dále CP) mě uchvátila možnost animace jako taková. Mj. také díky snadnosti s jakou lze animace v CP dělat. Je to hezký pocit, vdechnout nehybnému obrazu život (pohyb) a děj. Záhy jsem však narazil na nedostatek paměti. S 0,5 KB RAM mi na vlastní animaci v paměti zbylo něco kolem 40 kB. I tak se dá vytvořit něco pěkného, ale k náročnější práci to nestačí. Po rozšíření na 1MB to už bylo o něco lepší, ale za chvíli to bylo taky málo. Rozšiřovat paměť již nehodlám. Nezbývá než šetřit místem.

CP ukládá animaci jako první frame a pak už ukládá jen změny. Tj. když má pixel o souřadnicích xy na framu 2 stejné číslo barvového registru (dále b.reg.) jako na framu 1, není to žádná změna. Z toho vyplývá - čím více změn, tím větší nároky na paměť. Maximální změna tedy je když 320*200 pixelů framu 2 je vybarveno barvami z jiných barvových registrů, než frame 1. Každý bod z 320*200 o souřadnicích xy obsahuje barvu z jiného registru, než předcházející frame. To je množství dat. I přes to, že CP data ještě dále komprimuje. Můžete si to ověřit v CP volbou status.

V CP (v.2.0) je řešením používat kde to jde tzv. barvové rotace. Myslím, že toto umožňuje také Degas Elite , nevím jestli Deluxe Paint a CP to umí od v.2.0. CP 2.0 umožňuje nastavit si v každém framu pomocí RGB jinou barevnou paletu. Pokud jsem dělal animaci v CP 1.0, musela být paleta pro celou animaci stejná, takže jsem třeba pro efekt stmívání musel použít funkci separate. Nahradil jsem barvu pixelů z jednoho b.reg. jinou (tmavší) z jiného b.reg. ze 16 pevně nastavených. Nyní pouze změním (pomocí RGB) barvu v danném registru. Nakreslím si pouze jeden frame s použitím všech 16 barev. V tomto obrázku jsou obsaženy již všechny změny, jako když několik framů se všemi fázemi animace nalepíte na sebe. Změny jsou odlišeny jiným b.registrem. A nyní již v každém dalším framu žádné pixely do obrázku nedoplňujeme, ale pouze si hrajeme s nastavením RGB registrů. Místo změny mnoha pixelů v daném framu měním jen RGB nastavení 16 b. registrů (méně dat).

RGB můžeme v jednotlivých framech měnit ručně, když však chceme jen jednoduchou rotaci barev CP(2.0) nám toto umožní provést automaticky funkcí shift-color f/x (viz obr.). Náš animační obrázek složený z pěti fází namnožíme do 5 framů. V horní liště vpravo nastavíme s (segment) nebo a (all frames) a pod tím ještě t. Pokud zvolíme s musíme ještě definovat segment a jeho směr šipkou A. To znamená na kterém framu segment animace, v němž se bude něco renderovat, začíná a kde končí. Pak si nastavíme šipku B - tj. kolik b.registrů se bude rotace účastnit a v jakém směru rotace poběží. Nastavením FPsh určíme o kolik registrů se budou barvy posouvat (krok rotace). Pak už si jen můžeme zkontrolovat správné nastavení funkcí previev a nakonec spustit render. V menu color f/x, kde toto vše provádíme, je ještě mnoho dalších možností s kterými můžeme rotaci kombinovat, napříklat stmívání, zjasňování atd. Ale to si již zajisté vyzkoušíte sami metodou pokusů a omylů.

Jistě jste si všimli krátké animace v Narsilu při loadingu a Esc. Zde je použit přesně týž princip. Prostě jsem Headovi poslal 1 obrázek PI1 a k němu asi 12 palet COL. Ve skutečnosti jsem mu to poslal ve tvaru SEQ, a on už si s tím poradil. Tímto mu děkuji, že si dal tu práci a vše do Narsilu nějak zamontoval. Jestli jsem se dopustil nějaké nepřesnosti při popisu práce CP, ať mě opraví. Také zdravím M. Hejrala, autora nejrychlejšího SEQ. přehrávače všech dob. Snad by mohl k problematice SEQ animací také mnohé dodat.