atarionline.pl RastaConverter by Jakub Debsky - Forum Atarum

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

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorPhilsan
    • CommentTime6 May 2012
     
    Perhaps the news has already appeared here.

    Have you seen this awesome automatic graphic converter?
    ->link<-
    • 2:
       
      CommentAuthorjhusak
    • CommentTime6 May 2012
     
    Yes, we've discussed and tested this very intensively here:

    ->link<-
    • 3: CommentAuthorPhilsan
    • CommentTime6 May 2012
     
    Thank you Jakub, I don't read "vs" threads so I missed it.

    I think your converter deserves a thread and a news on Atalionline frontpage.

    Your program makes Atari history!
    • 4:
       
      CommentAuthorjhusak
    • CommentTime6 May 2012
     
    It's not mine, its Jakubs' Debski (ilmenit), I'am Jakub Husak.

    Anyway, you're right about history :)

    However, there is some work to do, Jakub's workin' on it.
    • 5:
       
      CommentAuthorxeen
    • CommentTime7 May 2012
     
    And I'll take care to put final version on AOL frontpage :)
    • 6: CommentAuthorPhilsan
    • CommentTime7 May 2012
     
    I am sorry Jakub (Husak).
    I read your first name only!

    Thank you xeen!
    • 7:
       
      CommentAuthorDracon
    • CommentTime7 May 2012
     

    Philsan:

    Perhaps the news has already appeared here.

    Have you seen this awesome automatic graphic converter?

    Well, it's a bit funny saying this, but everything about RastaConverter was born exactly in this forum! :D
    • 8: CommentAuthorilmenit
    • CommentTime28 May 2012
     
    Cały rozwój RastaConvertera przeniósł się na GitHub i AtariAge (kilka osób zaangażowało się w projekt). Załączam najnowszą wersję.
    • 9:
       
      CommentAuthorjhusak
    • CommentTime29 May 2012
     
    testing testing...
    • 10:
       
      CommentAuthorKaz
    • CommentTime29 May 2012
     
    No prosze, nie bylo mnie, a tu takie bomby podpalajace :)
    Brawo Ilmenit!
    • 11:
       
      CommentAuthorDracon
    • CommentTime29 May 2012 zmieniony
     
    Bedzie jeszcze bardziej bombowo jak obliczenia zostana przeniesione na procki graficzne bo wiadomo, ze np. enkodowanie video na nowoczesnej pecetowskiej karcie gfx (z uzyciem OpenCL) jest szybsze niz mielenie procesorem...
    • 12: CommentAuthorilmenit
    • CommentTime1 Jun 2012
     
    To szykujcie się na opad szczeny... Na razie działa pod emulcem, najlepiej z Altirra.
    ->link<-
    Autor - Xeul z AtariAge.
    • 13:
       
      CommentAuthorKaz
    • CommentTime1 Jun 2012
     
    No dobrze, ale o co w tym chodzi? Wiemy kto, ale po co, jak, dlaczego?
    • 14:
       
      CommentAuthorxeen
    • CommentTime1 Jun 2012
     
    he he, dzięki za ostrzeżenie, udało mi się złapać szczękę w ostatniej chwili :)
    • 15:
       
      CommentAuthorMaW
    • CommentTime1 Jun 2012
     
    ja.pier.dy.le. oniemiałem. JAK to możliwe ??
    • 16: CommentAuthorGonzo
    • CommentTime2 Jun 2012
     
    u mnie opad szczeki wystapił prawidłowo :)
    • 17: CommentAuthorkade
    • CommentTime2 Jun 2012
     
    fajne !:)
  1.  
    Niby fajne, ale lipa. Na prawdziwym Atari nie działa. Próbowałem załadować ten plik xex przez SIO2USB - bez względu na ustawienia prędkości wysypuje się po wczytaniu kilkuset bajtów.
    • 19:
       
      CommentAuthorKaz
    • CommentTime2 Jun 2012
     
    Ilmenit pisal, ze na razie dziala pod emulcem, ale prace (jak mniemam) trwaja.
  2.  
    Nie znam się na tyle na bebechach Atari, żeby się tu wymądrzać, ale wydaje mi się, że na prawdziwym sprzęcie to raczej nie ma prawa zadziałać. Chodzi o sposób transferu danych do pamięci komputera. W przypadku emulatorów wczytanie pliku XEX najprawdopodobniej odbywa się z pominięciem POKEYa, czyli ładowany jest cały blok do pamięci "bocznym wejściem". Na prawdziwym sprzęcie przy podłączeniu jakiegokolwiek urządzenia przez gniazdo SIO za transfer odpowiedzialny jest POKEY, a co za tym idzie po pierwsze zeżre cykle procesora potrzebne do wyświetlenia obrazka, a po drugie będzie jakieś jajo z dźwiękiem (albo wcale albo jakiś poszarpany, gdyby wstrzelić się z dźwiękami pomiędzy cykle odczytu IO). Może mnie ktoś sprostuje - jak pisałem nie mam za dużej wiedzy w tym temacie.
    • 21: CommentAuthorilmenit
    • CommentTime11 Jun 2012 zmieniony
     
    To kwestia nośnika o odpowiednio szybkim transferze danych. Dla C64 powstało: ->link<-
    więc czemu by nie miało powstać dla Atari :)




    Btw, mały tutorial jak przygotowywać grafikę dla RastaConvertera:
    ->link<-
    • 22:
       
      CommentAuthorjhusak
    • CommentTime11 Jun 2012
     
    Ha!
    Breaking the Wall!

    Wiesz, co Ilmenit, Ty nie wiesz, czego NIE DA SIĘ ZROBIĆ na Atari 8-bit.
    I robisz to!

    Szacun, chociaż dla mnie większym osiągnięciem jest RastaConverter; RastaMovie jest jego wykorzystaniem, jakże spektakularnym.

    Wracając do urządzenia - wszystkie nogi procesora wystawione są na szynę A800XL, a i chyba XE z expansion port mają wszystko co trzeba, aby zatrzymać na co drugi cykl procesor (co drugi cykl, gdy ma dostęp do pamięci), następnie w DMA przerzucać te naście kb w 900000/25=35000 cykli; wyrobi się toto.

    Czyli urządzenie musi dostać start, długość bloku pamięci oraz adres w pliku. Karta SD ma odczyt rzedu kilku MB/sek, co z powodzeniem wystarcza, następnie DMA wypełnia pamięć, a procek wyświetla poprzedni obrazek i gra sample. Po wczytaniu ekranu podmieniany jest dl i hula!

    Dać - da się. Trzeba tylko speca, co to zrobi. Ale - potrzeba jest matką wynalazków. Candle! Do dzieła!
    • 23:
       
      CommentAuthormiker
    • CommentTime12 Jun 2012
     
    Coś takiego już chyba nawet istnieje:
    (nie doczytałem się tylko, jakiego trybu powyższa anima używa, bodajże jest to RGB, nieużywalny praktycznie na PAL - potrójny interlace, ale mogę się mylić).
    • 24:
       
      CommentAuthormiker
    • CommentTime12 Jun 2012
     
    Tak, dokładnie, tu temat o powyższym filmiku: ->link<-
  3.  
    @jhusak
    Ale mi chodziło o takie purystyczne podejście: mam zwykłe 8-bitowe Atari, podłączam do niego "coś" przez jedno z istniejących gniazd (w domyśle SIO) i oglądam film.

    O ile pamiętam Mr. Atari zbudował jakiś samorobny kontroler IDE do celów demonstracji tych filmików, nie wiem tylko czy to urządzenie w pełni zewnętrzne, czy przeróbka komputera.

    Bo to że komputer można dozbroić od środka to wiadomo i nie robi to na mnie specjalnie wrażenia. Jak by się uprzeć można dodać tam 16MB RAMu, sterujący tym procesor x86, mostki, kontrolery, itp. i uruchomić MS DOSa, czy Windows tylko po co? Sztuka to wycisnąć więcej z istniejącej architektury.

    Oczywiście wielki mam szacunek dla Ilmenita - RastaConverter to właśnie takie purystyczne podejście - generator obrazków wyciskający maksa z Atari.

    Wiadomo czy te filmiki na C64 wymagały przeróbek sprzętu?
    • 26:
       
      CommentAuthorjhusak
    • CommentTime12 Jun 2012 zmieniony
     
    @xmgatz, chodzi o urządzenie ZEWNĘTRZNE podłączane przez szynę procesora.
  4.  
    @jhusak
    Mówisz o szynie PBI, ECI, czy po prostu o flakach przylutowanych do szyny procesora, a wiszących na kablach na zewnątrz obudowy? ;-) Wiesz, można róźnie definiować pojęcie "urządzenie zewnętrzne".

    A tak poważnie, to pewnie się po prostu czepiam, ale dla mnie to co np. dzieje się w światku Amigowym (akceleratory, nakładki na procesor, dodatkowa pamięć gdzieś tam lutowana na płycie, ROM switchery) to zaprzeczenie takiej purystycznej idei retro komputerów. Niestety to samo tyczy się VBXE, stereo do Atari, i tak dalej. Oczywiście takie np. stereo stało się już do pewnego stopnia standardem, i tu granice zaczynają się zacierać, ale po drugiej stronie skali masz hardcorowe przeróbki, i zaczyna się pojawiać wtedy pytanie "czy to jeszcze 8-bitowe Atari, czy już nie"?

    Więc wracając do tematu: jeżeli działa na nieprzerobionym Atari, to pełen szacun, a jak trzeba przerabiać, to tylko pół szacunu (za włożony wysiłek). :-)
    • 28:
       
      CommentAuthorjhusak
    • CommentTime12 Jun 2012 zmieniony
     
    A tak poważnie, to pewnie się po prostu czepiam

    No strasznie. Sam bym wymyślił jeszcze z kilka interpretacji epitetu "urządzenie zewnętrzne".

    PBI/ECI + HW + DMA, RED PCB z LCD, a także HALT na CPU PIN.

    IMHO 8 bit atari = cpu6502
    16-bit Atari= cpu 65816
    32 bit Atari = 68xxx

    Więc gdyby do A8bit podłączyć jakąś kartę graficzną ISA, to dalej byłby 8-bit.
    • 29:
       
      CommentAuthorKaz
    • CommentTime9 Jul 2012 zmieniony
     
    Panowie, wpis Ilmenita z komentarzy pod ta nowinka:
    ->link<-
    przeklejam na forum, zeby latwiej sie dyskutowalo:

    Ilmenit:

    A jak to działa?
    Program szuka najlepszego programu rastra (kernel program), technika stosowana powszechnie w Atari 2600:
    ->link<-
    ->link<-
    "Najlepszy", czyli dający najbardziej podobny obrazek wg wybranej miary odległości kolorów:
    ->link<-

    Optymalizacja programu rastra to zagadnienie podobne do:
    ->link<-
    Szukamy w tym przypadku nie najkrótszego programu, ale dającego najlepszy obrazek.

    Po testach okazało się, że najlepsze efekty (czas vs jakość) daje:
    ->link<-


    Oraz uwaga na temat wspolpracy z G2F:

    Ilmenit:

    Dzięki za newsa na głównej. Dla mnie to motywacja do poprawy dwóch błędów, które znam i do dodania obiecanych opcji (np. wł/wył poszczególnych rejestrów w wybranych liniach). Jeszcze sporo można w tym projekcie usprawnić :-)

    Tebe pisał, że przerobienie G2F do wczytywania RC będzie problematyczne. Starałem się to zrobić jak najmniej problematycznym (generuję kod i dane tak, jak generuje je G2F), ale RC wykorzystuje więcej możliwości Atari niż G2F (np. duplikacja duszka w linii jest chyba nie zaimplementowana w G2F).

    Ewentualnie mógłbym dodać przełącznik, który będzie generował obrazek kompatybilny z G2F. Obrazek taki byłby gorszej jakości niż bez ograniczeń G2F, ale przynajmniej można by go edytować...


    Ilmenit:

    Nie wiem jak jest napisany G2F, więc trudno mi ocenić, jak wielkie zmiany byłby konieczne do przystosowania go do RC. Tebe, w czym głównie jest problem?
    Nie uważam jednak, że obsługa musi być tak niewygodna jak w Power Graphics... Mógłbym samemu dodać pisać edytor, ale (a) nie lubię pisać GUI i nie jest to dla mnie w żaden sposób ciekawe (b) dwa programy o rozłącznych cechach byłyby wciąż krytykowane z brak cech drugiego, co skutecznie zniechęciłoby autorów do jakiejkolwiek pracy nad nimi.
    • 30: CommentAuthor0xF
    • CommentTime9 Jul 2012
     
    Plus dla Ilmenita za źródła na GitHubie. Plus dla TeBego, że zaczął lepiej dokumentować formaty G2F i MCH.

    Co do (b) to moim zdaniem jest przeciwnie - konkurencja sprzyja rozwojowi i daje użytkownikom wybór.
    • 31: CommentAuthorilmenit
    • CommentTime11 Jul 2012
     
    Wrzuciłem sporo moich konwersji tutaj:
    ->link<-
    • 32:
       
      CommentAuthorKaz
    • CommentTime11 Jul 2012 zmieniony
     
    Ilmenit - nieprawdopodobne!!!

    Czy dalbys rade podzielic sie tez z nami obrazkami przed konwersja? I informacja, jakie w danych przypadkach byly uzyte parametry konwersji?

    Chociaz tymi kilkoma, bo sa niesamowite, wrecz niewiarygodne:











    • 33: CommentAuthorilmenit
    • CommentTime11 Jul 2012 zmieniony
     
    Obrazek Winter
    1. Preprocess obrazka



    RastaConverter.exe winter-original.jpg /dither=knoll /distance=ciede

    2. Obrazek output.png-dst.png przemianowany na winter.png



    3. Konwersja z wykorzystaniem maski detali:



    RastaConverter.exe winter.png /filter=box /details=winter-details.png /details_val=4

    Wynik (954 670 524 evaluations):
    • 34: CommentAuthorilmenit
    • CommentTime11 Jul 2012 zmieniony
     
    Obrazek Stones:


    RastaConverter.exe stones_mist.jpg /dither=knoll /pal=laoo
    Evaluations: 1359387000
    • 35:
       
      CommentAuthormgr_inz_rafal
    • CommentTime11 Jul 2012 zmieniony
     
    Mi cuś nie idzie... River Raid jeszcze wyszedł jak cię mogę... :)

    Może to z .png nie działa?






    • 36: CommentAuthorilmenit
    • CommentTime11 Jul 2012 zmieniony
     
    1. Nie używaj obrazków w stratnej kompresji jako wejścia (rr.jpg)
    2. Dla obrazków z 8bitowców używaj /filter=box
    3. Obrazki hdm i hh mają szerokość ponad 320 pikseli. RC robi ich resize, co przy standardowym /filter bardzo efekt psuje. Najlepiej w IrfanView wybierz opcję Auto Crop Borders. Warto też ustalić odpowiednią wysokość obrazka np. /h=200 aby zachować proporcje.
    4. Dla obrazków o małej liczbie kolorów często lepiej działa /init=less lub /init=smart.

    Więcej w helpie.

    I jeszcze uwaga: Obrazek musi mieć paletę minimum 8bit. RC nie wczytuje poprawnie obrazków w 4bit palecie.

    Trudno napisać coś więcej, bo nie podałeś użytych parametrów.
  5.  
    Hej,
    Dzięki za wyjaśnienie. Przyznaję, nie przebrnąłem przez całego helpa :) Jestem z tych, co instrukcję czytają jak już nic innego nie pomaga.

    Wieczorem spróbuję jeszcze raz sobie pokonwertować.
    • 38:
       
      CommentAuthorKaz
    • CommentTime11 Jul 2012
     
    Ilmenit - dzieki wielkie, jest to dobry material do testow i analiz. Takie pytanie: czy mozliwe by bylo wprowadzic opcje kompresji pliku xex, jakies takiej optymalnej do tego typu obrazkow?
    • 39: CommentAuthorilmenit
    • CommentTime12 Jul 2012 zmieniony
     
    Tebe, 0xF, czy w G2F i PowerGraphics macie zaimplementowane poprawnie repozycjonowanie duszków i czy Phaeron ma rację odnośnie algorytmu ->link<- ?
    • 40: CommentAuthorilmenit
    • CommentTime12 Jul 2012 zmieniony
     
    @mgr_inz_rafal

    Henry's House

    RastaConverter.exe hh.png /h=200 /filter=box /init=smart /pal=laoo

    • 41: CommentAuthortebe
    • CommentTime12 Jul 2012
     
    Henry House akurat wykorzystuje 5 kolorów + PMG na koronie, RC to za duża armata na takie małe coś
    • 42: CommentAuthor0xF
    • CommentTime12 Jul 2012
     
    ilmenit: PowerGraphics jest programem na Atari, a repozycjonowanie duszków uzyskuje się tam przez de facto pisanie w asemblerze z nietypową składnią. Dlaczego by więc miało działać niepoprawnie?
    • 43: CommentAuthorilmenit
    • CommentTime12 Jul 2012 zmieniony
     
    Dzięki za info. PG nie używałem i myślałem, że oprócz samej możliwości pisania kodu są też funkcje pomocnicze np. pokazujące gdzie zajdzie na ekranie zmiana. Ale może i tak jesteś w stanie podpowiedzieć coś na temat repozycjonowania duszków? Ma Phaeron rację? :)
    • 44: CommentAuthor0xF
    • CommentTime12 Jul 2012
     
    Nie sprawdzałem tego, ale wierzę mu na słowo. Istotna jest jego uwaga, że emulatory tego nie obsługują z wyjątkiem najświeższej Altirry. Gdyby więc polegać na tym efekcie, proponuję dodać test "czy masz prawdziwe Atari lub porządny emulator".
    • 45: CommentAuthortebe
    • CommentTime12 Jul 2012
     
    mnożenie duszków w G2F jest bez dodatkowych testów, tak że miarą możliwości jest prawdziwy sprzęt albo emulator któremu ufamy
    • 46: CommentAuthornodez
    • CommentTime12 Jul 2012 zmieniony
     
    takie rzeczy cza testowc na real hardzie to nawet nie polega dyskusji
    • 47: CommentAuthorilmenit
    • CommentTime12 Jul 2012
     
    testy testami, ale samo zachowanie zmiany pozycji duszków nie jest nigdzie dobrze udokumentowane.
    • 48: CommentAuthorGonzo
    • CommentTime14 Jul 2012 zmieniony
     


    muza - miker stereo
    • 49:
       
      CommentAuthorKaz
    • CommentTime14 Jul 2012
     
    1. Czy obrazek jest nizszy, zeby mogla zagrac muzyka czy moze byc fullscreen i muzyka tez da rade?

    2. Nie rozumiem tego - jest czas, zeby grala muzyka, a nie mozna wcisnac opcji wylaczenia obrazka po 5 sekundach?
    • 50:
       
      CommentAuthorlarek
    • CommentTime14 Jul 2012 zmieniony
     
    ad.2
    Kaz, na poziomie asemblera można prawie wszystko. Po kompilacji, gdy mamy dostępny tylko plik wynikowy (xex), możliwości wprowadzania zmian drastycznie spadają.