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: CommentAuthor0xF
   • CommentTime19 Sep 2021

    
   Niestety utknąłem przy kompilacji RastaConvertera. Problem jest, że on jest jakoś mocno "mentalnie" powiązany z MicrosoftWindows i starszą biblioteką allegro, która z kolei ma opory żeby ją przekompilować dla nowszych zależności

   
   
   Utknąłeś na tym samym etapie co ja. Proponuję połączyć siły. W takim razie odkryję karty. :)
   
   Na początku sierpnia zaimplementowałem w Ć odczyt obrazków RastaConvertera (w postaci czterech plików: MIC+PMG+RP+RP.INI): ->link<-
   
   Zastanawiam się nad przepisaniem RastaConvertera na OpenCL. Dzięki temu działałby na GPU. Spodziewam się wzrostu wydajności wielokrotnego. Nawet zintegrowane GPU powinno nieźle sobie radzić, a co dopiero nowy GeForce. Od 9 do 17 developuję ->link<-
   
   Wydaje mi się, że możnaby to zrobić jako apkę konsolową, która wypisuje status na stdout i zapisuje PNG, który obejrzymy zewnętrzną aplikacją. Szkoda czasu na zabawę z Allegro 5, nie wygląda to na prostą przesiadkę.
   
   RastaConverter ma kilka forków na GitHubie i są tam jakieś commity. Chętnie bym się dowiedział, czy jest tam coś istotnego.
   
   Główny problem jest taki, że nigdy nie używałem RastaConvertera i czekam na tego YouTube-a. :)
2. • 2:
      
     CommentAuthoramarok
   • CommentTime19 Sep 2021

    
   @0xF, w oczekiwaniu na filmik proponuję, żebyś zerknął na prezentację, którą pokazywałem podczas spotkania.

   • RastaConverter-warsztaty.pdf
3. • 3: CommentAuthorilmenit
   • CommentTime19 Sep 2021

    
   0xF - inicjatywa zacna! Myślę, że bardziej wchodzi w grę napisanie od podstaw na OpenCL niż dostosowywanie istniejącego kodu. Za chwilę wyjaśnię dlaczego.
   Najnowszy fork na GitHubie to ten Ivopa ->link<- ale nie przeglądałem dokładnie co tam zmieniał - jak widzę głównie czyścił kod i wprowadzał niewielkie poprawki dostosowując go do bardziej współczesnych kompilatorów, oraz trochę eksperymentował z mutacjami obrazka.
   
   Polecam zerknąć na FAQ w Wiki ->link<-
   
   Odnośnie pisania na OpenCL polecałbym nie portować najnowszej wersji, ponieważ był to kod mocno zoptymalizowany (różne cache) i wielowątkowy, przez co jest bardzo trudny do zrozumienia. Zdecydowanie bardziej polecałbym jakiś starszy commit, np. ten przed wprowadzeniem wielowątkowości:
   ->link<- ... ewentualnie jeszcze jakiś starszy.
   
   Biblioteka Allegro jest w tym projekcie opcjonalna i można by generować obrazek do PNG. Kiedyś planowałem dodać "tryb interaktywny", w którym można by kontrolować proces konwersji w jej trakcie (np. ustalać lokalną maskę detali).
   Nigdy nie przeportowałem z Allegro 4 na Allegro 5, bo tam porzucili wsteczną kompatybilność (jak przy przejściu z SDL 1 na 2). Jako GUI jak jest teraz mogłoby być cokolwiek, bo to tylko wyświetlanie trzech obrazków na ekranie (oryginalny, docelowy w palecie Atari i z ditheringiem, oraz środkowy aktualny).
   
   Proponowałbym jednak usiąść do projektu od podstaw i ewentualnie bazować na koncepcie (im starsza wersja na GitHubie tym prościej kod zrozumieć), ponieważ RC ma kilka niedociągnięć.
   Najważniejsze to błąd w emulacji Antica związany z repozycjonowaniem duszków. Aktualnie RC nie obsługuje sytuacji, gdy duszek zmienia pozycję w taki sposób, że nachodzi sam na siebie. Więcej w tym wątku: ->link<- - w innym, ale nie mogę na szybko znaleźć Phaeron opisywał prawidłowe zachowanie. Błąd jest głównie widoczny przy programie uruchomionym przez długi okres czasu, gdy program dla poprawy obrazka zaczyna multiplikować duszki w linii.
   Albo trzeba by poprawnie zaemulować zachowanie Antica, albo przy emulacji programu rastra odrzucać rozwiązania, w których takie przekrycie następuje.
   Kolejna rzecz to użyty tryb graficzny - wszystko bazuje na GR.15, ale robiąć warstwę abstrakcji odnośnie cyklowania można by zaimplementować tryb tekstowy 5 kolorowy, co potencjalnie znacznie by poprawiło jakość.
   Też zmiana, którą planowałem na przyszłość to generowanie dwóch obrazków jednocześnie i liczenie odległości z "uśrednionego" koloru piksela. Przy zastosowaniu podobnej jasności (siła błędu mnożona przez różnicę jasności) można by zminimalizować mruganie i zrobić interlace. Myślę, że takie obrazki to byłaby kolejna "nowa jakość".
   Co jeszcze - system mutacji jest całkiem dobry, ale jest w pełni losowy. Można by raz na jakiś czas robić "sweep" poprzez cały program rastra i robić modyfikacje wartości +1,-1,+16,-16.
   Jak chodzi o algorytm optymalizujący to testowałem wiele i "Late Acceptance Hill Climbing" zdecydowanie wygrywał. Potem autor tego algorytmu wymyślił jego "poprawioną wersję" (Step Counting Hill Climbing Algorithm) ale już nie implementowałem. Potem były jeszcze tego usprawnienia ->link<-
   
   Ja bym jednak proponował pozostawić takie pomysły na przyszłość i zrobić jak najprostszą wersję na GPU, która będzie poprawnie emulować Antic i program rastra.
   
   Chętnie będę służył pomocą, ale głównie merytoryczną, bo czasu niestety na hobby i programowanie bardzo mało.
4. • 4:
      
     CommentAuthorgienekp
   • CommentTime19 Sep 2021

    
   Dzięki za cenne informacje! Spróbuje rozbić sobie kod na "dwa światy". Ja od jakiegoś czasu w kodach robię tak, że "engine" czy jako to tam nazywać, wykorzystuje tylko <stdio.h>. Wiem, że szalone ale niezawodne. Potem interfejsy graficzne i wszystkie bajery robię w Qt i tu od razu robię sobie wersję Windows/Ubuntu/MacoS/Android. Chodzi o to, żeby kluczowy kod nie był niczym skażany. W zasadzie RastaConverter albo coś ala libRastaConverter może pobrać z stdin tablicę 320x240 bajtów gdzie każdy kolejny bajt to Atarowski kolor 0-255. Wynik wywali na stdio i po sprawie. GUI Qt bez problemu przygotuje wstępnie JPGa czy PNG czy co tam jeszcze. Przeskaluje do tej tablicy itd. Po prostu to już świat dawno zrobił dobrze i nie potrzeba otwierać otwartych drzwi. Natomiast główny algorytm RastaConvertera to dla mnie jakaś MAGIA. I pytanie, emulator ANTICa bierze udział tylko w wizualizacji czy może siedzi w pętli sprzężenia zwrotnego dla iteracyjnego algorytmu?
5. • 5: CommentAuthor0xF
   • CommentTime20 Sep 2021

    
   Dzięki za odpowiedzi!
   
   @amarok: Czy są jakieś opcje RastaConvertera, które uważasz za zbędne? I w drugą stronę, czego brakuje?
   
   @ilmenit: Wiem, jak działa nałożenie duszka na samego siebie. Jest trochę nieintuicyjne, szczególnie w poczwórnej szerokości. Pytanie, czy działa tak samo na wszystkich egzemplarzach Atari i wystarczy je zemulować, czy są różnice i należy go zabronić, tak jak piszesz?
   Z czego wynika ustalony na stałe priorytet "duszki za grafiką", wyłączony multicolor duszków i poczwórna szerokość? Czy chodziło wyłącznie o uproszczenie emulacji, czy robiłeś eksperymenty i jest to najlepsze rozwiązanie?
   
   Przepisanie nie stanowi problemu, sam się ku niemu skłaniałem. Na początek chciałbym po prostu przenieść RastaConvertera na GPU, a później dopiero ewentualnie eksperymentować. Ponieważ to OpenCL, będzie możliwość wybrania urządzenia (CPU / zintegrowane GPU / dyskretne GPU). I ponieważ to nie CUDA, będzie działać z każdym GPU.
6. • 6: CommentAuthorilmenit
   • CommentTime20 Sep 2021 zmieniony

    
   @0xF: nawet przy idealnej emulacji Antica warto by pewnie dodać opcję odrzucania rozwiązań z nakładającymi się duszkami, aby działało tam, gdzie tego pewnie nie ma (VBXE?) - jak pisał Phaeron ->link<-
   
   Ustalona szerokość i priorytet wynikała z intuicyjnego podejścia, że to da dobre rezultaty przy konwersjach i z uproszczenia emulacji. Zakładałem, że duszki poczwórnej szerokości będą dobrze pokrywały duże przestrzenie jednym kolorem, zaś grafika playfield w wyższej rozdzielczości doda detale.
   Gdyby chcieć wycisnąć takim programem wszystkie soki z możliwości sprzętu, to warto by dodać pełną emulację (wraz ze wszystkimi zmianami w linii ustawień sprzętu) - ale by to spowolniło emulację.
   Powolne jest też porównywanie obrazka docelowego z wygenerowanym i mając ograniczenia można implementować różnego rodzaje cache (gdy stan rejestrów (CPU, grafiki0 i program jest taki sam na początku linii jak na końcu, to wygenerowana linia będzie taka sama. U mnie emulacja działa "po liniach obrazu", choć można by potraktować cały obraz jako jedną linię...
   Z tych powodów implementowałem emulację samemu zamiast kombinować z użyciem kodów np. Atari800.
7. • 7:
      
     CommentAuthorCyprian
   • CommentTime20 Sep 2021

    

   0xF:

   Wiem, jak działa nałożenie duszka na samego siebie. Jest trochę nieintuicyjne, szczególnie w poczwórnej szerokości.
   

   
   
   nie słyszałem o tym wcześniej, możesz napisać coś więcej?
8. • 8: CommentAuthorilmenit
   • CommentTime20 Sep 2021 zmieniony

    
   Odnośnie duszków ->link<-
9. • 9: CommentAuthor0xF
   • CommentTime20 Sep 2021

    
   @Ilmenit Dzięki za wyjaśnienie! Nie zamierzam na początek zmieniać możliwości graficznych.
   
   

   nie słyszałem o tym wcześniej, możesz napisać coś więcej?

   
   Link podany przez Ilmenita to wyjaśnia, ale opiszę też po polsku.
   
   Duszki są generowane z rejestrów przesuwnych, każdy duszek i pocisk ma swój. Zwykle rejestr jest wypełniony zerami, a po dojściu do kolumny HPOS następuje OR (a nie załadowanie) zawartością GRAFxx. W przypadku szerokości pojedynczej daje to efekt taki, że duszek na nowej pozycji nakłada się na dusza na starej pozycji. W szerokości podwójnej i poczwórnej dochodzi dodatkowo dzielnik przez 2 lub 4, który jest resetowany w kolumnie HPOS. Oznacza to skrócenie obecnie rysowanego piksela.
10. • 10: CommentAuthorilmenit
    • CommentTime20 Sep 2021 zmieniony

     
    @0xF - ogólnie wszystko co do projektu dodawałem było dodawane, ponieważ było przydatne w jakimś celu
    
    FreeImage dependency - daje sporo możliwości manipulacji obrazem (contrast, gamma, brightness, resize filters) z linii poleceń zamiast odpalania edytora graficznego.
    
    Parametry:
    init - to bym pominął, i tak najlepiej działa losowa inicjalizacja
    save - autozapisywanie polecam dać jako "default" - w RC tak nie jest, co jest nieintuicyjne dla używających.
    pal - wybór palety ACT to podstawa, każdy preferuje inną i to się nie zmieni ;)
    distance i predistance - ponieważ miara odległości kolorów ma wielkie znaczenie - to polecam zostawić, ewentualnie jako "default" dać Ciede2000 w ramach preprocesu a potem YUV w konwersji.
    dither - zależnie od gradientów i kolorów obrazka różne dithery się sprawdzają lepiej lub gorzej.
    dither_val i dither_rand - też przydatne
    detail - maska detali przydatna ->link<- lub ->link<-
    onoff - możliwość wyłączania użycia duszków w wybranych liniach - gdyby chcieć robić przygodowkę Point & Click.
11. • 11:
       
      CommentAuthorpirx
    • CommentTime21 Sep 2021

     
    @Fox - super robota, OpenCL świetny wybór! Nie mogę się doczekać.
12. • 12:
       
      CommentAuthorgienekp
    • CommentTime22 Sep 2021

     
    @ilmenit
    Też, wydaje mi się, że obraz trzeba potraktować jako jedną długą linię. Bo to tylko monitor składa to od lewego górnego rogu do prawego dolnego. Dla sygnału (ANTICa) i CPU to jest jednowymiarowy ciąg w funkcji czasu. No chyba, żeby pójść po bandzie i najpierw przeanalizować obraz linia po linii. Zobaczyć jakie jest zapotrzebowanie na każdą linię i miejsca gdzie są tylko 2 kolor walnąć "GR.8" a tam gdzie gradienty to "GR.9". No ale wtedy to doszłoby budowanie DL.
    
    Sugerowałbym, żeby jednak obraz wejściowy do analizy był oparty na tablicy bajtów, Gdzie każdy bajt to bezpośrednio kolor ATARI. Po prostu jak jest powiedzmy 0x20 tzn że taki ma być atarowski kolor. Odpada całe zamieszanie z paletami ditheringiem tonacją nasyceniem czy co tam jeszcze. Bo to można zrobić wcześniej w zwykłym GIMPie. Nawet teraz z GIMPa, można wywalić zwykłego RAWa gdzie kolejne bajty to atarowskie kolory.
    
    Pytanie tylko jaka rozdzielczość jest najfajniesza?
    
    P.S. Czemu projektant ANTICa nie wpadł na prosty trik, żeby DMA dla PM zamiast wpisywać bajt do rejestru kształtu, wpisywało do rejestru koloru. Praktycznie zero tranzystorów by na to poszło.
13. • 13: CommentAuthorilmenit
    • CommentTime22 Sep 2021 zmieniony

     
    @gienekp - operowanie po liniach ma swoje zalety (można robić cache wyników emulacji i/lub różnic odległości pikseli) i dla poszczególnych linii, które się nie zmieniły, nie robić ponownie kosztownych operacji, które kiedyś zostały już wykonane. Po dodaniu takiego cache program przyspieszył (o ile dobrze pamiętam) około x100.
    Inny przykład to mutacje programu rastra, które aktualnie działają na liniach - czemu? Bo to przyspiesza uzyskanie poprawnego obrazka. Jeżeli znajdziesz na obrazku losowo miejsce, gdzie warto zmienić jakiś kolor rejestru na inny (bo w całym obrazku spowoduje to pozytywne zmiany), to warto spróbować przenieść tę zmianę linię niżej lub wyżej, bo może za zmiana zmienia zbyt dużo lub warto ją rozszerzyć.
    
    Jako obraz wejściowy warto jednak dać możliwość użycia dowolnego obrazka + preprocess, bo jednak odpalanie GIMPa przed każdą konwersją i konwertowanie do indeksowanej konkretnej palety byłoby dosyć irytujące dla użytkownika. Nie wiem też, czy GIMP ma sensowne parametry ditheringu działające na paletach indeksowanych (mało który program ma).
    Myślę, że dając taką radę bardziej myślisz jak programista niż jak użytkownik ;)
    
    @0xF - odnośnie zmian, to warto by dodać też do emulacji dodatkowe instrukcje INX,INY,DEX,DEY, ponieważ aktualnie są w programie rastra jedynie LD*,ST*. Mała i prosta zmiana a mogłaby poprawić jakość generowanych obrazków.
14. • 14: CommentAuthor0xF
    • CommentTime22 Sep 2021 zmieniony

     
    Czemu projektant ANTICa nie wpadł na prosty trik, żeby DMA dla PM zamiast wpisywać bajt do rejestru kształtu, wpisywało do rejestru koloru. Praktycznie zero tranzystorów by na to poszło.

    
    ANTIC nie adresuje rejestrów GTIA. To GTIA pobiera dane z szyny do rejestrów duszków. Myślę, że możliwe byłoby rozszerzenie, które dzięki separacji GTIA od szyny adresowej umożliwiałoby DMA dla kolorów. Fajne byłoby też sprzętowe przestawianie trybu GTIA.
    
    

    odnośnie zmian, to warto by dodać też do emulacji dodatkowe instrukcje INX,INY,DEX,DEY, ponieważ aktualnie są w programie rastra jedynie LD*,ST*. Mała i prosta zmiana a mogłaby poprawić jakość generowanych obrazków.

    
    To jedynie skróci exe dla Atari, bo te instrukcje trwają dwa cykle, tyle co LD* #.
15. • 15: CommentAuthorilmenit
    • CommentTime22 Sep 2021

     
    To jedynie skróci exe dla Atari, bo te instrukcje trwają dwa cykle, tyle co LD* #.
    

    
    aż otworzyłem ->link<- aby sprawdzić i masz rację. I to chyba powód, czemu 10 lat temu, jak pisałem RC, tego nie dodałem ;)
16. • 16: CommentAuthor0xF
    • CommentTime22 Sep 2021

     
    Każda instrukcja 6502 ma co najmniej dwa cykle. Dopiero wiele lat później powstały klony 6502 wykonujące instrukcje w trybie implikowanym w jednym cyklu.
17. • 17:
       
      CommentAuthorjhusak
    • CommentTime24 Sep 2021

     
    @0xF, tak nawiasem mówiąc, nie uważasz, że implied -> implikowany to trochę niefortunne tłumaczenie? Tylko nic mi innego nie przychodzi do głowy...
18. • 18: CommentAuthor0xF
    • CommentTime24 Sep 2021

     
    Nie wiem, nie znam się na językach.
    Jeden wykładowca na PW mówił o "kierowcach" i "kieszeniach" (cache) i brzmiało to dziwnie.
    Niektórzy twierdzą, że nawet jedna polska litera w dziedzinie programowania to coś dziwnego.
19. • 19:
       
      CommentAuthorpirx
    • CommentTime26 Sep 2021

     
    miałeś wykłady z Jankowskim? :)))
    dwumlask rulz
20. • 20: CommentAuthor0xF
    • CommentTime26 Sep 2021

     
    Nie, Daszczukiem.
21. • 21:
       
      CommentAuthorgienekp
    • CommentTime27 Sep 2021

     
    ... a napędy to "aktorzy" (actuators), profesory mają czas to filozofują.
    
    Wracając do tematu. LDA # + STA COLOR to 6 cykli. Ile pikseli w GR.15 za ten czas przeleci? A dokładniej w GR.10?
    
    Bo wzięło mnie na basicowy GR10. Mam już kod: wczytuję JPG, skaluję na 320x240, potem kadrowanie na 192 (na razie musi być po atarowskiemu). Następnie skalowanie 80x192. Redukcja do palety ATARI. To wszystko wspomagam poleceniem convert z ImageMagic, który moim zdanie jest najpraktyczniejszy w fazie przygotowania obrazka (no i ma kompilację na wszystko co potrzeba).
    Potem już mój kod, gdzie biorę każdą linię z osobna ograniczam ją do 9 kolorów, z tym że jeden kolor to zawsze czarny. Z symulacji wychodzi, że niektóre obrazki wychodzą bardzo barwnie, inne trochę mniej (wiadomo to jednak GR10). Teraz będę generował ASMa i właśnie w tym miejscu się zastanawiam czy zdążę podmienić 8 kolorów przed nadejściem pierwszego piksela z nowej linii. Musze zmieścić:
    LDY #
    LDX #
    LDA #
    -> tutaj musi być moment wyświetlenia ostatniego piksla
    STY c1
    STX c2
    STA c3
    LDA #
    STA c4
    LDA #
    STA c5
    LDA #
    STA c6
    LDA #
    STA c7
    LDA #
    STA c8
    
    6 cykli przygotowania to OK, ale pozostałe 42 to nie wiem czy wyrobię. Bo jak wyrobię, no to GR10 z nową paletą w każdej linii pomaluję. Czyli metoda drąga w płocie, ale bardzo szybka. Potem się zobaczy czy to coś rokuje na więcej.
22. • 22: CommentAuthorilmenit
    • CommentTime27 Sep 2021

     
    Ile pikseli w GR.15 za ten czas przeleci? A dokładniej w GR.10?
    

    
    Tu niestety nie ma prostej odpowiedzi - ile przejdzie zależy od miejsca na ekranie:
    ->link<- strona 75 i kolejne
    U mnie w RC robiłem to tak:
    ->link<-
23. • 23:
       
      CommentAuthorjhusak
    • CommentTime27 Sep 2021

     
    42 cykle to połowa widocznej linii. Nie wyrobisz, bo jeszcze Antic Ci ukradnie.
    Natomiast wyrobisz, jak się posłużysz trikiem a la HAM w Amidze, czyli z linii na linię zmienisz tylko 4 lub 5 kolorów. Komplikuje trochę logikę,ale różnicy nie zauważysz, bo najwyżej w dwóch liniach zmienisz wszystkie kolory.
    
    Chyba, że przeanalizujesz (ale to trudniejsze) i będziesz zwlekał z kolorami, które występują później. Ale to stworzy bardziej widoczne artefakty, niż poprzedni sposób.
24. • 24:
       
      CommentAuthorjhusak
    • CommentTime27 Sep 2021 zmieniony

     
    OFFTOP :)
    
    0xF - na językach nie trzeba się znać. Tzn można, ale wtedy nic nie wyciągniesz z "raw" danych językowych. Oto co znajduję po 10 minutach szukania (znając się na językach w stopniu ogarniania, bo muszę, żeby weryfikować):
    
    Kieszeń występuje w polskim, oraz jako "kiszenia" w ukraińskim i białoruskim (po wstępnym przejrzeniu Wiktionary). Zapewne gdzieś jeszcze będzie stosowana jako drugie określenie, ale nie powinno to zabużyć, tylko pomóc. Osobiście widzę ścisły związek, że kisi się w kieszeniach (ale nie w spodniach, tylko w naczyniach, w których też można coś chować).
    
    W Ang jest cache, w niem Tasche. To cache jest wywodzone "from Vulgar Latin *coacticare "store up, collect, compress"
    A ja patrzę, i jak wół mi to nie pasuje, bo cache jest bardziej jak kieszeń, niż jak ten "odtworzony" *coacticare. Oczywiście samo to nie jest dowodem, ale:
    
    Idę kisić w kieszeni kasę, a w kiszkach kiszkę. Kiesa też stąd, czyli kasa (to akurat zapożyczenie) i cash (from French caisse "money box" (16c.), from Provençal caissa or Italian cassa, from Latin capsa "box") Tak. Kabza, która jest pl, ale też w czeskim i dolnołużyckim (kapsa) (ang keep?)
    
    Wszystko powyżej jest od kisić. Ser (kaiser, cheese) też. A kiszono ho ho ho... lat temu. Ponad 7000. Potwierdzone (patrz sery kujawskie).
    
    Wszystko oprocz niem Tache (oraz fiński: tasku), tam jest od tachać/taskać/taszczyć (ang task).
    
    To wszystko jest w zagranicznych słownikach etymologicznych, tylko to, co odtwarzają z mozołem jako PIE, to się dziwnie z naszym składa w niemal 100%.
    
    Możliwości są dwie: albo zapożyczaliśmy wszystko od wszystkich, albo wszyscy od nas. Pierwsza możliwość jest bardzo mało prawdopodobna wziąwszy na rozległość złowiańszczyzny i jednolitość (nadal) dzisiejszych słowiańskich języków.
    
    A poza tym takie rozkminy to świetna łamigłówka i źródło nieoczekiwanych wniosków.
25. • 25:
       
      CommentAuthorCyprian
    • CommentTime27 Sep 2021

     

    jhusak:

    Ser (kaiser, cheese) też
    ...
    Możliwości są dwie: albo zapożyczaliśmy wszystko od wszystkich, albo wszyscy od nas. Pierwsza możliwość jest bardzo mało prawdopodobna wziąwszy na rozległość złowiańszczyzny i jednolitość (nadal) dzisiejszych słowiańskich języków.
    

    
    pochodzenie słowa "ser" jest prasłowiańskie - "Prasłowo do pnia sur- (p. surowy)"
    ->link<-
26. • 26:
       
      CommentAuthorjhusak
    • CommentTime27 Sep 2021

     
    No niektóre są rzeczywiście prasłowiańskie oficjalnie :) od ser mamy np. serum (w łacinie).
27. • 27:
       
      CommentAuthorgienekp
    • CommentTime27 Sep 2021

     
    Faktycznie nie wyrobię z pełną podmianą. Trzeba linie "zazębiać" pierwsza z drugą, druga z trzecią i sukcesywnie podmieniać paletę, możliwie jak najmniej degradując obrazek.
    Pojawił mi się inny problem. Zauważyłem, że dość duże znaczeni ma przyjęta paleta kolorów. Chodzi o ten pierwszy etap, który potem wpływa przy wywalaniu pikseli. Zachciało mi się wyliczyć matematycznie atarowską paletę. Znalazłem jakie przesunięcia fazowe mają być dla poszczególnych kolorów, ale ni jak nie wychodzi to z modelu HSV. Mało tego, nie wiadomo ile przyjąć nasycenia, bo to przecież już nie ATARI a gałka w TV. Jeden ustawi na 50% inny na maksa. Eksperymentalnie wyszło mi, że większe nasycenia jakoś tak mniej niszczą obrazek, z tym że jest bardziej "oczojebny". Słabe nasycenia ciągną mi piksle do szarości, a tu realnie tylko 8 poziomów.
28. • 28:
       
      CommentAuthorDracon
    • CommentTime27 Sep 2021

     
    @Gienek, a nie można by paletę w skali szarości jakoś przyjąć? I potem do trybów GTIA albo tej #15 z duszkami nałożonymi jako dodatkowe stopnie szarości (plus zmiany w rastrze) ?
    
    W sumie kiedyś używałem tego RASTA.. ale było koszmarnie wolno i nic zbyt ciekawego mi nie wyszło... ;) :P
29. • 29: CommentAuthorilmenit
    • CommentTime28 Sep 2021 zmieniony

     
    @gienekp - widzę, że natrafiasz na te same problemy, które miałem ja. Odnośnie palety kolorów to proponuję dać możliwość wyboru docelowej (.act) - różne palety mają różne pokrycie kolorami przestrzeni barw i z mojego doświadczenia najlepsza (choć nie zawsze) jest ta z emulatora Altirra ->link<- To paleta z wersji chyba 2.0 emulatora, warto by sprawdzić czy aktualnie używana przez Altirra jest lepsza. W przypadku innych palet zbyt wiele kolorów było mapowanych do tych samych wartości palety, co degradowało jakość obrazka.
    Też miałem problem z mapowaniem do szarości - powodem jest miara odległości kolorów, którą używasz (zakładam, że euklidesowa). W przypadku takiej miary odległości dla wielu kolorów o niskim nasyceniu najbliższym kolorem jest szary. Aby adresować m.in. ten problem powstały inne miary odległości kolorów ->link<- i ja w preprocesie używam CIEDE2000 (zdecydowanie najlepsza ze wszystkich testowanych przeze mnie).
    Zerknij na sekcję FAQ ->link<- i "Why some blue colors get violet during conversion?" lub załączone tu obrazki.
    
    Dla obrazka "orig", który na górze ma niskie nasycenie barw, wg odległości euklidesowej (obrazek "euclid") najbliższe kolory są szare. Zaś dla CIEDE2000 mapowanie jest wizualnie znacznie bardziej zgodne z oczekiwaniami użytkownika. Obliczanie tej odległości mam w ->link<-
    
    O ile miara odległości ma olbrzymie znaczenie w mapowaniu obrazka źródłowego na paletę Atari, w późniejszych wyliczeniach nie aż tak bardzo. Mimo wszystko nawet tam odległość euklidesowa dawała najgorsze wizualnie rezultaty, więc użyłem YUV (czyli ważonej euklidesowej) ->link<-

    • orig.png
      
      
      
      
    • euclid.png
      
      
      
      
    • ciede2000.png
      
      
      
      
30. • 30:
       
      CommentAuthorgienekp
    • CommentTime28 Sep 2021 zmieniony

     
    @ilmenit
    Dzięki za cenne rady! Dokładnie jest tak jak piszesz. Mój algorytm na razie nie jest tak sprytny, więc degradacja w kolorach ma mocniejszy wpływ. Za to jest bardzo szybki, wynik mam natychmiastowy, więc porwę się na zbudowanie modelu budowania koloru w systemie PAL. Dam suwak do GUI i user sobie ustawi jakie nasycenie preferuje. Jak mi się nie będzie dokumentacja zgadzać z rzeczywistością to wezmę ATARI na oscyloskop i musi wyjść.
    Na razie mam GUI zrobione. Paletę wezmę gotową, żeby zobaczyć czy całe podejście z GR.10 ma w ogóle sens.
31. • 31: CommentAuthorAdam
    • CommentTime28 Sep 2021

     

    jhusak:

    @0xF, tak nawiasem mówiąc, nie uważasz, że implied -> implikowany to trochę niefortunne tłumaczenie? Tylko nic mi innego nie przychodzi do głowy...

    
    Tryb "implied": "zrozumiały sam przez się" ;) Ewentualnie zastanawiałbym się nad tłumaczeniem "tryb dorozumiany".
32. • 32: CommentAuthortatqoo
    • CommentTime28 Sep 2021

     
    @gienekp: tak przy okazji: Original :)
33. • 33:
       
      CommentAuthorlaoo
    • CommentTime29 Sep 2021

     

    Adam:

    Tryb "implied": "zrozumiały sam przez się" ;) Ewentualnie zastanawiałbym się nad tłumaczeniem "tryb dorozumiany".
    

    
    
    Mamy już na to słowo w j. polski. Jest to "domyślny".
34. • 34: CommentAuthorilmenit
    • CommentTime29 Sep 2021

     
    @gienekp - btw, podobne podejście do Twojego (zmiany palety w liniach) zastasowałem w poprzedniku RastaConvertera (Quantizator), który też działał w Gr.15 ->link<- i ->link<- - źródła ->link<-
35. • 35: CommentAuthorAdam
    • CommentTime29 Sep 2021

     

    laoo:

    Mamy już na to słowo w j. polski. Jest to "domyślny".

    
    "Domyślny", "dorozumiany" - oba te słowa funkcjonują od lat w polszczyźnie, jedno jest często używane, a drugie rzadziej, natomiast wydaje mi się, że ich zakresy znaczeniowe nie pokrywają się w 100%.
    
    "Tryb domyślny" trochę brzmiałoby dla mnie, jakby to miał być tryb "defaultowy". "Dorozumiany" natomiast bardziej kojarzy mi się z tym, że trzeba jeszcze sobie coś "domyślić", "dorozumieć", dopowiedzieć.
    
    W tym wypadku intencją użycia "implied" była jak rozumiem taka, że w przypadku rozkazu bez operandów procesor na podstawie rozkazu jednoznacznie "dopowiada" sobie np. skąd dokąd ma przesłać dane.
    
    Nie jest to idealne tłumaczenie, dlatego napisałem "ewentualnie zastanawiałbym się", a nie "tak należy tłumaczyć" :)
36. • 36:
       
      CommentAuthorjhusak
    • CommentTime29 Sep 2021 zmieniony

     
    samookreślony, samowynikający :) samostanowiący...
    
    Tryb wynikowy, tryb wynikający. Albo wynikany :)
    
    To wynikany/wynikowany (imiesłów) jest lepsze, niż wynikowy (przymiotnik)
    
    Tryb wynikowany. Tryb wynikowy. Po chwili namysłu jednak wynikowy, bo z niego wynika.
    
    Tryb domniemany :D
37. • 37:
       
      CommentAuthormaly_swd
    • CommentTime30 Sep 2021

     
    Możecie wrócić na ziemię. Chciałbym poczytać o RC :D
38. • 38:
       
      CommentAuthorjhusak
    • CommentTime1 Oct 2021

     
    Ale gdybyśmy wrócili, to kto by tworzył polskie słowniki informatyzacji?
39. • 39:
       
      CommentAuthorpirx
    • CommentTime1 Oct 2021

     
    ziemianie
40. • 40: CommentAuthor0xF
    • CommentTime11 Oct 2021

     
    Czekam na youtuba. :) Slajdy wyglądają profesjonalnie.
41. • 41:
       
      CommentAuthoramarok
    • CommentTime16 Oct 2021 zmieniony

     
    Miałem ostanio długą przerwę w konwertowaniu obrazków (poza naszym spotkaniem na zoomie). Tak więc czas najwyższy coś nowego wrzucić. Milutki szczeniaczek rasy rottweiler.
    
    Taka ciekawostka, to pierwszy dla mnie przypadek kiedy usuwałem artefakty linione grzebiąc bezpośrednio w plikach output.png.mic oraz output.png.rp. Ale miałem przednią zabawę :)

    • output.png
      
      
      
      
    • amarok_puppy.xex
42. • 42:
       
      CommentAuthorYosh
    • CommentTime17 Oct 2021

     
    Genialne, nie wiem czy taka była idea ale wyszedł nie do końca pretendujący do fotorealizmu. Tak jakby ograniczenia naszego komputerka były tutaj użyte celowo - a nie na siłę zaklinane że ich nie ma.
43. • 43:
       
      CommentAuthoramarok
    • CommentTime17 Oct 2021

     
    @Yosh, masz całkowitą rację. W tym przypadku nie było sensu walczyć o fotorealizm.
    
    To wynika głównie z faktu, że Atari nie jest w stanie wyświetlać kolorów z niskim nasyceniem. W związku z tym ciemniejszą sierść całkowicie pozbyłem nasycenia (w oryginale wpadała w granatowy) a jaśniejszą wręcz przeciwnie, wzmocniłem.
    
    Następnie wygenerowałem wstępny obrazek przy pomocy RastaConvertera i powstały obraz docelowy (output.png-dst.png) wykorzystałem jako bazę do dalszej ręcznej obróbki.
    
    W kolejnych krokach redukowałem liczbę kolorów w taki sposób, żeby obraz był łatwiejszy do przekonwertowania a jednocześnie nie tracił na szczegółowości i głębi.
    
    Dodatkowo, żeby nie było zbyt jednolicie, dodałem pewien drobny efekt w tle. Lubię jak obraz jest pełen szczegółów na całej powierzchni.
    
    Na sam koniec i tak powstało sporo artefaktów, które jak wcześniej napisałem usunąłem ręcznie modyfikując poszczególne kolory w mapie bitowej (plik .mic) oraz zmieniając nieco kod programu (plik .rp).
    
    Cała zabawa od początku do końca zajęła 10 dni. Ale chyba było warto...
44. • 44:
       
      CommentAuthorKaz
    • CommentTime17 Oct 2021 zmieniony

     
    Piękne! A ja przy okazji dodam, że już jutro o 20:00 na YT premiera długo oczekiwanego materiału z Amarokiem, "zaginiona instrukcja do RastaConvertera" - jak napisał Misza, czyli nagranie naszego spotkania zoomowego, na którym Amarok opowiada i pokazuje, jak radzi sobie z konwersją zdjęć w programie Ilmenita. Warto subskrybować nasz kanał, ustawić sobie powiadomienia, a film obejrzeć!
    
    
45. • 45: CommentAuthor0xF
    • CommentTime18 Oct 2021

     
    Zaraz po prezentacji nowych MacBooków przez Apple!
46. • 46:
       
      CommentAuthorgienekp
    • CommentTime24 Oct 2021

     
    Wersja Ivopa z GitHuba kompiluje się na debianach. W załączniku wersja skompilowana dla ubuntu. W tygodniu zrobię wersję na rPi-4 to zobaczymy jak malinka to mieli...
    
    Przy okazji sprawdziłem prędkości. Miałem do dyspozycji dwa kompy gdzie był win10 i ubuntu. Jeden jakiś serwerowy na Xeonach (gdzie rdzenie są wolne mimo że ich jest jakaś setka) z wirtualizacją VMware i jeden i7 (klasyczny win10 i ubuntu18). I na obu wychodzi mi, że ten sam przykład na jednym rdzeniu na ubuntu idzie szybciej niż na Windowsach. Zupełnie nie wiem dlaczego. Z moich doświadczeń max różnica kompilowanych kodów to 15% na korzyść Linuxa. Jednak wyszło, że na Xeonie w Windowsie w minutę zrobił 220tys ewaluacji na ubuntu 300tys (oba wirtualizowane VMware). Podobnie na i7 z tym, że było 2 razy szybciej (wiadomo tu już bez wirtualizacji na żywca szło).
    Zrobiłem też test na Ryzenie 3900. Ten sam przykład w minutę miał 1 milion ewaluacji. Niestety na nim nie mam linuxa, żeby porównać
    
    No więc, skoro wersję Ivopa łykają nowe kompilatory i kompiluje się FreeImage. To wpadłem na pomysł, że zrobię wydmuszkę biblioteki allegro. Taka "allegro.h" co tylko markuje niezbędne rzeczy. No i takie coś kompiluje się ładnie pod konsolę. W zasadzie to można by skompilować pod router TPLinka albo cokolwiek.
    
    Co ciekawe puszczone na AppleM1 robi ta wersja konsolowa ponad 1.5mln ewaluacji w minutę. To o 50% szybciej niż rdzeń Ryzena. Niestety nie mam nic szybszego do testów na x86. Więc stan na dzisiaj to M1 jest szybszy o 50% od inteli.
    
    Jak zakończę wersję konsolową to zrobię na wszystkie systemy i wtedy puszczę ten sam przykład dokładnie z tym samym kodem skompilowanym. I wtedy wyjdzie ile wnosi system operacyjny a ile procek.
    
    @ilmenit
    Czy pamiętasz może użycie funkcji z allegro:
    void stretch_blit(BITMAP *, BITMAP *, int , int, int, int, int , int , int , int);
    ?
    
    Mniej więcej wiem co to robi, ale RastaConverter wywołuje funkcje bardzo dziwnie w początkowej części. 240 razy po kawałeczku:
    stretch_blit 0 0 0 0 0 1 640 0 0 1
    stretch_blit 0 0 0 1 0 1 640 1 0 1
    stretch_blit 0 0 0 2 0 1 640 2 0 1
    I tak do:
    stretch_blit 0 0 0 239 0 1 640 239 0 1
    
    Kompletnie tego nie czaję, bo wysłane bitmapy są nie zainicjalizowane i mają 0*0 rozdzielczość.
    Natomiast potem te bitmapy lecą do freeimage i idzie z nich zapis podglądu do PNG.
    Klasyczne użycie 160x240 na 320x240 i png już śmiga...

    • RastaConverter_Ubuntu18.7z
47. • 47: CommentAuthorilmenit
    • CommentTime24 Oct 2021

     
    @gienekp - możesz dać linka do GitHuba w której linii kodu jest to stretch_blit wołane?
48. • 48:
       
      CommentAuthorgienekp
    • CommentTime24 Oct 2021

     
    Wywołań jest kilka, CHYBA kluczowe dla wersji konsolowej jest jedno (skalowanie z 160x240 na 320x240). Reszty nie kumam, co ciekawe bez tego działa.
    Generalnie jak funkcję "wydmuszkę" zrobię pustą to wygeneruje mi wynik assemblerowy, ale nie ma podglądów w PNG. Jak dodam obsługę tego jednego skalowania to wszystko gra. Więc cała reszta to chyba malowanie po ekranie?
    
    Wywołania:
    rasta.cpp:230 - RastaConverter::SavePicture(string filename, BITMAP *to_save)
    rasta.cpp:564 - RastaConverter::ShowInputBitmap()
    rasta.cpp:586 - RastaConverter::ShowDestinationLine(int y) - TU JEST JAKAŚ DZIWNA SIECZKA
    rasta.cpp:599 - RastaConverter::ShowDestinationBitmap()
    rasta.cpp:1632 - RastaConverter::ShowLastCreatedPicture()
    
    W załączniku biblioteka allegro, z którą działa wersja konsolowa. NIE MA JESZCZE metody przerwania (na klawisz). Nie mam pomysłu jak to zrobić. Na razie jest tak, że po milionie ewolucji kończy. Może jest jakiś parametr do automatycznego zakończenia?
    
    Puszczam na totalnym defaulcie. Teraz jeszcze puściłem na innym kompie. W minutę Windows:440k, Lubuntu: 650k. No każdy test i na Linuxie 30% szybciej... Do zbadania sprawa...

    • fakeALLEGRO4RastaConverter.7z
49. • 49: CommentAuthorilmenit
    • CommentTime25 Oct 2021 zmieniony

     
    rasta.cpp:586 - RastaConverter::ShowDestinationLine(int y) - TU JEST JAKAŚ DZIWNA SIECZKA
    

    
    wynika chyba z tego, że nie inicjujesz BITMAP. Ta funkcja jest wywołana do wyświetlenia na ekranie konkretnej linii obrazka przy preprocessingu. Funkcja stretch_blit tam:
    [code]
    void RastaConverter::ShowDestinationLine(int y)
    stretch_blit(destination_bitmap,screen,0,y,destination_bitmap->w,1,input_bitmap->w*4,y,destination_bitmap->w*2,1);
    [/code
    A jeszcze odpowiadając na niezadane pytanie dlaczego wyświetlać po linii ekran a nie cały? Dlatego, że preprocess może trwać długo (np. przy zastosowaniu knoll dithering + CIEDE2000 color distance) i wyglądałoby, że się program zawiesił, a tak widać jak przebiega preprocess.
50. • 50:
       
      CommentAuthorgienekp
    • CommentTime25 Oct 2021

     
    Dobra, wiem już o co chodzi. Po prostu w wersji konsolowej ja nie widzę co się dzieje na ekranie. Sprowadzam kod do minimum.
    Myślałem, że "allegro" jest tylko do wyświetlania i podglądu, ale w kilku miejscach wynik przechodzący przez tę bibliotekę jest brany do analizy. Więc tak w 100% nie da się jej wywalić. Natomiast uzupełnienie to prosty kod.
    
    Tak przy okazji przekompilowałem wersję dla raspberryPi. Testowałem na rPi4. W minutę robi jakieś 80k ewaluacji. To jest wersja pełna z malowaniem podglądu.

    • RastaConverter_rPi.7z