Kolorowe filmy na Atari by Kaz 2008-08-13 19:27:28
Jakim cudem to możliwe? Bo Tomasz "TeBe" Biela oraz Jakub
"Lewis" Kosiec postanowili zastrzelić nas kolejną rewelacją
sezonu w postaci programu TIP Animator. Jak sama nazwa
wskazuje, służy on do tworzenia animacji w trybie TIP - obrazki o
rozdzielczości 160 na 100 punktów. Efekt jest rewelacyjny, co
możecie zobaczyć na poniższych filmikach:
Jak napisał Tomek: "w załączniku program do zamiany plików TIP
(rozmiar 160x100) na animację - pliki DIC?.DAT i ANM.DAT. Animacja
polega na zapisaniu różnic pomiędzy kolejnymi klatkami. Jedyną
pełną klatką jest pierwsza klatka animacji, pozostałe są już
zapisywane jako pionowe kolumny obrazu na podstawie zaistniałych
różnic w treści obrazu. W załączniku także przykłady animacji (plik
MANGA.XEX), który jest ostrzeżeniem przed klatkami animacji
różniącymi się za bardzo. Nie ma buforowania obrazu, obraz
aktualizowany jest w locie."
Download całości tutaj. A nie, bo tutaj. Radujmy się, bo dzień dogonienia
możliwości Amigi już bliski! ;) Kto pierwszy przyśle jakąś animację
zrobioną tym programem?
Kaz 2008-08-13 20:00:04
TIP staje sie bardzo kuszacym formatem do robienia grafiki. Jest konwerter, jest animator, jest program do malowania, ktory korzysta z myszki PC... sikor 2008-08-13 20:31:38
Jeszcze poprosimy o możliwość dodawania dźwięku i możemy mieć całkiem przyjemny format do animowanych filmów. W końcu na 16MB partycji (albo 32MB, w przypadku najnowszej sparty) można by zmieścić już całkiem pokaźne filmiki. A i pojemność nowych kart/urządzeń byłaby bardziej wykorzystana ;) tebe 2008-08-13 20:58:18
klatki animacji były konwertowane przy pomocy TipConv 1.0.0 Epi-ego (wymaga Javy), Lewis został wplątany za kod wyświetlający Tip-a Kaz 2008-08-13 21:12:30
Czyli glownym sprawca jest Tebe, dran jeden! :)
To moze dogadalbys sie z Epim co do polaczenia algorytmow konwertera TIPconv z TIP Animatorem, dodalbys do tego to, co obecnie robi tylko LePix na Atari czyli edycje TIP-a i wmontowal to w G2F albo osobno, zeby powstal kolejny bezwglednie rzadzacy program? :) tebe 2008-08-13 21:20:39
kod Tip Animatora jest bardzo prosty, tak że Epi nie miałby problemów z przełożeniem tego na Jave, bo odwrotna kombinacja przekładanie Javy na Delphi i to w takiej ilości byłoby conajmniej uciążliwe, inna możliwość to rozszerzenie funkcjonalności programu Epi-ego o obsługę linii komend, tak aby Animator wywoływał jego konwerter z odpowiednio spreparowanymi parametrami _rocky 2008-08-13 22:31:05
Innym majstersztykiem tebe jest silnik w X demo... piotr 2008-08-14 00:08:10
rewelacja! CharlieChaplin 2008-08-14 00:10:14
So, assuming someone has large XRAM or a harddisk available for the A8, one can produce a long film (with hundreds or thousands of converted TIP pictures) ?!? Or are there some restrictions within TIP Animator that make this impossible ?!?
I know these nice "films" from the MyIDE by Sijmen Schouten (the Matrix, Southpark, Spongebob and others) and it would be really nice to have something similar in TIP format...
-Andreas Koch. Ciekawski 2008-08-14 00:27:18
TeBe - 1. ile maksymalnie KB może mieć film? 2. Ile maksymalnie może mieć klatek? 3. Ile jest maksymalnie klatek na sekundę? 4. Czy zależy to od ilości zmian w stosunku do nastepnęgo obrazu? 5. Czy możliwe jest dodanie dźwięku, nawet kosztem zwolnienia animacji? tebe 2008-08-14 00:49:31
dane ładowane są do pamięci dodatkowej (przykładowy BUGS nie korzysta z pamięci dodatkowej, JUGGLER potrzebuje 64KB dodatkowej, WHEE i MANGA potrzebują 6 dodatkowych banków) więc ograniczeniem jest tylko ilość pamięci dodatkowej, procesor zajmuje się przerzucaniem danych pod właściwe adresy obrazu, jeśli zaangażować do tego HDD pamięć dodatkowa pewnie nie byłaby potrzebna
JUGGLER, MANGA, WHEE działają z pełną szybkością, tempo animacji wyznacza ilość danych potrzebnych do uaktualnienia obrazu, BUGS jest spowalniany oczekiwaniem na 4 ramki (4* 1/50sek)
MANGA to przykład gdzie różnice pomiędzy następującymi po sobie klatkami animacji są tak znaczne, że przesyłane są prawie całe ekrany a to oznacza widoczne spowolnienie
nie ma buforowania pamięci obrazu, jest tylko jeden 12KB bufor, dane obrazu uaktualniane są bezpośrednio, więc jeśli danych jest za dużo wówczas można doświadczyć widocznego efektu "rysowania" obrazu
aktualnie ROM i OS jest włączony, muzykę można dodać, trzeba tylko zadbać o synchronizację z obrazem Kaz 2008-08-14 03:18:34
Charlie - According to TeBe's words: it means this version is limited by XRAM only and doesn't use HDD. However, HDD version is relativly easy to make (no XRAM usage) and I hope TeBe will give us an evidence :). Music/sound is possible too, but needs to be synchronized with image.
I think that full quality movies are not possible because framerate is variable, depends on data volume to be changed (the more image data to change - the slower animation, look at MANGA.XEX - Tebe's illustration of this problem). It is perfect for movies where only part of picture is changed at time.
Now I dream about TIP universal util created by mixed TIP converter, TIP Animator and LePIX (the only TIP drawing editor) :). xxl 2008-08-14 08:13:50
wreszcie cos swierzego na atari :-) wydaje mi sie ze niezle by bylo, zeby mozna bylo sterowac szybkoscia (zmian) klatek animacji to by wymagalo aby po kazdej klatce byl znacznik opoznienia, pozwoliloby tez uniknac naglych przyspieszen jesli jest mniej danych do przekopiowania w ktorejs klatce - na filmiku bugs tak jest - chyba ze to zamierzone? irwin 2008-08-14 09:39:51
Może by tak wydębić ;-) od Naveed'a algorytm, źródła kompresji opartej o wektorową kwantyzację (np w kodeku Intel Indeo 3.2 i paru innych) Pozwoli to na znacznie lepsze upakowanie danych, czyli więcej klatek animacji w pamięci. Zaś dekompresja jest na tyle szybka że wystarcza 1mhz 6502 w ... C64 a tym samym powinny zniknąć te efekty występujące w np manga.xex gdyż cała dekompresja jest zorganizowana niezależnie czy zmiany dotyczą 1% ekranu czy klatki różnią się dosłownie w 100%. - co zresztą widać na poniższym demie. Wedle autora: "I have developed a video compression format which allows 25frames per second Vector Quantisation decode on a 1mhz C64!" "Around 40 true frames are packed into the memory of this part and uses only around 16k of data when packed further." (taki whee.xex ma na moje oko zdaje się około 15 klatek)
Korzystając z wyżej podanego sposobu kompresji można by uruchomić wszystkie te animacje tj Bugs, Jugler, Whee i Manga na standardowym 64kb Atari a i jeszcze zostałoby pamięci na jakąś muzyczkę oraz... dalsze animacje. xxl 2008-08-14 09:54:46
irwin jest tylko maly problem... na atari mozesz zdefiniowac o polowe mniej ksztaltow w zestawie znakow irwin 2008-08-14 11:23:49
Wyżej zrobiona metoda kompresji opracowana przez Tebego też nie korzysta z zestawu znaków. Oczywiście pewnie próba użycia algorytmu Naveed'a bez znaków spowoduje jakieś obniżenie wydajności, zwiększenie zapotrzebowania na pamięć - ale pytanie brzmi o ile. Jeśli by zeszło się z 25fps z C64 do np 8fps to i tak byłoby super. A różnica pomiędzy kompresją wektorowej kwantyzacji a opartą na zapisie różnic pomiędzy kolejnymi klatkami (Tebe) jest kolosalna - pewnie jest to rząd wielkości koło 10 razy. A to jest nad wyraz istotne przy pamięci rzędu 64kb. Nie jestem programistą, ale ta różnica spowodowałaby że zamiast jedynie ciekawostki (tym niemniej brawo! dla autorów) jak obecnie, możnaby rzeczywiście korzystać z filmowych, renderowanych wstawek np w grach.
Kluczem jest fakt że procesor 6502 1mhz potrafi dekodować w 25fps na C64 wysoce skomplikowaną kompresję z którą (oczywiście w znacznie wyższych rozdz. kolorach i stopniu komplikacji) nie daje rady np 286. Nigdy by nie przypuszczał że to możliwe, a jednak. Skoro więc C64 potrafi to mam nadzieję że i Atari choćby w jednej trzeciej prędkości - ale za to np lepszych kolorach vide TIP. Najistotniejszy jest tu dekoder wektorowej kwantyzacji który jest możliwy do użycia na 6502. Reszta czyli sposób jego użycia, wyświetlenia jest oczywiście sprawą ważną, ale drugorzędną - oczywiście ja piszę to z punktu laika programistycznego i może na tym etapie pojawić się jakieś wąskie gardło Atari i wtedy zima. Ale jeśli chcemy mówić o animacji na Atari będącej czymś więcej niż ciekawostką, to właśnie kompresja stratna jest kluczem (kompresja Tebego jest bezstratna w związku z tym pamięciożerna) dhor 2008-08-14 12:48:12
Prawdziwi videofile mówią zdecydowane NIE kompresji stratnej na atari!
A program fajny, przydałoby się gui w Javie (multiplatformowe). irwin 2008-08-14 13:10:27
A to dlaczego? Ja tam wolę filmik który zajmie np 40kb i odpali się na gołym Atari niż taki który zajmie 400kb i trzeba mieć 512kb Ramu.
na Pc też wszystko masz rawie i np 2godzinny film w rozdz dvd zajmuje u ciebie jedynie 208gb (dzwięku już nie doliczam bo to grosze) ;-) sikor 2008-08-14 13:15:51
@Irwin: "eśli by zeszło się z 25fps z C64 do np 8fps to i tak byłoby super" oraz: "Skoro więc C64 potrafi to mam nadzieję że i Atari choćby w jednej trzeciej prędkości" - proszę, przeczytaj jeszcze raz, co napisałeś. 8fps to 3 razy szybciej, a nie wolniej!!! (fps - Frame per second). Oczywiście, ze się da - co więcej, playerek dla 16-tu barw pokazywał w zeszłym roku Epi na Głuchołazach. Zauważ, że tu mamy 256 kolorów, a znając TeBego - prace trwają nadal... ;) Kaz 2008-08-14 13:22:16
Eee, chyba 8 klatek na sekunde to nie jest trzy razy szybciej niz 25 klatek na sekunde... :) Kaz 2008-08-14 13:31:31
Poza tym cala dyskusja zmierza w zla strone - to nie jest problem CO ZAMIAST CZEGO - oba rozwiazania moga istniec rownolegle i prezentowac rozne mozliwosci Atari. irwin 2008-08-14 13:39:36
@sikor - zadanie wykonane: przeczytałem. I nadal uważam że 8 to mniej niż 25. ;-) Zresztą jak widzę Kaz również nie popiera twojego śmiałego projektu matematycznego ;-)
Playerek, playerkiem na youtube jest film pokazujący odtwarzanie całego trailera filmu Matrix na Atari i z dzwiękiem. Problem w tym że bezstratnie i zajmuje to całe megabajty danych absolutnie nie do użycia w normalnym użytkowaniu (na jednej 180kb zmieści się z 2 sekundy filmu). Natomiast gdy się użyje wyżej zapodanej kompresji można by było nagrać na tych samych 180kb około 45-60 sekund filmu. A to już jest użyteczne w sensie wykorzystania np grach. Pozostaje pytanie czy ten playerek Epiego korzysta z bezstratnej kompresji jak powyższy Tebego czy też używa czegoś rewolucyjnego w rodzaju playera Naveed'a. Tj czy to kolejna ciekawostka jak player Tebe, czy http://www.youtube.com/watch?v=owHCjEWjAvs czy też coś co spowoduje że realnie stanie się np filmowe czy renderowane intro przed grą mieszczącą się na jednym dysku. irwin 2008-08-14 13:42:49
@Kaz - masz całkowicie rację - Moim celem nie była krytyka a pokazanie jedynie linka i naświetlenie pomysłu. Internet internetem, nie każdy może znać tę stronę i metodę w niej zawartą. irwin 2008-08-14 13:49:27
Dzięki takiej wymianie informacji, może jakiś guru w rodzaju (pokłony on) xxl, tebe, epi itd (pokłony off), przyjrzy się temu i powie "to da się zrobić, nie będziemy gorsi od tej mydelniczki C64, w końcu mamy po odjęciu czasu który zjada nam Antic jakieś około 0,2mhz więcej niż ten C64" tebe 2008-08-14 18:41:13
grafiki w stylu TIP, RIP itp. które wykorzystują przerwania DLI co linię "zjadają" blisko jedną całą ramkę na dzień dobry
kompresję stratną bardzo prosto uzyskać wystarczy n-krotnie pomniejszyć rozdzielczość ekranu, czy też jakiegoś wycinka obrazu, w ten sposób 1 klatka obrazu może zajmować parę bajtów jeśli nie jeden :)
intro Vasco wykorzystuje kompresję stratną do wyświetlania HIP-ów, obejrzyjcie je i napiszcie jak bardzo podoba się Wam kompresja stratna na Atari :) tebe 2008-08-14 18:42:05
Niezle! Jak na kompresje stratna to strata jest niewielka :). A pamietac trzeba, ze film to nie to samo co statyczne obrazki - skoro wiec statyczne obrazki wygladaja niezle, to ruchomy obraz bedzie sie wydawal jak brzytwa... jestem za! :) tebe 2008-08-14 19:48:38
jest pewne ALE, ta stratna kompresja dotyczy obrazu w odcieniach szarości, chodzi o zmiany jasności pomiędzy pixlami, podbijamy jasność o 1 aż do uzyskania docelowego stanu, nie ma mowy o gwałtownych przejściach jak ma to miejsce w kolorowych obrazach irwin 2008-08-14 20:15:33
@tebe - masz rację, można iść drogą n-krotnego zmniejszania rozdz. można też zmniejszać liczbę klatek na sekundę., kolorów. Przykładowo na początku lat 90-tych na PC, Apple kodeki typu Cinepak, MSvideo przy rozdz 320x240 aby obraz był dość dobry wymagały transferu danych na poziomie 600kb-1mb na sekunde. Idąc tą drogą dziś filmy w rozdz dvd musiałyby mieć transfer w okolicach 3-4mb na sek. Ale dzięki zwiększeniu szybkości procesorów można użyć wydajniejszej kompresji a tym samym przy podobnej jakości transfer znacznie spadł i podobnie jakościowo film w h264 w stosunku cinepak wymaga 10-30 razy mniej.
Podobnie jest na 8bit - gdy nagle ktoś udowodnił że można zrobić coś co w teorii nie powinno chodzić, to warto pojść tą drogą. Zamiast zmniejszać rozdz. liczbę klatek na sekundę to dzięki użyciu odpowiedniego kodu, algorytmu spowodować zmniejszenie samego pliku (bo oto tu na atari głównie chodzi - nikt nie oczekuje cudów HDTV i ac3 ;-)
Jeśli Tip czy Hip zajmują tak dużo czasu na samo wyświetlenie, jak piszesz - to może obraz w odcieniach.
Co do tego demka: po pierwsze "intro Vasco wykorzystuje kompresję stratną do wyświetlania HIP-ów" - nie ma czegoś takiego jak piszesz tj przy wyświetlaniu. Kompresja stratna odbywa się przy encodowaniu, pakowaniu obrazka, filmu czy dzwięku. Gdyż chodzi tu oto aby dany plik zajmował jak najmniej, przy określonej jakości. Tak więc możesz sprecyzować jaka to kompresja i czy takowy plik Hip różni się od zwykłego Hipa? po drugie - ja też jestem za, tylko że to nieruchome obrazki i ich jakość jest aż za dobra, i wiem że gdy zamiast nieruchomych parunastu obrazków będziemy chcieli mówić o parunastu sekundach video to absolutnie nie zmieścimy się w pojemności dyskietki. A przy metodzie którą reklamuje ;-) byłoby to możliwe.
Aha - Tebe - i tak to co robisz to świetna robota, praktycznie do tej pory ten temat (animacja) leżał odłogiem. Wreście coś ruszyło i dlatego rzucając tym linkiem chciałem coś pomóc. Po prostu tak jak dziś nie mamy playerów audio 4-5 bitowej kompresji adpcm a mp3, czy nawet bardziej zaawansowane aac (w szczególności he-aac ps) tak może warto zamiast prostej kompresji"różnic pomiędzy kolejnymi klatkami" użyć zaawansowanej "wektorowej kwantyzacji". Procesor 6502 stwierdził że temu zadaniu podoła ;-) i nie przestraszy się jej jak Wisła Barcelony. ;-) sikor 2008-08-14 20:26:37
@irwin @kaz: macie absolutną rację... Mea culpa - tak to jest, jak się na chwilę wyskoczy z pracy i looknie na atarionline.pl. Tylko jedno ale: do w miarę płynnego oglądania potrzeba conajmniej 12fps, mniejsza ilość to już katorga przy oglądaniu... Także 8 - to ciut za mało. Poczekamy, co TeBe jeszcze wymyśli... tebe 2008-08-15 20:05:25
ok, w nowej wersji udało się zwiększyć stopień kompresji, tak że taki Whee uruchamia się na conajmniej 130XE, w pozostałych przypadkach też zostało parę banków zaoszczędzonych tebe 2008-08-15 20:23:48
wersje 1.3 można pociągnąć z www.atari8.info tebe 2008-08-15 22:40:49
sporo animacji do przerobienia http://www.randelshofer.ch/animations/ menel 2008-08-15 23:43:52
na comodzie idze takie cos i z tego co widze o wiele bardziej plynne i dynamiczne http://pl.youtube.com/watch?v=knZyPXcelYM tebe 2008-08-16 00:01:10
to jest z kategorii Wild Demo i jakoś nie widze tego na prawdziwym C64 w formie programu, ponagrywali scenki i złożyli w całość na PC, w każdym razie do obejrzenia tylko w formie AVI na PC, http://pouet.net/prod.php?which=50183 tebe 2008-08-16 00:08:29
tutaj wyjaśnienie jak to działa http://noname.c64.org/csdb/release/?id=64233 musicie mieć C64 z HDD i CDROM-em :) irwin 2008-08-16 11:40:41
Także tutaj jest tego typu ciekawostka http://www.pouet.net/prod.php?which=19205
@menel: poczytaj wszystkie komentarze a przekonasz się że na C64 możesz mieć i płynnie i dość dużo sekund bez udziału HDD i CDROMu irwin 2008-08-16 12:11:25
@tebe - świetnie że rozwijasz program - tak trzymaj. Silna kompresji to podstawa, szczególnie na Atari. Cy'5 2008-08-19 19:40:36
Jestem w szoku tebe 2008-08-24 17:34:25
http://madteam.atari8.info/index.php?prod=uzytki
na samym końcu strony mono 2008-08-24 22:07:49
Rewelacyjna rzecz. A tego robocika widziałem tylko w wersji b/w. To teraz można robić animowane wstawki w grach :) maly_swd 2008-08-25 15:08:41
@tebe - Super sprawa - a czy dałoby się zrobić tryb wyświetlania w odcieniach szarości, tj nie TIP a normalny tryb Atari bez interlace? tebe 2008-08-25 18:23:03
można przez G2F -> EDIT MAPS -> Export as animation pin/trs 2008-09-14 21:24:09
... KAZ - czy zamiast *.7z możesz używac po prostu normalnego starodawnego *.zip?? mono 2008-09-15 02:31:59
E no pin. Robi się po prostu $ 7za x plik.7z :) Kaz 2008-09-16 16:22:00
Pin, moglbym, ale nie widze sensu takiego dzialania. Do 7z sa darmowe i sprawne narzedzia, a jest wydajniejszy niz zip. Co mialoby przemawiac za tym, zeby stosowac zip?