Coś mi się obiło o uszy, że istnieje (chyba konwerter tworzący animacje na z tego formatu na obsługiwany od kilku lat na małe jakiś tam format na małe Atari... Kiedyś dużo takich animacji robiłem, format anm to format z Deluxe_Paint z Amigi, jak i PC ->link<-
Program do tworzenia animacji w formacie Taquart Interlace Pictures (256 kolorów i więcej). Sposób kompresji obrazu jest podobny do tego znanego z FLI, FLC (PC) lub IFF-ANIM (Amiga), z tą różnicą że TIP ANIMATOR nie porównuje pixli obrazu a bajty i to konkretnie w pionowych kolumnach. Jeśli występują różnice pomiędzy kolejnymi klatkami animacji zapisywana jest odpowiednia informacja do pliku wynikowego ANM.DAT i DICXX.DAT. Plik ANM.DAT ładowany jest do pamięci podstawowej (można ustalić jego adres ładowania wraz z właściwym programem dekodującym poprzez podanie parametru PRG$ADRES) i nie może przekroczyć adresu $C000. Pliki DICXX.DAT to słowniki zawierające dane których nie udało się spakować metodą RLE (Run-Length Encoding), ładowane są do banków pamięci dodatkowej standardowo w obszar $4000..$7FFF (adres słownika można ustalić podając parametr DIC$ADRES, dodatkowo wypada podać parametr ONEDIC, tym sposobem uda się jakąś krótką animację zmieścić w pamięci podstawowej), maksymalnie może być ich 64 w przypadku rozszerzenia pamięci do 1MB. Jest tylko jeden bufor obrazu (Graphics 9 - $C000..$CFFF, Graphics 10 - $E000..$EFFF, Graphics 11 - $F000..$FFFF) stąd możliwe widoczne falowania pionowych pasów obrazu w przypadku scen o dużym nasileniu ruchu. Parametry dla których podajemy wartość (PRG, DIC, H, V, DELAY) akceptują zapis heksadecymalny oraz decymalny (DIC8192 lub DIC$2000). Jeśli ktokolwiek planuje zapisanie przy pomocy TIP ANIMATOR-a animacji wcześniej zapisanej jako AVI, MPG czy przy pomocy innej stratnej metody kompresji to powinien poważnie zastanowić się nad sobą i niech potem nie ma pretensji że taka animacja spowoduje przekroczenie limitu długości dla pliku ANM.DAT. Najlepszym źródłem klatek animacji są pliki FLI, FLC, IFF-ANIM, przykładowe pliki JUGGLER, WHEE, MAGICIAN, FROG są tego dowodem. Najkorzystniej poddają się kompresji te animacje gdzie ruch zachodzi tylko w wybranych, stosunkowo niewielkich fragmentach obrazu, szybciej przemieszczają się małe fragmenty, wolniej duże fragmenty obrazu, tekstury są w miarę jednolite dzięki czemu łatwo poddają się kompresji RLE. Przykładowe animacje i dodatkowe informacje na temat programu można znaleźć na forum AtariAge.
I just sent two USB sticks to KAZ (for AOL) and Grey (for SV). One stick contains over 700 TIP animations I collected for the A8 in various formats (XEX, 180k/360k/720k ATR, 16MB ATR MyDOS and 16MB ATR SDFS), as well as sources in GIF and AVI format and all PC tools I used to create these animations.
The other stick contains various A8 sounds (game and demo sounds in MP3 format), various Atari videos (adverts and other stuff from the 80s for 8Bit, 16bit, 32 bit and 64 Bit computers and consoles, videos from Arcade machines, a Futurama special episode and Nolan Bushnell interview), Atari vinyl singles (for promotion), Atari covers (Franklin and others on E-Guitar) and some other stuff.
Hopefully the contents of these two sticks will be uploaded to AOL or another Atari webpage (e.g. pigwa.net)
-----
Besides, TIP animator is limited to 1MB RAM and it plays only videos and animations without sound. Some animations will not work allthough they require less than 1MB, simply because the ANM.DAT file has not enough space left. The maximum resolution of TIP animator is 160x100 pixels, but often you have to use a much lower resolution to get the animation or movie-clip working. Some time ago Avery Lee, the author of Virtual Dub and Altirra, detected a mode that works with SIDE-2 by Candle/Lotharek and IDE+/IDE-2 by KMK (and maybe also with MyIDE), where the Atari can fetch data extremely fast with 350kbytes up to 500kbytes per second. There is even enough time to playback some sample sound. And since the data is coming from a CF-card or a harddisk, an Atari XL/XE computer with 64k RAM would be enough. So, if you want cool realtime videos with sound from the A8, this could be the solution. The topic can be found here: ->link<-
Postaram się to jakoś ogarnąć, tylko do końca nie rozumiem, czy to jest tak, że wystarczy, że do jakiegoś programu wrzucę pliki ^.anm odpowiedniego rozmiaru, a ten program mi przerobi je na animacje odtwarzane w Atari, czy muszę w nich jakoś dłubać.
in the last 2-3 years I have been very active in creating tip-animations with tip animator 2.8/2.9 and tip-animator 2xB. While tip-animator 2xB worked with double-buffering and showed (almost) flicker-free movies and animations, it did have an annoying bug:
When the tip-animation had loaded and completely unpacked, garbage appeared on the screen. While the animation played, more and more garbage disappeared, until it was completely gone, when the animation re-started. I kept those animations and here and there I wrote, that one has to wait for the ani to re-start, then everything will be fine. Nevertheless I asked TeBe if he could fix this annoying garbage-bug in tip-animator 2xB, alas, he could not find or see the bug...
Today JAC! spread some info at atari-age forum about this tip-animator 2xB bug and how to fix it:
"Hi there,
Charlie Chaplin sent me a bunch an TIP animation a while ago (Dec. 2012, huh,... )and mentioned some of them showed garbage during the first iteration of the animation for some unknown reason. Today I found his mail on my todolist (yes, it's looooog) and had a look. The reason for the garbage is that the bank counter variable is not initialized explictly before the animation starts. Due to some memory copying that takes place before this, the value of $8d may or may not be zero at the start (depending on the individual animation). Once the animation reaches the first data in the 2nd bank, the value is updated and everything is fine after this.
So maybe tebe can add "mva #0 bank" to the begin of "tipanm_engine.asm" to fix this.
Because hardly anybody would re-encode the existing animations (well maybe except Andreas with his endless passion and patience;-) ), here also a small fix for the existing ones:
- Copy the .xex file - Append the following bytes to the and of the file using a hex editor or your favourite DOS: $8d $00 $8d $00 $00.
This works for the version the I've seen. Older versions might have a different value then $8d for the bank counter."
So, hopefully we will see an update of tip-animator 2xB (hello Tebe!) with this bug fixed.
