Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorxeen
   • CommentTime11 Dec 2009 19:12

    
   Jaki programik do edycji duszków/pocisków polecicie - tak aby wygenerować pliczek, który można potem swobodnie wczytać do pamięci? Jest coś na piec'a czy też lepiej to robić "natywnie" na Atari?
   Ponieważ (z tego co zdołałem się zorientować) przesuwanie duszków w pionie nie jest takie oczywiste czy macie może jakąś gotową procedurę w języku maszynowym, którą można sobie wczytać do pamięci i uruchomić z poziomu języka wyższego poziomu? znalazłem coś u Zientary - może jest to gdzieś przepisane i można skorzystać?
2. • 2:
      
     CommentAuthorMaW
   • CommentTime11 Dec 2009 20:12 zmieniony

    
   W sumie można się zastanowić, czy coś nowego nie napisać - przesuw z buforem nie jest tak wydajny, jak przekopiowanie duszka z osobnego miejsca pamięci i skasowanie bajtów w ilości różnicy nowej pozycji y do poprzedniej pozycji y - to pozwala też od razu na podmienienie na kolejną klatkę duszka, a więc nie tracimy dodatkowego czasu na przesów bo czas ten i tak byśmy wykorzystali na kolejną klatkę animacji.
3. • 3:
      
     CommentAuthormiker
   • CommentTime11 Dec 2009 20:12

    
   Tutaj leży jakaś procka dla (Turbo) BASICa z objaśnieniem: ->link<-
4. • 4:
      
     CommentAuthorMaW
   • CommentTime15 Dec 2009 12:12

    
   Miker, za dużo treści :-).
   
   Mam jedno skomplikowane pytanie: chcę uzyskać osiem dwukolorowych, (+3ci kolor z nałożenia bitów) animowanych(i ruchomych) duszków, które mogą się nakładać - da się ? :D
5. • 5: CommentAuthorgorgh
   • CommentTime15 Dec 2009 14:12 zmieniony

    
   da,pod warunkiem, że naraz w 1 poziomej linii będą tylko 2 dwukolorowe duszki.
6. • 6: CommentAuthortebe
   • CommentTime15 Dec 2009 18:12

    
   no chyba że z interlacem jak Crownland, made by Probe
7. • 7:
      
     CommentAuthorMaW
   • CommentTime15 Dec 2009 22:12

    
   żebykażda gra miała taki interlace przy takiej jakości to by było dobrze :-)
8. • 8: CommentAuthormono
   • CommentTime19 Dec 2009 02:12

    
   Na którymś z ostatnich serious'ów Zenona jest coś do edycji pmg.
9. • 9:
      
     CommentAuthorKaz
   • CommentTime5 Jan 2010 02:01

    
   Zapowiada sie, ze bedzie tez cos pecetowskiego do edycji duszkow. Dearhorse, ktory pracuje tez nad edytorem grafiki ST (pisalem o tym tutaj: ->link<- ), ma tez w planach edytorow duszkow dla malego Atari.
   
   Jak dowiedzial sie Irwin, ktory podeslal ta informacje - praca wre. "Gr-Editor" bedzie obslugiwal tez tryby GTIA (Emkay, do you hear that? :)) i opcje do animacji duszkow. Calosc ma sie zwac "Atari800tools" i bedzie zawierac - co widac na screenshocie z wersji alpha - rowniez edytor znakow "Char-Editor", a takze "DL-Editor" do tworzenia wlasnej Display List, ktora potem bedzie mozna wykorzystac w "GR-Editor"; ponadto "PM-Editor" do edycji duszkow z opcja DLI. Po prostu fajny kombajnik.
   
   
10. • 10:
       
      CommentAuthorxeen
    • CommentTime5 Jan 2010 17:01

     
    no, no
    czekamy
11. • 11:
       
      CommentAuthorMaW
    • CommentTime21 Jan 2010 10:01

     
    odświeżam:
    
    Jeden duszek w pojedyńczej szerokości zajmuje 16px ekranu w GR.8.
    
    Czy jest możliwe, aby co 16px (*8 cykli koloru, 2 znaki itd. itp.) przesunąć wszystkie duszki naraz, by pokryć nimi cały obraz, przy okazji zmieniając adres pamięci duszków i zawartość rejestrów kolorów raz na linię ?
12. • 12: CommentAuthorirwin
    • CommentTime21 Jan 2010 17:01

     
    Podejrzewam że jakby to było możliwe to Tebe by to wprowadził do Graph2Fonta. W końcu tą drogą można by mieć 8 kolorów w linii bez żadnych ograniczeń. Ale najlepiej jakby wypowiedział się ktoś kto siedzi w temacie.
13. • 13:
       
      CommentAuthorRastan
    • CommentTime21 Jan 2010 18:01

     
    mnie udało się powielić duszki w linii w gr. 8, oczywiście w Graph2Font w programie rastra. niestety ta opcja nie jest jeszcze obsługiwana prze G2F, więc musiałem zapisywać taką grafikę do pliku .xex i oglądać pod emulatorem.
    efekty zaprezentowałem w obrazkach Xenon i Kung-fu Master.
    TDC kiedyś pokazywał mi na party, że wyświetlił chyba 10 czy 12 duszków w linii (duszki oczywiście w zwykłej szerokosci).
14. • 14: CommentAuthorirwin
    • CommentTime21 Jan 2010 19:01

     
    A mógłbyś zamieścić owe pliki g2f z tego Xenon i Karateki, tak aby można było zobaczyć różnice w stosunku do tego co daje emulator.
    Czy da się takie hece zrobić w trybie pixla 2x1?
15. • 15:
       
      CommentAuthorMaW
    • CommentTime21 Jan 2010 20:01

     
    To ja mam prostsze pytanie: żeby uzyskać podkolorowane 320x192 jakie jest najprostsze rozwiązanie ? Mona męczyłem na gg, ale nie wymiękł - 80px duszki 1:1 dałby radę, ale co z pozostałymi 20 pixelami ? zależy mi bardziej na szerokości niż wysokości podkolorowania.
    
    Multiplexer x4 ktoś dałby radę napisać ?
    
    Bez nakładania się, duszek obok duszka, pocisk obok pocisku...
    
    ...bez żonglerki kolorami...
16. • 16:
       
      CommentAuthorRastan
    • CommentTime21 Jan 2010 23:01

     
    Irwin: jutro dodam pliki g2f z grafikami. jeśli chodzi o tryb 2x1 to oczywiście da się ale tylko w trybie GED--.
    
    Maw: jeśli chodzi o przykrywanie obszaru duszkami w 320x192 to jest jeden problem, możesz powielić ich liczbę, ale te powielone mają taki sam wzór jak oryginały.
17. • 17:
       
      CommentAuthorMaW
    • CommentTime22 Jan 2010 07:01

     
    no to jest faktycznie problem :/
18. • 18: CommentAuthorirwin
    • CommentTime22 Jan 2010 16:01

     
    @Rastan
    A w owym GED-- też wszystkie powielone duszki będą miały taki sam wzór i kolor?
19. • 19:
       
      CommentAuthorMaW
    • CommentTime22 Jan 2010 21:01

     
    Rastan: a gdyby inkrementować wskaźnik pamięci duszków i jakąś "metodą siłową" go odświeżyć ?
20. • 20: CommentAuthorGonzo
    • CommentTime22 Jan 2010 22:01 zmieniony

     
    MaW - ciekawy pomysł, ustawianie adresów w rastrze ograniczyło by ilość zmian, ale ze 2/3 zmiany być może dało by się uzyskać.
21. • 21: CommentAuthormono
    • CommentTime22 Jan 2010 22:01 zmieniony

     
    @MaW: Tak się właśnie nie da. Próbowałem to robić kiedy podsyłałem Ci testy multiplikacji sprajtów wielokolorowych w linii. Antic bierze kształt ducha na początku linii i potem możesz mu przestawiać adres PMBASE - nic to nie da. Trzeba zmieniać: rejestr kształtu konkretnego sprajta, jego położenie i jeśli potrzeba kolor, a to niestety daje 12 do 18 cykli CPU. Między samą zmianą kształtu a zmianą pozycji będziesz miał 6 cykli CPU czyli co najmniej 6*4 pikseli hires. Nie zmieniając więc koloru sprajta możesz go ponownie w linii wyświetlić po 24 pikselach (z prawej strony ekranu z lewej będzie to nawet 3x tyle czyli 72px).
    Kod:
    

    lda #shape
    ldx #x0
    ldy #x2
    sty hpospN
    ;punkt 1: w tym punkcie ekranu kończy się wyświetlanie sprajta N z treścią pobraną przez Antic
    sta grafpN
    ;punkt 2: tu zaczyna się wyświetlanie sprajta N z treścią pobraną z rejestru A
    stx hpospN
    ;punkt 3: a w tym punkcie kończy się wyświetlanie sprajta N z treścią pobraną z rejestru A
    

    
    ogranicza odległość sprajtów tylko do 4 cykli CPU (16px hires). Ale musisz po multiplikacji w linii przywrócić położenie sprajta malowanego Antic'em (sty).
    Na ekranie będzie to wyglądać z grubsza tak (1 kropka = 1 piksel hires):
    

    --0000000000000000111111111111111100000000000000002222222222222222333333333333333344444444444444440000000000000000--
    ..aabbccddeeffgghh................iijjkkllmmnnoopp................................................qqrrssttuuvvwwxx..
    --0---------------1---------------2---------------3-----------------------------------------------4-----------------
    

    
    a..h: sprajt 0 malowany Antic'em
    i..p: sprajt 0 malowany CPU
    q..x: sprajt 0 malowany CPU
    Przestrzeń od 1..2 można przykryć sprajtem 1 malowanym przez Antic, ale nie multiplikowanym, bo nie wystarczy czasu na przeładowanie rejestrów CPU (zauważ, że w p1 masz załadowane rejestry CPU odpowiadające za treść sprajta, jego położenie i położenie sprajta malowanego Antic'em). Przeładowanie A i X zajmie 4 cykle CPU, potem zapis położenia 4 cykle, potem zapis treści 4 cykle czyli łącznie 3*16px=48px hires. Niby więc między punktem p3 a p4 włożyłbyś sprajty 2, 3 i 4 (missiles) rysowane Antic'em a w p4 narysowany zostałby znowu sprajt 0 co dałoby pokrycie sprajtami 112px hires (na 320), ale przy założeniu że 1 cykl CPU = 4px hires. A tak nie jest na całej szerokości ekranu.
    Kod:
    

    ldy #x0
    ..
    lda #sh1
    ldx #x2
    stx hposp0
    sta grafp0
    lda #sh2
    ldx #x4
    stx hposp0
    sta grafp0
    sty hposp0
    ....
    

    
    Łącznie 28 cykli CPU (ok połowa dostępnych w linii). Może jeszcze udałoby się wcisnąć jeszcze jedną multiplikację p0, ale wątpię. I to w trybie graficznym - nie ma mowy o znakach, bo każda pierwsza linia będzie wolna od sprajtów rysowanych CPU.
    Może taka multiplikacja dałaby się wykonać na prawej stronie ekranu, bo z lewej CPU jest wolniejszy i blokowany 9x na odświeżanie pamięci dzięki czemu 1 cykl CPU potrafi zająć 24px (a nie 4, jak po prawej stronie ekranu).
    A no i jeśli to dałoby się jednak wyświetlić, to "pamięć sprajtów malowanych za pomocą CPU" byłaby mocno poszatkowana, bo są to argumenty instrukcji lda #.
    Ma to swoje ograniczenia, ale może coś udałoby się uzyskać. Moje wyliczenia są bardzo zgrubne, bo nie uwzględniają dokładnie czasu trwania cyklu CPU w konkretnym punkcie ekranu - trzeba by to po prostu zrobić i sprawdzić co da się w realu uzyskać.
22. • 22: CommentAuthorgorgh
    • CommentTime22 Jan 2010 22:01 zmieniony

     
    edit:nieaktualne
23. • 23:
       
      CommentAuthorRastan
    • CommentTime22 Jan 2010 23:01

     
    No i Mono wszystko wyjaśnił. Niestety nie jest tak wesoło z tą multiplikacją spritów. Na to wszystko traci się cykle i stąd jest to mocno ograniczone.
    
    Ktoś mi powie jak wkleić tutaj pliki .g2f ?
24. • 24:
       
      CommentAuthorRastan
    • CommentTime22 Jan 2010 23:01

     
    Irwin: tak w GED-- też tak jest. choć kolor sprita możesz zmienić, ale tracisz cykle.
25. • 25: CommentAuthorirwin
    • CommentTime23 Jan 2010 08:01 zmieniony

     
    To w sumie załatwia sprawę gdyż po co komu takie same duszki? znaczy przy malowaniu statycznej grafiki.
    
    Nie wiem jak załączyć tutaj pliki, może wrzuć na jakiś serwer typu rapidshare.
    
    @Mono - dzięki za szczegółowe wyjaśnienia.
26. • 26: CommentAuthortebe
    • CommentTime23 Jan 2010 08:01

     
    musicie zajrzeć do dokumentacji ANTIC-a, tam jest diagram z przebiegiem sygnału, dane PMG pobierane są od lewej strony ekranu w konkretnej kolejności i w konkretnych milisekundowych opóźnieniach
    
    jeśli chcecie bawić się w inne kształy w linii to najpierw trzeba wyłączyć DMA dla PMG i wykorzystać rejestry grafiki PMG (GRAFPM0 itd.) wówczas trzeba wpisać odpowiednią wartość do rejestru GRAFPM, zmienić pozycje poziomą itd.
    
    w dopałce Psychola (GTIA Upgrade) gdzie rejestry $d000..$d01f były "bombardowane" ze stałą szybkośćią nowo zapisywanymi wartościami udawało się umieszczać ducha (8 pikslowego) co 8 piksli z nowym kształtem, tak że cały ekran można było tak pokryć
27. • 27: CommentAuthorirwin
    • CommentTime23 Jan 2010 08:01

     
    W takim razie jako experta zapytam Cię - A na ile można liczyć bez owej dopałki Psychola?
28. • 28:
       
      CommentAuthorRastan
    • CommentTime23 Jan 2010 13:01

     
    irwin: ok. dodałem źródła w g2f do xenon i kung-fu master game

    • pic.zip
29. • 29: CommentAuthorw1k
    • CommentTime23 Jan 2010 15:01

     
    admin:
    
    edit CSS:
    
    .quote {word-wrap: break-word;}
30. • 30:
       
      CommentAuthorKaz
    • CommentTime23 Jan 2010 19:01

     
    Cosi - to Twoj kodzik, poprawisz? :)
31. • 31:
       
      CommentAuthorMaW
    • CommentTime10 Mar 2010 09:03 zmieniony

     
    No i taka mała prośba dla asemblerowców: czy
    

    LDA #$22
    STA DMACNTL
    LDA #NEWPMBADR
    STA PMBASE
    LDA #3E
    STA DMACNTL

    
    daje widoczny efekt między liniami lub w linii ?
    
    //EDIT: kurcze, a chciałem tylko zadać pytanie: czy "postać" duszka da się przesunąć bez rozkazów MOVE /bez przepisywania/ ?
32. • 32:
       
      CommentAuthorKaz
    • CommentTime11 Mar 2010 01:03

     
    Widze, ze Dearhorse dziala nad cala bateria programow wspomagajacych:
    
    CHAR-EDITOR:
    
    
    
    CAHR-ANIMATOR:
    
    
    
    P/M-EDITOR:
    
    
    
    DL-EDITOR:
    
    
    
    GR-EDITOR:
    
    
33. • 33:
       
      CommentAuthorMaW
    • CommentTime11 Mar 2010 07:03

     
    Super te edytory, co do PMG-edytora to mam nadzieję, że pamięta o priorytetach łączonych i biędzie się dało takiego sprite'a (dwudusznego) edytować. No i jestem chętny do testowania-zaproś Dearhorse'a na nasze forum!
34. • 34:
       
      CommentAuthorKaz
    • CommentTime11 Mar 2010 10:03

     
    Juz dawno zaproszony, na razie czyta, ale bedzie tutaj lada chwila zarejestrowany.
    
    PS. Czy ktos ma problem ze sciagnieciem programow z jego strony?
    
    ->link<-
35. • 35:
       
      CommentAuthorMaW
    • CommentTime11 Mar 2010 10:03

     
    DEXL-nie, ataritools - nie widzę linków do pobrania
    
    Ja ponowię pytanie: czy po ponownym przydzieleniu dostępu do pamięci PMG na początku nowej linii ANTIC reaguje na zmianę rejestru PMBASE ? Tzn. da się to wykorzystać do szybkiej animacji duszków lub ich zwielokrotnienia (z różną zawartością), czy nie ?
36. • 36: CommentAuthormono
    • CommentTime11 Mar 2010 11:03

     
    Wydaje mi się, że robiłem kiedyś taki test i się tak nie da :( Ale zweryfikuję to wieczorem na żywym Atari. Tzn. treść sprajta w linii (pobrana przez DMA) jest taka sama nawet po zmianie pozycji sprajta. Można to zmienić tylko przez wpis do GRAFPx/GRAFM (taki test miałeś ode mnie przy okazji prac nad mceng).
37. • 37: CommentAuthormono
    • CommentTime11 Mar 2010 19:03

     
    W załączniku test z multiplikacją sprajtów w poziomie za pomocą zmiany położenia HPOSPx i PMBASE.
    Obszar PMG0 inicjalizowany jest następująco:
    P0=%10110101
    P1=%11011011
    co przy nakładaniu kolorów powinno dać kolory
    32132123
    co widać na lewym pasie.
    Obszar PMG1 inicjalizowany jest tak:
    P0=%11110000
    P1=%11000011
    co przy nakładaniu kolorów powinno dać kolory
    33110022
    czego na ekranie niestety na prawym pasku nie widać :(
    Linia pusta na prawym pasku jest efektem zabierania pierwszej linii skanningowej przez ANTIC w trybie tekstowym - procesor jest tam praktycznie nieużywany.

    • pmgtest.atr
38. • 38:
       
      CommentAuthorMaW
    • CommentTime11 Mar 2010 23:03

     
    to teraz powiedz to po ludzku...
39. • 39: CommentAuthormono
    • CommentTime12 Mar 2010 15:03

     
    W teście robię dwa pasy pionowe: lewy to sprajty 0 i 1 nałożone na siebie (ANTIC maluje je przy użyciu DMA), prawy to sprajty 0 i 1 nałożone na siebie (ANTIC maluje je biorąc dane o sprajtach z rejestru GRAFP0 i GRAFP1). Sprajty mają włączony tryb multicolor (nakładanie) dzięki czemu pionowe pasy są w 3 kolorach (+ przezroczysty).
    Co chcemy przetestować? Chcemy sprawdzić, czy ANTIC potrafi rysować sprajty w jednej linii korzystając raz z jednego banku ustawianego w PMBASE (pasy z lewej), a raz z drugiego (pasy z prawej strony).
    Przerwanie DLI włącza PMBASE na bank PMG0, po czym czeka aż sprajty zostaną narysowane, zmienia położenie playerów 0 i 1 i ustawia PMBASE na bank PMG1 (i czeka aż sprajty zostaną narysowane po czym powtarza operację w następnej linii skanningowej). W obydwu bankach sprajty mają nieco inaczej zdefiniowany kształt, dzięki czemu obraz widoczny na ekranie wykaże czy zmiana PMBASE w trakcie rysowania linii coś da, bowiem jeśli dane dla sprajta brane są z pamięci w momencie rysowania to pasy po lewej stronie powinny być inne niż pasy po prawej (bo w międzyczasie zmieniamy banki dla sprajtów w PMBASE).
    Okazuje się jednak, że zmiana PMBASE nic nie daje. Dlaczego? Winny jest ANTIC, bo używa on DMA do pobrania danych o sprajtach z pamięci I WPISANIA ICH DO REJESTRÓW GRAFPx i GRAFM na początku linii ekranowej! A więc aż do momentu zmiany GRAFPx kształt sprajta się nie zmieni na co dowodem jest to, że pasy po lewej i po prawej są identyczne.
    Różnica widoczna w pojedynczych liniach skanningowych na pasie po prawej stronie jest efektem zastosowania trybu tekstowego i faktu, że ANTIC pobiera przez prawie całą pierwszą linię skanningową trybu tekstowego dane pamięci obrazu, natomiast na tej podstawie rysuje treść obrazu korzystając z pamięci generatora znaków przez kolejne linie trybu tekstowego (bo kody znaków ma już zbuforowane). Ponieważ ANTIC ma priorytet w dostępie do pamięci przed procesorem, CPU jest blokowane i żadne DLI się w tej linii nie wykona - zostanie opóźnione do czasu aż ANTIC skończy pobierać dane z pamięci obrazu. Dzięki temu w trybie tekstowym multiplikacja sprajta w linii jest praktycznie niemożliwa w każdej pierwszej linii skanningowej wiersza.
40. • 40:
       
      CommentAuthorKaz
    • CommentTime13 Sep 2010 11:09

     
    Przypomne watek, jako ze program DearHorse'a nadal sie rozwija:
    
    ->link<-
41. • 41:
       
      CommentAuthorinsert
    • CommentTime8 Nov 2010 22:11

     
    super, pieknie, kolo pisze program i napisac nie moze, a poki co nikt nie odpowiedzial na pytanie czy istnieje juz na atari albo na pc jakis edytor do duszkow, ja chcialbym sobie dolaczyc takie dane do programu w tbxl np, moze ktos w koncu rozwinie temat :)
42. • 42: CommentAuthorxxl
    • CommentTime8 Nov 2010 22:11

     
    g2f osobno zapisuje dane duszkow, mozna to wykorzystac
43. • 43: CommentAuthorGonzo
    • CommentTime9 Nov 2010 00:11

     
    nie ma nic lepszego do edycji duszków na A8 niż G2F, i raczej nie będzie, Tebe przemyślał to bardzo dobrze, chociaż G2F może na początku wydawać się trochę dziwnym programem
44. • 44:
       
      CommentAuthorKaz
    • CommentTime9 Nov 2010 00:11

     
    poki co nikt nie odpowiedzial na pytanie czy istnieje juz na atari albo na pc jakis edytor do duszkow, ja chcialbym sobie dolaczyc takie dane do programu w tbxl np, moze ktos w koncu rozwinie temat

    
    
    Nikt nie odpowiedzial, bo temat jest sliski :). Jak dotychczas - nie bylo jednolitego formatu dla duszkow, wiec uniwersalnych metod nie ma. Co program - to inny sposob zapisu danych. A programow dla Atari do edycji troche jest - polecam przegladniecie dzialu uzytkow.
    
    Na pececie z kolei posucha, przeciez w ogole jest bardzo malo programow dla Atari. Wiec stosuje sie G2F, ale nie jest to najwygodniejsze.
    
    Ale jest swiatelko w tunelu :). Jak pewnie wiesz - Konop pracuje nad uniwersalnym formatem danych, ja staram sie przekonac m.in. DearHorse'a, zeby zastosowal go w swoim edytorze, TeBe tez chyba jest przychylny standaryzacji. Za jakies piec lat mozesz sie spodziewac odpowiednich programow na peceta ;)
45. • 45: CommentAuthorKonop
    • CommentTime9 Nov 2010 17:11

     
    Format, który zaprojektowałem, nadaje się już na obecnym etapie rozwoju do wykorzystania w prostym edytorze. Nie widzę przeszkód, aby tak zrobić.
46. • 46: CommentAuthorslaves
    • CommentTime9 Nov 2010 18:11

     
    insert: nie wiem, czy dokładnie tego szukasz, ale zerknij na taki program jak: ANIMATION STUDIO by zielony/waxsoft - kiedyś robiłem na nim animki do gierki.
47. • 47:
       
      CommentAuthorKaz
    • CommentTime28 Mar 2011 15:03 zmieniony

     
    Wczoraj TDC opublikowal artek opisujacy jego program do edycji:
    
    ->link<-
    
    A ponadto mam niespodzianke. W postaci edytora, ktorego uzywal Tomasz Liebich przy tworzeniu gry "Vicky". Program podeslal Darek Majer z komentarzem:
    
    

    Eagle:

    Sa one w Turbo Basicu. Uzywalem je dosyc dlugo i sie przydawaly bardzo. (...) PicToPmg z tego co widze zostal chyba zmodyfikowany przeze mnie na wersje 2 graczy i 4 pociski. Ale chodzi o sam program, wiec jak ktos sie chociaz troche zna to moze zmodyfikowac.

    
    
    
    
    
    
    Zrobilem dyskietke z oboma programami i automatycznie odpalanym TBXL. Wystarczy wiec poczekac i wpisac LOAD "D:ANIM.TBX" lub LOAD "D:PICTOPMG.TBX". Na dyskietce jest przykladowy obrazek Faraon, mozna testowac na nim podawanie parametrow.
    
    ->link<-
    
    Zasada dzialania programu jest prosta. Musimy miec rozrysowane fazy postaci na obrazku MIC, programowi podajemy parametry (rozmiar, itp) postaci, a on juz sobie przetrawi ten obrazek na animacje.