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: CommentAuthorilmenit
   • CommentTime6 Jan 2010 21:01 zmieniony

    
   - Na razie wspiera tylko gr. 15 (mam dziwne problemy z kolorami w gr. 10).
   - Domyślnie używa palety Palettes\laoo.act
   - Do zbudowania XEX potrzebuje zainstalowanego CC65. Jeżeli program wzbudzi zainteresowanie, to zrobię od razu kompilację MADSem lub autogenerowanie XEX.
   - Zmiany DLI nie są na razie optymalizowane.
   - W zależności od wybranej palety niektóre obrazki kwantyzuje lepiej lub gorzej (podobieństwo kolorów).

   • Quantizator.zip
2. • 2: CommentAuthorirwin
   • CommentTime6 Jan 2010 22:01 zmieniony

    
   Ilmenit na prezydenta!
   Otake programy chodzi!, o konwentery! Nie będą nam tu komodziarze plu.... stop... ;)
   
   Działa znakomicie!
   Jak jeszcze byś skontaktował się z Mono i jego ->link<- engine do podkładania duszków (ale w wersji gr15) oraz Tebe tj zapis do pliku g2f celem poprawienia i retuszu drobnych niedoskonałaści konwersji to mamy megabombę wszechczasów.
   
   btw. Logo High Dark Majesty rządzi ;)
   
   @Kaz - byłem szybszy ;)
3. • 3:
      
     CommentAuthorKaz
   • CommentTime6 Jan 2010 22:01

    
   Fajne toto! Aczkolwiek byloby znacznie bardziej uzyteczne, gdyby oprocz albo zamiast XEX budowalo plik w formacie G2F, ktory potem mozna by recznie edytowac w Graph2Font. To pozwolilo by dodac duszki, ewentualnie poprawic niektore piksele i tym samym uzyskac jeszcze wierniejszy efekt. To taka sugestia do nastepnych wersji :)
   
   
   
   
   
   
   
   
   
   
   
   
4. • 4: CommentAuthorirwin
   • CommentTime6 Jan 2010 22:01

    
   @Kaz - dawaj newsa na główną bo taki program zasługuje, jak mało który ;)
5. • 5: CommentAuthormono
   • CommentTime6 Jan 2010 22:01

    
   Ładne. Efekt jest całkiem niezły. Czy to są tylko zmiany podstawowych kolorów? Żadnych sprajtów nie używasz? Jeśli tak, to końcowy efekt z użyciem sprajtów może się okazać bardzo dobry.
6. • 6: CommentAuthorirwin
   • CommentTime6 Jan 2010 22:01

    
   Jest maksymalnie 5 kolorów w linii więc duszków pewnie nie ma. Teraz trzeba zaprząść do roboty Twój duszkowy engine by Mono i gra muzyka. ;)
7. • 7:
      
     CommentAuthorAlex
   • CommentTime6 Jan 2010 23:01

    
   WYbaczcie ignorancję, ale zupełnie nie jestem w temacie. Ciekawi mnie czym ten programik się różni od tego, co do tej pory było? Czy G2F nie nadaje się do konwertowania obrazków?
8. • 8:
      
     CommentAuthormiker
   • CommentTime6 Jan 2010 23:01

    
   Znaczy programik ciekawy, ale jakoś nie chce mi tego xex-a nigdzie zapisać, pomimo wgrania cc65 i ustawienia mu ścieżek. Coś mu tam mignie w oknienku poleceń i tyle go widzieli...
9. • 9:
      
     CommentAuthorKaz
   • CommentTime7 Jan 2010 00:01 zmieniony

    
   Alex - a co do tej pory bylo?
   
   Irwin - przeciez watek na forum jest na glownej stronie :). A do nowinki to poczekajmy na wersje nie-beta.
10. • 10: CommentAuthorilmenit
    • CommentTime7 Jan 2010 10:01 zmieniony

     
    Engine do duszków Mono nie ma tu zastosowania. Jest specyficzny dla Spectrum, czyli duszki ustalone w określonych miejscach zawsze o poczwórnej szerokości.
    
    Export do G2F raczej trudny, bo Tebe chyba nie dał opisu formatu pliku?
    Aktualnie generuję wynikowy obrazek BMP, w którym każda linia ma maksymalnie 4 kolory. Jest to już banalne do przeparsowania. Mogę też generować pliki danych, czyli piksele ekranu + kolory DLI.
    
    Najprościej jak się dogadam z Tebe i Quantizator będzie zewnętrznym DLL dla G2F. Ewentualnie do Delphi (w czym jest G2F) można przenieść sam algorytm kwantyzacji kolorów (grupowanie z wykorzystaniem k-średnich, specyficzna inicjalizacia centroidów).
    Sam algorytm już nie jest prosty, a skomplikuje się jeszcze bardziej bo mam pomysł jak zrobić międzyliniowy dithering, gdy w każdej linii jest inna paleta.
    Algorytm ten będzie starał się minimalizować różnice obrazka bazowego i wynikowego.
    
    Co do duszków i ich automatycznego umieszczania to sprawa jest trudna. Trzeba by to zintegrować z generowaniem palety, ewentualnie po wygenerowaniu obrazka nakładać duszki tak, aby minimalizować różnice pomiędzy obrazkiem bazowym a wynikowym. Obawiam się jednak, że w tym przypadku byłyby widoczne kolumnowe "przebarwienia" kolorów tam, gdzie duszki byłby naniesione.
    A może nie... Warto sprawdzić :)
    
    Do kompilacji XEX potrzeba ustawić zmienne środowiskowe dla kompilatora CC65_INC i CC65_LIB.
    
    W nowej wersji postaram się też dodać inne od euklidesowego miary podobieństwa kolorów np. cosine similarity. Powinno dać lepsze efekty dla kolorowych obrazków.
11. • 11:
       
      CommentAuthorKaz
    • CommentTime7 Jan 2010 13:01 zmieniony

     

    Ilmenit:

    Engine do duszków Mono nie ma tu zastosowania. Jest specyficzny dla Spectrum, czyli duszki ustalone w określonych miejscach zawsze o poczwórnej szerokości.

    
    
    Oczywiscie najlepiej, zeby Mono sie sam wypowiedzial na temat swojego pomyslu, ale o ile pamietam, to docelowo jego silnik ma tworzyc (lub juz tworzy) duszki dowolnej szerokosci.
    
    

    Ilmenit:

    Aktualnie generuję wynikowy obrazek BMP, w którym każda linia ma maksymalnie 4 kolory. Jest to już banalne do przeparsowania. Mogę też generować pliki danych, czyli piksele ekranu + kolory DLI.

    
    
    Pozyteczna moglaby tez byc (jako opcja!) funkcja uwzgledniania piatego koloru - gdyby efekt mial byc w trybie znakowym.
    
    

    Ilmenit:

    Najprościej jak się dogadam z Tebe

    
    
    O do tego bardzo bym zachecal :).
    
    PS. Poza tym - musi byc jakas metoda sensownego podkolorowania duszkami. Czlowiek potrafi, a maszyna nie? ;)
12. • 12: CommentAuthorilmenit
    • CommentTime7 Jan 2010 14:01 zmieniony

     
    Czy piąty kolor może być w tym generowany dokładnie tak jak pozostałe, czy musi spełniać jakieś dodatkowe parametry np. wyrównanie do szerokości znaku w pionie i poziomie?
    
    Podkolorowanie duszkami to chyba problem klasy NP. Z tymi często człowiek radzi sobie lepiej. Ale pomysły mam i jak znajdzie się czas, to potestuję :)
    
    Czy G2F obsługuje wszystkie tryby pracy duszków (podświetlania, zamalowywanie tła)?
13. • 13: CommentAuthorirwin
    • CommentTime7 Jan 2010 14:01

     
    @ilmenit po pierwsze na Atari jest jedna zasada - Nigdy nie mów "nie da się" ;)
    
    A tak na poważniej:
    Zacytuje Mono "Jeśli zaś chodzi o podkładanie sprajtów przez g2f podczas konwersji obrazków, to myślę że algorytm musiałby być bardziej rozbudowany. Obecnie dzielę wiersz na 32 pola i analizuję kombinacje tylko dla nich przy założeniu, że sprajty są szerokości x4. Żeby dokładnie podkładać sprajty należałoby rozbudować elgorytm o szerokości x1 i x2 oraz brać 256/320 pól. Nie jest to jednak niewykonalne - zasada działania konwertera pozostaje podobna, zmieni się tylko złożoność czasowa.
    Jeśli zaś chodzi o podkolorowywanie innych trybów to wydaje mi się, że poza zmianą kilku początkowych założeń wynikających ze specyfiki hires nie byłoby większych trudności. "
    
    Po drugie, bardzo podobny, choć pewnie trochę inaczej rozwiązany problem mają komodziarze przy podkładaniu duszków w trybie hires. Poczytaj artykuł w C&A nr 5 który parę dni temu wyszedł, tam z boku na rysunku carriona train jest pokazane jak to u nich wygląda: jest podział na płaszczyzne bitmapy, duszki, maska bitmapy tj jeśli dobrze to rozumiem miejsca przez które prześwitują duszki. Oni oczywiście mają lepsze duszki i więcej kolorów linii ale i tak muszą np również rozciągać duszki do 2x czy 4x size. Są wtedy piksle kolosy ale dzięki nakładaniu na nich normalnych kolorów da się to ukryć. Wystarczy zobaczyć te niesamowicie kolorowe obrazki Piesiu tam jest jedynie 9 kolorów linii. Skoro człowiek potrafi, skoro konwentery na c64 potrafią to - być może w sporo gorszej, szczątkowej formie ale i u nas by to dało rade. Wtedy jakość takich obrazków po konwersji byłaby o niebo... err... o dwa i pół nieba lepsza ;)
    
    Po trzecie taki podobny program zrobił Algorithm dla c64 - gdyż to komodziarz z dziada pradziada - jednak zaoferował się że zrobi podobny dla Atari jak ktoś Mu wyłoży o co biega w naszych duszkach (po angielsku). Mimo moich usilnych starań nikt z atarowców nie był w stanie tych tajemnych runów przełożyć na angielski. ;) Obecnie Alogorithm przestał się interesować Atari i ma szereg projektów związanych z c64 min. Tri-Lace czy SuperMusc który rozłoży opisywany w C&A nr 5 NUFLI. Jednak być może pomoże, wskaże jak to zrobić, może jakieś źródła.
    Jego konto na csdb:
    ->link<-
    Możesz do niego uderzyć, przez PM lub mogę Ci podać jego adres mailowy, mój adres znasz, podsyłałem ci kiedyś animki do HighDarkMajesty. polecam też zobaczyć jak działa jego program MUSC:
    ->link<-
    
    Po czwarte mimo iż na C64 owe konwentery dość dobrze to robią to i tak plik wynikowy można potem edytować. Gdyż zawsze pozostaną jakieś blędy konwersji tym bardziej u nas na Atari przy ograniczonej liczbie duszków. Tak więc raczej program zamiast xex'a który na dobrą sprawę jest tutaj niepotrzebny powinien mieć zapis do formatu edytowalnego tj mic a najlepiej od razu do g2f gdyż to format dominujący ;) i mający wsparcie dla duszków - a wierzę że Twój quantizator nie przestraszy się duchów i wzorem Ghostbusters parę złapie (Zuul'a może nie złapie ale inne równie wredne jak Pm0 czy Pm1)
    Tebe wielokrotnie mówił że format pliku g2f jest otwarty - ale najlepiej to z nim obgadaj.
    
    Tak czy siak jeszcze raz dzięki za zajęcie się tym trudnym tematem. To jest jednak coś co interesuje rzesze atarowców - wystarczy popatrzeć na co rusz pojawiające się konwersje obrazków na forum, lepsze czy gorsze ale cały czas, cały rok obecne. Zainteresowanie tym jest niesłabnące. Jako że ja pod względem programistycznym jestem zero bezwzględne - jedynie czym cię mogę wspomóc to tylko tym że na taki program czaka naprawdę wielu, i gdyby Ci się udało to pomnik masz jak w banku ;)
14. • 14: CommentAuthortebe
    • CommentTime7 Jan 2010 18:01

     
    format pliku G2F nie jest z góry ustalony, w nowej wersji znowu uległ zmianie, potrzebne były dodatkowe informacje o trybie z wierszami wysokości 4 linii
    
    najłatwiej będzie dodać odczyt jakiegoś nowego formatu aniżeli męczyć się z G2F, jakiś czas temu wprowadziłem pliki MCH, które integrują MIC i INV, dodatkowo można dodać informację o kolorach i będzie taki G2F bez PMG
    
    w MCH informacje zapisane są po 9 bajtów, pierwszy bajt ($00 lub $80) to informacja o inwersie znaku, następne 8 bajtów to dane znaku, plik kończy się 5-oma bajtami z informacją o kolorach 712,708,709,710,711
    
    czyli MCH zapisuje obecnie maks 5 kolorów, ale można rozszerzyć go o informację o kolorach w każdej linii, dodatkowo G2F na podstawie długości pliku MCH ustawia automatycznie odpowiednią rozdzielczość
15. • 15: CommentAuthormono
    • CommentTime7 Jan 2010 19:01 zmieniony

     
    Spektroskop był pomyślany, jako narzędzie do wyświetlenia grafiki z ZX Spectrum na Atari. Wykorzystuje hires z DLI i wszystkie sprajty (4/5 players i 4 missiles) do podkolorowywania trybu w celu emulacji mapy kolorów dlatego, że jest to tryb najbardziej zbliżony do ZX Spectrum. Nie wykorzystuję zmian koloru w trakcie rysowania linii (pomyślę nad tym po ukończeniu obecnej wersji).
    Założenie było takie, że w całej linii kolor znaku się nie zmienia (jest czarny), natomiast zmienia się kolor tła. Ma ograniczenia, bo nie mamy szans (bez VBXE) wykorzystać 15 kolorów w linii - ale da się 8 (a być może nieco więcej - trzeba by poeksperymentować jeszcze z priorytetem 0 PMG). Szerokość sprajtów x4 jest konsekwencją wykorzystania sprajtów do emulacji atrybutów (czyli podkolorowywania kwadratów 8x8 pikseli), niezależnie od tego jednak treść, pozycja i kolor sprajta oraz konfiguracja GTIA (4/5 players) musi był wyliczona dla każdego wiersza z osobna, bo playery mają szerokość 8 "pikseli" a missiles 2 "pikseli" i nie można dowolnie pokryć różnokolorowymi sprajtami całego wiersza.
    Modyfikacja algorytmu (po jego dopracowaniu o multicolor i priorytet 0 oraz ukończeniu) wymagałaby dopuszczenia obliczania dodatkowo szerokości sprajta (x1, x2 i x4), priorytetu PMG i zmiany "rozdzielczości" dla której przeprowadzane byłyby obliczenia - aktualnie jest to 32x24 - nic nie stoi na przeszkodzie, żeby było to 40x24, 80x24, 160x192 czy 80x192 tym bardziej, że obliczenia nie muszą się dokonywać na Atari - na Atari ma być prezentowany wynik.
    Algorytm jest prosty i opiera się na policzeniu statystyki wykorzystania kolorów w wierszu i rozłożeniu ich na ekranie, po czym w zależności od tego przyporządkowania grupom pikseli odpowiednich sprajtów tak, aby uzyskać żądany efekt (kolor tła wiersza jest przyporządkowany kolorowi, który najczęściej występuje). Następnie następuje minimalizacja zmian wartości kolorów i położenia sprajtów z wiersza na wiersz. W dalszej kolejności przesuwane są zmiany kolorów i położenia sprajtów, które mogą być wykonane wiersz wyżej ponieważ treść sprajta jest pusta.
    Na początku mapa atrybutów (ZX Spectrum) jest przeglądana pod kątem wyeliminowania znaków, które są całe czarne, ale mają zdefiniowany kolor tła (bo nie jest on przecież widoczny, kiedy cały chunk 8x8 ma punkty w kolorze atramentu czyli czarne).
    Do zrobienia pozostało mi jeszcze:
    1. Posortowanie rozkazów DLI modyfikujących położenie sprajtów i ich kolorów tak, aby zminimalizować zniekształcenia obrazu i mruganie pojedynczych linii skanningowych.
    2. Nakładanie sprajtów w celu uzyskania "pikseli" o dodatkowych kolorach (tryb multicolor).
    3. Wykorzystanie priorytetu 0 PMG.
    4. Zmiany kolorów w linii (ale to dopiero w następnej wersji programu).
    DLI występują tylko w tych wierszach, gdzie jest to niezbędne.
    
    Edit: Wykonywana jest jeszcze modyfikacja treści obrazu kiedy to kolor tła jest czarny, a znak w kolorze innym. Kolory tła i znaku w mapie atrybutów są zamieniane, a treść obrazu odwracana, ale na sam algorytm rozkładania sprajtów nie ma to żadnego wpływu.
16. • 16: CommentAuthorKonop
    • CommentTime7 Jan 2010 19:01

     
    Dobrym pomysłem byłoby wprowadzenie generycznego formatu (XML) opisu zmian kolorystycznych grafiki. Quantizator mógłby w łatwy sposób generować taki pośredni plik w formie czytelnej dla człowieka. Taki plik mógłby w pierwszej fazie zawierać dane bez uwzględnienia daleko idących więzów integralności wynikających z ograniczeń układów graficznych Atari. Inny program lub ten sam mógłby dokonywać później analizy tego pośredniego pliku (Level 1) i stosować inne algorytmy dopasowujące go do poziomu "Level 2" uwzględniającego wszystkie ograniczenia sprzętowe. Dzięki temu uzyskujemy rozbicie problemu na dwa mniejsze oraz modularną architekturę, pozwalająca na tworzenie osobnych narzędzi przez różne osoby. G2F mógłby odczytywać taki format wraz z osobnymi, surowymi danymi graficznymi.
17. • 17: CommentAuthorirwin
    • CommentTime7 Jan 2010 19:01

     
    @Mono, i tak trzymaj! :) Potenciał Twój Spectroskop ma a z uwagi iż xxl raczej poszedł w kierunku kolorowania vbxe'em, szkoda żeby się zmarnował. Pecety mają pod maską mnóstwo mhz więc można i trzeba to wykorzystać, sprawdzając jak piszesz każdą kombinację. Odnośnie piorytetu 0 - pewnie nie uwierzycie ale dopiero ostatnio "odkryłem" ;) tę możliwość, naprawdę ciekawe.
18. • 18: CommentAuthormono
    • CommentTime7 Jan 2010 19:01

     
    @irwin: efekt widać w praktyce :) Gratulacje za zajęte miejsce.
19. • 19: CommentAuthorirwin
    • CommentTime7 Jan 2010 19:01

     
    Dzięki! ale jak Tebe wie "odkrycia" ;) (jak ja jeszcze mało wiem o g2f) dokonałem dopiero parę dni temu i ten obrazek z kompo jest normalny, z 9 kolorami w linii max tj. bez piorytetu0. A narazie testuje/eksperymentuje np myślę że obrazek Ripka z kompo dałoby się zrobić bez zbytniego pogorszenia w trybie no-interlace. Zaczynam poznawać zasady, tj Tebe wyjaśnił mi schemat powstawania nowych barw na duszku ale trzeba odpowiednio dobrać kombinacje kolorów, a to trwa wieki. W każdym razie z pewnością zrobię obrazek z tym piorytetem0 i ditheringiem który stosuje Ripek.
20. • 20: CommentAuthorilmenit
    • CommentTime8 Jan 2010 13:01 zmieniony

     
    Quantizator v0.7
    Ta wersja nie generuje XEX, ale pliki MIC i COL dla G2F.
    Zmian sporo - czekam na komentarze :)
    
    
    
    EDIT: Quantizator domyślnie używa palety Laoo. Ją też trzeba wczytać do G2F i "Apply Adjustment"

    • Quantizator2.zip
21. • 21: CommentAuthorilmenit
    • CommentTime8 Jan 2010 18:01 zmieniony

     
    Wersja 0.85
    
    Dodane sortowanie palety minimalizujące zmiany kolorów (przydatne do poprawek w G2F).
    Najciemniejsza kolumna kolorów jest ustawiana jako COLBAK.

    • Quantizator3.zip
22. • 22: CommentAuthorirwin
    • CommentTime8 Jan 2010 18:01

     
    Teraz efekt konwersji wygląda lepiej, zwłaszcza dodano możliwość konwersji XXXx240 a nie XXXx192 jak ostatnio. Ten tytułowy obrazek z Secret of the Monkey Island wyglądał już poprzednio dobrze teraz jeszcze lepiej. Aż dziw że ma tylko 4 kolory w linii. Znakomicie że zmieniłeś zapis z xex do mic/col. Jednak pełnia szczęścia będzie gdy w konwenterze zadomowią się ... duchy ;)
23. • 23: CommentAuthorilmenit
    • CommentTime8 Jan 2010 18:01

     
    Z duchami będzie ciężko...
    Cała siła i problem z grafiką Atari to zmienianie palety co linię. Nawet prosty dithering Floyda–Steinberga nie ma racji bytu, bo nie ma gwarancji, że błąd koloru w kolejnych liniach zostanie zminimalizowany...
    Ale z duchami to wyzwanie, popróbuję :)
24. • 24: CommentAuthorirwin
    • CommentTime8 Jan 2010 18:01 zmieniony

     
    Z ditheringiem - wiem o tym. No i tym bardziej warto aby program jakoś... uduchowić ;) (spoko jeszcze się nie wyprztykałem, jeszcze mam parę skojarzeń w zanadrzu ;)
    Czasami przecież jest w linii jakiś niewielki obiekt/kolor - idealny na duszka. A teraz jest z reguły tracony.
    
    Po drugie komodziarze mają, my dotychczas nie, może Ty pierwszy spróbujesz poprowadzić natarcie, na tę niezdobytą fortecę, może polegniesz - ale przynajmniej spróbujesz, Glory ->link<- będziesz miał zapewnioną.
    ;)
25. • 25: CommentAuthorvega
    • CommentTime8 Jan 2010 21:01

     
    też by mi się przydał taki konwerter z "duchami":) na maksa można by wykorzystać możliwości graficzne ATARI w grach:)
26. • 26:
       
      CommentAuthorKaz
    • CommentTime9 Jan 2010 03:01

     
    Przylaczam sie do choru piesniarzy spiewajacych "tez by mi sie przydal taki program..." :D
27. • 27:
       
      CommentAuthormiker
    • CommentTime9 Jan 2010 08:01

     
    Tak, duszki i ściganie plamki też by się przydało. Nawet niech generuje ERROR-y w G2f, zawsze można wtedy popoprawiać, bo już wiadomo co. Ogólnie fajny wynalazek. Kiedy support dla Gr.10?
28. • 28: CommentAuthorilmenit
    • CommentTime9 Jan 2010 20:01 zmieniony

     
    Wersja 0.9
    Trzy przydatne opcje:
    /lock - służy do definiowania koloru obowiązującego we wszystkich liniach. Można dzięki temu ustawić kolor tła na czarny, albo np. ustalić 4 kolorową paletę dla calego obrazka.
    /col - umożliwia wczytanie predefiniowanego zestawu kolorów. Po wczytaniu są optymalizowane dla zmian DLI.
    /nsort - wylacza sortowanie kolorów, co przyspiesza testy.
    
    Konwerter z duchami i śledzeniem plamki... Pomyślimy...
    A na razie czekam na komentarze odnośnie aktualnej wersji.
    
    Dlaczego w przypadku trybu GED-- plik wykonywalny pokazuje czasem glupoty?
    Check pokazuje 4 zmiany koloru w linii i ERROR, czy to dlatego?
    Jeżeli tak, to nie rozumiem dlaczego, skoro po 4 zmianach jest wsync.
    Chyba nie brakuje czasu procesora, bo przesunięcie plamki jest na swój sposób zsynchronizowane z pracą cpu, dzięki czemu może działać GED?
    
    Napisałem mały programik, który w każdej linii zawsze robi 4 zmiany i on działa.
    Załączam wywalający się plik G2F i mój programik testowy (naprzemiennie ustawia ciemniejszy odcień koloru).

    • quantizator09.zip
    • test.zip
29. • 29: CommentAuthortebe
    • CommentTime9 Jan 2010 22:01

     
    jeśli jest przekroczony limit to G2F nie zapisze nic ciekawego (dla GED-- 3 zmiany na linie), liczba zmian dokonywana przed programem zmian rastra podyktowana jest stałą długością programu zmian rastra
30. • 30: CommentAuthorilmenit
    • CommentTime11 Jan 2010 12:01

     
    Prośba do grafików. Pobawcie się proszę Quantizatorem i dajcie mi znać jaka inna funkcjonalność (oprócz ścigania plamki i duszków - pracuję nad tym) by się przydała. Od lutego będę miał mniej wolnego czasu.
31. • 31: CommentAuthorilmenit
    • CommentTime12 Jan 2010 11:01 zmieniony

     
    Wersja 0.96
    
    Ważna poprawka buga w parsowaniu parametrów. Używający 0.95 proszeni są o zmianę na 0.96
    
    Wersja 0.95
    
    - Nowy algorytm wyboru koloru - daje lepsze rezultaty dla obrazków o wyraźnych kolorach.
    - Nowa miara podobieństwa koloru - znacznie lepsza od euklidesowej.
    
    Ponieważ z każdą dodaną opcją liczba kombinacji możliwych opcji rośnie, dodałem dwa nowe tryby pracy:
    - preview - tworzy do podglądu kombinacje większości opcji
    - fastpreview - jak preview, ale z wyłączeniem czasochłonnych lub prawdopodobobnie kiepskich wyników.

    • Quantizator096.zip
32. • 32: CommentAuthorilmenit
    • CommentTime13 Jan 2010 15:01 zmieniony

     
    Wersja 0.97
    
    - dla /fastpreview i /preview działają dodatkowe parametry (np. /h=192) is są one przekazywane do plików .bat
    - Generowany jest plik XEX (gr. 15) gdy width<=160 i height<=192
    - Działa przycisk kończący aplikację
    - Poprawka: był błędnie zapisywany parametr do pliku .bat

    • Quantizator097.zip
33. • 33: CommentAuthorilmenit
    • CommentTime13 Jan 2010 17:01

     
    Jeżeli wrogowie w MrProper / MrPlum by się poruszali jedynie poziomo, a pionowo byli zrobieni na duszkach, to...

    • MrPlum.xex
34. • 34: CommentAuthorirwin
    • CommentTime14 Jan 2010 22:01

     
    @ilmenit: "Pobawcie się proszę Quantizatorem i dajcie mi znać jaka inna funkcjonalność (oprócz ścigania plamki i duszków - pracuję nad tym) by się przydała. "
    
    To co uzyskałeś obecnie jest wystarczające aż nadto. Więcej z 4 kolorów w linii się nie wyciśnie. Funkcjonalność jest również bez zastrzerzeń, rworzy pliki mic/col i to wszystko co potrzeba. Jak więc piszesz że w lutym będziesz miał mniej czasu to najwyższa pora zająć się Gozerem... tj jest duszkami. ;)
35. • 35: CommentAuthorilmenit
    • CommentTime15 Jan 2010 10:01

     
    Z moich wstępnych testów wynika, że mimo wykorzystania duszków i ścigania plamki cudów nie będzie. W linii uzyska się maksymalnie 2-3 kolory więcej (bez gwarancji, że w miejscu, gdzie odbiorca więcej kolorów oczekuje), ale późniejsza korekta będzie masakrycznie ciężka, bo nawet mała edycja rozwali kolory w kilku kolejnych liniach...
    
    Nie wiem, czy nie lepiej pozostawić piąty kolor i duszki do retuszu 4-kolorowego wyniku Quantizatora.
36. • 36: CommentAuthorgorgh
    • CommentTime15 Jan 2010 13:01 zmieniony

     
    ale jakby to się udało zrobić choćby w części, pomyśl jaki szacun byś miał w środowisku!:)Zadanie trudne ale chyba gra warta świeczki.
37. • 37: CommentAuthormono
    • CommentTime15 Jan 2010 14:01

     
    @ilmenit: Czy mógłbyś pokazać efekt działania ostatniego quantizatora? Nie mam windowsa i nie bardzo mam jak sobie pooglądać :)
38. • 38: CommentAuthorilmenit
    • CommentTime15 Jan 2010 14:01

     
    @gorgh - Zadanie nie aż takie trudne :) Linię trzeba podzielić na mniejsze fragmenty i wykorzystać funkcjonalność blokowania zmian kolorów, którą już mam. Wykorzystanie duszków też proste - na obrazku dajemy jeden kolor więcej i na koniec zamieniamy go albo na kolor tła + maska duszka, albo na najbliższy kolor z palety linii, jeżeli w tym miejscu nie da się postawić duszka.
    Ale jak napisałem wcześniej, ze wstępnych prób wynika, że jakość obrazków się bardzo nie zwiększa.
    
    @mono - pod Wine nie działa?
    Troche obrazków wrzuciłem na AtariAge
    ->link<-
39. • 39: CommentAuthormono
    • CommentTime15 Jan 2010 15:01

     
    Dzięki za (k)linka. Nie używam Winka :)
40. • 40: CommentAuthorilmenit
    • CommentTime15 Jan 2010 17:01

     
    Jeżeli przypadkiem źródła miałyby się stracić, to załączam.
    Nie są ładne, ale program stał się znacznie bardziej rozbudowany niż początkowo planowałem, a na większe sprzątanie w kodzie czasu brak.

    • quantizator_src.zip
41. • 41: CommentAuthormono
    • CommentTime16 Jan 2010 02:01 zmieniony

     
    Skompilowałem to na linuxa x86_64 (plik compile.sh).
    Co zmieniłem:
    1. Parametry są porównywane case-sensitive.
    2. Generowany jest plik .sh a nie .bat
    3. Nazwa pliku to Quantizator a nie Quantizator.exe.
    Kompilacja przebiegała na Ubuntu 9.04 x86_64 z gcc-4.3.3 i zainstalowanymi bibliotekami allegro-4.2.2 oraz freeimage-3.10.0; można je zainstalować za pomocą:
    

    # apt-get install liballegro-dev libfreeimage-dev
    

    
    
    @ilmenit: Czy mógłbyś przejrzeć kod pod kątem ewentualnych problemów/niezgodności z Windows?
    
    Edit: Zmieniłem też wielkość liter w nazwie pliku XEXFILE.H - teraz jest małymi tak, żeby odpowiadał include'owi w main.cpp.
    
    Edit 2: Wszystkie \ w ścieżkach do plików zostały zastąpione przez /.
    
    Edit 3: Zrobiłem też prosty makefile (zamiast compile.sh) - można robić make i make clean. W razie gdyby skrypt miał problemy ze znalezieniem biblioteki allegro można w LINKERFLAGS zmienić -lalleg na -lalleg-4.2.2.

    • quantizator_src_20100115_linux.zip
    • Makefile
42. • 42: CommentAuthorgorgh
    • CommentTime17 Jan 2010 22:01 zmieniony

     
    "Ale jak napisałem wcześniej, ze wstępnych prób wynika, że jakość obrazków się bardzo nie zwiększa."
    Z programu nie korzystałem ale z obrazków zamieszczonych tu i na planetarnym forum atarowców AA wnioskuję, że czasami w linii brakuje właśnie jednego bądź dwóch kolorów, które mogłyby maskować przekłamane kolory elementów obrazka (jak twarz i płot w konwersji obrazka z przygodówki powyżej), a poza tym 6 kolorów to 50% więcej niż 4, więc jakość powinna się zwiększyć.Jest dobrze, ale rozumiesz, człowiekowi ciągle mało :>.
    Tak czy siak powodzenia w projekcie(jeśli planujesz jeszcze coś dodawać), niedługo sam siadam do SDL`a co by napisać małe narzędzie graficzne.
43. • 43: CommentAuthorirwin
    • CommentTime18 Jan 2010 16:01

     
    @Ilmenit, zgadzam się Gorgh'em, wierz mi jest różnica pomiędzy obrazkiem z duszkami a bez. ;)
    
    
    
    
    Skoro człowiek potrafi, skoro konwentery na C64 potrafią to może kiedyś i jakiś programista atarowy będzie potrafił. Wiem że to trudne, że będzie trzeba część zmian w linii użyć na duszki a nie na kolory - ale to nawet dobrze. Bo jeśli początkujący grafik (bo to do nich ten program jest przecież skierowany) z czymś ma kłopoty to nie z kolorami - to pikuś - a właśnie z rastrami czy duszkami.
44. • 44: CommentAuthortebe
    • CommentTime18 Jan 2010 17:01

     
    irwin jak możesz porównywać ducha C64 który jest już w 4 kolorach w konkretnej rozdzielczości 12x21 piksli z duchem XE/XL który ma tylko jeden kolor i szerokość 8 piksli, to jest nieporównywalne (przeszło połowa układu VIC-II to obsługa duchów, bez duchów C64 to tylko złom)
45. • 45: CommentAuthorirwin
    • CommentTime18 Jan 2010 18:01 zmieniony

     
    Oczywiście że C64 jest w pewnych aspektach o niebo lepszy niż Atari. Dlatego nie chodzi mi oto by zrobić coś lepszego lub na takim samym poziomie jak w C64 bo to nierealne, z wielu powodów ot chociażby takim iż komodziarze praktycznie nie używają duszków multicolor do podkolorowywania grafiki trybu 2x1, więc trudno porównać coś co u nich praktycznie nie istnieje. Mają FLI i nie potrzebują duszków do pokazania grafiki w trybie lowres 2x1 ( tak więc bez duszków - jeśli mówimy o samej statycznej grafice, a tego dotyczy ten wątek, - c64 wcale nie jest takim złomem ;)
    
    Natomiast warto się przyjrzeć jak podkolorowywują swój hires aby podobne pomysły wykorzystać przy naszym atarowskim lowresie, który jest tematem Quantizera.
    
    Nie jestem ekspertem, po prawdzie zbytnio się nie znam, a z pewnością w tej dziedznie nie mam nawet 1/10 wiedzy co Ty tym niemniej:
    Zobacz zatem jak działają tryby MUSC czy NUFLI
    Pierwszy co prawda korzysta z duszków multicolor ale są one powiększanie i ich realny piksel ma... 4x1! - czy to czasem czegoś nie przypomina? Skoro podkolorywują hires 1x1! to po co im piksle kafle 4x1? Realna res jest wtedy 80x200. Z pewnością owe duszki są używane z maskowaniem na nich ich rozdz przez użycie innego koloru - tak jak to można zrobić w znakomitym Graph2Font jeszcze bardziej znakomitego autora ;)
    NUFLI zaś korzysta z jednokolorowych duszków hires które znów są ... powiększane i to tym razem nie tylko w poziomie ale i pionie! Czasami nawet 6x! Technika maskowania znów pewnie podobna.
    
    Tak więc nie jest to tak ładnie i bez problemów, oni też muszą się zmagać z ukryciem rozdzielczości tych duszków. Choć nie mają możliwości wyświetlenia duszka o wielkości 200 linii jak u nas to i tak jak piszesz mają więcej możliwości, zgadzam się z Tobą, i nawet w trybie hires ich podkolorywanie w stosunku do naszego w lowres jest lepsze.
    Jednak mając powyższe na uwadze nie oznacza to iż musimy używać duszków jedynie o szerokości 8 piksli 2x1, jak piszesz a można je powiększać gdyż oni też to robią i umiejętnie ukrywają nie mozolnie, ręcznie a programowo poprzez algorytm zawarty w konwenterze.
    
    Zresztą załóżmy hipotetycznie że C64 nie istnieje i nigdy nie istniał ;)
    Patrząc np jak potrafią podkolorować tacy geniusze jak Ooz czy Piesiu - czy komputer czyli konwenter nie mógłby zrobić coś podobnego? Po pierwsze bo człowiek potrafi, przykład Ooza powyżej a tym samym i komputer odpowiednio zaprogramowany powinien to zrobić. W końcu do tego został wymyślony aby przyspieszyć uciążliwe zadania a tym są właśnie ustawiania duszków, maskowania ich rozdz. czy ustawianie rastrów, jednocześnie nadzorując aby wszelkie limity zmian w linii były ok, z czym niektórzy jak wiesz mają problemy ;)
    
    Ja nie piszę tu o sobie, bo ja tam sobie lepiej czy gorzej dam rade, wolę sam ustawić dokładnie co trzeba, ale jest wiele osób które nie potrafią, albo gdy widzą ile z tym roboty to się zniechęcają i sobie darują. Oczywiście że taki konwenter z pewnością nie generowałby idealnej kombinacji jak Ooz czy Piesiu. Ale początkującym by z pewnością pomógł.
46. • 46: CommentAuthorilmenit
    • CommentTime18 Jan 2010 19:01

     
    Spoko, zmiany koloru w linii i duszki dodam, ale potrzebuję więcej wolnego czasu. Mam do dokończenia dwa inne atarowe projekty (Quantizator powstał tak naprawdę dlatego, że brakowało mi do jednego grafiki :)).
    Mono, jak wrócę do PL to odezwę się do Ciebie, bo jeden z projektów fajnie będzie też dostosować do linuxa :)
47. • 47: CommentAuthormono
    • CommentTime18 Jan 2010 21:01

     
    Nie ma sprawy. Pomogę na ile tylko będę potrafił.
48. • 48: CommentAuthortebe
    • CommentTime19 Jan 2010 21:01

     
    w sumie pliki MIC i COL są nie potrzebne dla G2F, wystarczy wczytać taki przetrawiony Quantizatorem plik BMP itp. (po 4 zmiany na linię) do G2F, zaznaczyć Smart Colors i wyjdzie to samo
49. • 49: CommentAuthorirwin
    • CommentTime25 Jan 2010 10:01

     
    Ilmenit vs Tebe 0:1
    ;) a dlaczego? szukajcie a znajdziecie...
    
    ps. Brawa zarówno Ilmenitowi jak i Tebe, nic tak dobrze nie robi jak współzawodnictwo.
50. • 50:
       
      CommentAuthorKaz
    • CommentTime25 Jan 2010 10:01

     
    A co biega? Bo nie wiem, gdzie szukac?