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:
      
     CommentAuthorKaz
   • CommentTime26 Dec 2021 zmieniony

    
   Gienekp - pozwoliłem sobie przekleić tutaj treść Twojego postu z wątku o programie "RastaConverter", bo tam nie będziemy mieszać tematów, a to co robisz to rzecz godna dyskusji!
   
   Zapytałem tam, czym zrobiłeś swój obrazek w GR.9 i Twoja odpowiedź:
   
   

   gienekp:

   @Kaz
   to z "automatu", który robię do konwersji JPG na Gr.9...
   
   Zafascynowany RastaConverterem i naładowany wskazówkami od ilmenita wzięło mnie na zrobienie konwertera. Początkowo planowałem konwersje do Gr.10. Okazało się, że sama konwersja to jedno, ale ogarnąć dobrze ATARowską paletę to nie lada wyczyn. Dlatego cofnąłem się do łatwiejszego Gr.9. Teoretycznie prosta sprawa. Każdy obrazek RGB można zamienić na skalę szarości, więc podkład do Gr.9 jest. Potem przeanalizować kolory i prockiem przełączać tylko jeden rejestr koloru...
   
   Tylko, że dobranie koloru to syzyfowa praca. Testowałem różne palety, różne metody i za każdym razem porażka. Jak jeden obrazek dobry to drugi do bani. Okazuje się, że nie da się tego zrobić dobrze. Bo ATARowski kolor definiują TRZY parametry. Z czego jeden to "gałka" w TV. No więc uznałem, że należy cofnąć się do źródeł generowania kolorów w systemie PAL. Na podstawie dokumentacji i oscyloskopu próbuje matematycznie opisać te kolory.
   
   Po uruchumieniu programu, mamy tylko jeden suwak. Suwak virtualnego nasycenia dla TV, na podstawie którego program w czasie rzeczywistym buduje paletę. Do tych kolorów potem są dobierane punkty. Na koniec program buduje kod zmieniający w kolejnych liniach chrominancję. Żeby nie było zbyt kańciasto to jedna linia zmienia się 7 razy a następna 6 razy i tak w kółko. Gr.9 jest mocno "gradientowy", wartość koloru też można by płynnie dobierać, więc sporo obrazków wyszłoby fajnie. I to w pełnej palecie 240 kolorów.
   
   Metodę budowania programu dla procka na razie zostawiłem, tutaj jest trywialna. Natomiast cały czas główkuję, jakim algorytmem zdecydować, czy dany piksel ma mieć kolor (czy tylko szarość) i który kolor, bo samo określenie jasności jest proste. Taki algorytm byłby uniwersalny i pożądany jako pierwszy etap do dowolnie innego konwertera.
   
   Zobaczcie, że im paleta ma mniejsze nasycenie, tym zwykły algorytm chętnie sięga po kolory i tym bardziej wersja finalna robi się bardziej ATARowsko kolorowa.
   
   Program w wersja mocno wstępnej, ale już jest się czym bawić.
   
   P.S Jak dodać EXE co ma więcej niż 8MB?

   • LCgr9.png
     
     
     
     
2. • 2:
      
     CommentAuthorgienekp
   • CommentTime26 Dec 2021

    
   @Kaz
   
   mam skompilowany program dla Windows, MacOS, Ubuntu, Android. Jak dodać pliki, są w Qt i ich wielkość w okolicach 10MB?
3. • 3:
      
     CommentAuthorKaz
   • CommentTime26 Dec 2021

    
   Nie da się wrzucić plików większych niż 8MB, bo tak sobie ustawiliśmy limit. Ale podeślij mi plik to wrzucę na nasz serwer do archiwum użytków PC i dam linkę do niego. Kolejne wersje programu też tam będzie w razie czego można trzymać.
   
   Generalnie - fajny program, dobrze się zapowiada. Jeżeli chodzi o matematyczne modelowanie kolorów PAL i NTSC to powstała z tego paleta OliverPAL i OliverNTSC.
4. • 4:
      
     CommentAuthorKaz
   • CommentTime26 Dec 2021 zmieniony

    
   I jeszcze raz, dla przypomnienia, wrzucam tu efekt działania Twojego programu:

   • LCgr9_winter.png
     
     
     
     
   • LCgr9_winter.xex
5. • 5:
      
     CommentAuthorgienekp
   • CommentTime26 Dec 2021 zmieniony

    
   To może taki szybki opis.
   
   "Load Picture" - wczytanie obrazka. Niby tylko JPG, ale idzie przez bibliotekę Qt, a ta obsługuje masę formatów, więc jak ktoś przemyci PNG z rozszerzeniem JPG to też będzie działać
   
   Podglądy:
   a) Original - obraz w rozdzielczości 320 x 240 RGB; program skaluje dowolny obrazek bez zachowania proporcji; zakładam, że kadrowanie to sobie każdy wcześniej ogarnie
   b) GTIA - obraz w rozdzielczości 80 x 240 RGB; tryby GTIA jakie są każdy wie, jeżeli na tym etapie poginęły szczegóły no to cudów nie będzie
   c) ATARI PAL - obrazek z przyporządkowaną paletą systemu PAL; ten krok będzie ulepszany w przyszłości (!); na ten krok ma wpływ "Saturation Level"
   d) obrazek wyjściowy w palecie z Altirry; ale wiadomo, co ATARI to ATARI
   e) Gray - obrazek wyjściowy w skali szarości trybu 9. Czyli jak będzie na TV czarno-białym lub inaczej sama składowa Y
   f) Green - zielono jak na Neptun 156 :)
   g) Chroma - składowa koloru, czyli gdzie i jak CPU podmienia barwę; na razie nie ma żadnej "inteligencji", po prostu 7 zmian, potem 6, znowu 7 i 6 i tak co linię
   
   "Save ASM" - Zapisuje plik tekstowy kodu ASM dla MADS; bazowałem na ASM RastaConvertera bo zupełnie nie kumam jakim cudem skleja się te 240 linii (po 204 chyba normalnie coś dziwnego się działo)
   "Save XEX" - gotowy XEX; przy czym ja to wcześniej skompilowałem, a że zmiany idą od siekiery więc tylko podmieniam w XEX dane w odpowiednich miejscach
   
   "Saturation Level"
   Według dokumentacji system PAL ma zaszyte przesunięcia w fazie nośnej koloru:
   135, 112.5, 90.0, 67.5, 45.0, 22.5, 337.5, 315.0, 292.5, 270.0, 225.0, 202.5, 180.0, 157.5, 135.0
   Według oscyloskopu prawie tak jest :)
   
   Na bazie tego program generuje sobie paletę, tylko jest dylemat jakie przyjąć nasycenie? No trzeba ustawić suwakiem. :) Już wiem, że wszelkie "odległości" koloru działają tak sobie. Należy wyliczyć kąt dla koloru szacowanego i znaleźć najbliższą barwę. W przyszłości o tym czy zrobić "szary" czy "kolor" chyba powinien być zwykły próg. Tego jeszcze nie wiem, na razie jest "Pitagoras". I wydaje mi się, że w przyszłości trzeba będzie dorobić edytor krzywej nasycenia. Np. żeby w różnym miejscu obrazka inaczej to ustawiać, bo dla wielu obrazków ruszając suwakiem raz jedna cześć jest ładna a raz inna (przykład poniżej jak wpakował się "szary").
   
   Program w wersji wstępnej, możliwe że się podzieli na dwa, jeden co obrabia tylko paletę a drugi co generuje. Wtedy można by drugą cześć podmienić na RastaConvertera. Po prostu z moich eksperymentów wyszło, że ten pierwszy etap z paletą jest dość ważny i chyba trzeba mu zrobić ekstra narzędzie.

   • desert.png
     
     
     
     
   • desert.asm
   • desert.xex
6. • 6: CommentAuthormono
   • CommentTime26 Dec 2021

    
   Super wynik. Jak długo się taki obrazek liczy? To jest ten sam algorytm co w RastaConverterze?
7. • 7:
      
     CommentAuthorgienekp
   • CommentTime26 Dec 2021

    
   Wynik jest natychmiast, bo algorytm jest deterministyczny i leci od lewej do prawej od góry do dołu.
   
   Generalnie Gr9 lubi nature i wszelkie krzaki ciekawie wychodzą.
   
   Chciałbym w przyszłości połączyć algo RC, bo widziałem, że są mistrzowie co tryby w lini przełączają. No więc jakby dalszy plan robić w Gr9 a bliższy plan w RC to było by coś...

   • wodospady.png
     
     
     
     
8. • 8:
      
     CommentAuthorpebe
   • CommentTime26 Dec 2021

    
   Łał... przyznam, ze obrazki wyglądają "nienaturalnie pięknie"
   Podoba i to bardzo.
9. • 9: CommentAuthortebe
   • CommentTime26 Dec 2021

    
   do GR10 konwertuje RastaJuice
10. • 10:
       
      CommentAuthorpirx
    • CommentTime27 Dec 2021

     
    @gienekp jeszcze jest taki tryb 9+10 przełączany co wiersz ekranu - ma on taką zaletę, że wizualnie zmniejszają się schodki, bo 10 jest przesunięty o cykl koloru w stos. do 9.
    efekt w moim starym demku NO SIGNAL. Toola to tego trybu zrobił też Irgwender z atariage, ale jakoś nie mogę znaleźć.
    Jakbyś potrzebował inspiracji, to tutaj
    ->link<-
    od mnie więcej wiersza 165 jedzie DL w tym trybie a potem DLI.
    Dla zwiększenia komplikacji tutaj jest w trybie znakowym, więc występują badline'y, w normalnej grafie byłoby łatwiej.
11. • 11:
       
      CommentAuthorgienekp
    • CommentTime27 Dec 2021 zmieniony

     
    @pirx, dzięki za wskazówkę. Nie widziałem, że 9 i 10 ma przesunięcia, wydawało mi się, że przełączenie trybów GTIA bitami przełącza tylko logikę. Ale skoro jest opóźnienie tzn, że musi się tam więcej dziać.
    A czy w połowie lini można przełączyć z 9 na 10? Co się wtedy stanie?
12. • 12:
       
      CommentAuthorKaz
    • CommentTime27 Dec 2021

     
    Dostałem już od Gienka pliki, dzisiaj je wrzucę do archiwum i zapodam linki.
13. • 13: CommentAuthortebe
    • CommentTime27 Dec 2021 zmieniony

     
    na temat mieszania trybów ->link<-
14. • 14:
       
      CommentAuthorKaz
    • CommentTime27 Dec 2021

     
    Już wrzuciłem.
    
    Wersja dla Androida:
    ->link<-
    
    Wersja dla peceta (Windows, Ubuntu):
    ->link<-
    
    Wersja dla MacOS:
    ->link<-
15. • 15: CommentAuthormkolodziejski
    • CommentTime30 Dec 2021

     
    a link do GitHuba?
16. • 16:
       
      CommentAuthorsun
    • CommentTime30 Dec 2021

     
    z GH to majkrosoft zaraz ukradnie :)
17. • 17: CommentAuthortebe
    • CommentTime30 Dec 2021

     
    LesnyRumcajs potwierdza ;)
18. • 18:
       
      CommentAuthorgienekp
    • CommentTime30 Dec 2021 zmieniony

     
    Jak uporządkuje kod to tutaj wrzucę źródła...
    
    Czy może ktoś wie, dlaczego gdy jest 240 linii, to dane muszą być jakoś dziwnie przygotowane. Skopiowałem to z RastaConvertera:
    
    org $2000
    :16 .byte 0
    PICTURE
    
    potem po 204 liniach jest jakieś tajemnicze ":16 .byte 0"? Działa to, ale nie wiem dlaczego.
    
    Chciałbym zrobić konwersję kilku klatek (taka mała animacja) no ale wygląda na to, że nie da się tak upchać obrazków jeden za drugim bo coś dziwnego się dzieje :/
19. • 19: CommentAuthormono
    • CommentTime30 Dec 2021

     
    Pamięć ekranu zawija się na blokach 4KB.
20. • 20:
       
      CommentAuthorpirx
    • CommentTime31 Dec 2021

     
    co niestety powoduje, że nie da się ustawić ciągłej pamięci ekranu dla więcej, niż ~204 wierszy w normalnej szerokości, bo o ile pierwszą granicę 4K da się przejść, to drugiej już nie (4096 mod 40 != 0)
21. • 21: CommentAuthormkolodziejski
    • CommentTime31 Dec 2021

     
    @Sun i @Tebe ja chętnie posłucham argumentów merytorycznych na temat "MS ukradnie" licencja to licencja, obowiązuje każdego. ps. też ich nie znoszę, ale GH zbudował renomę ZANIM MS go kupił i skupia idee OSS.
    
    @Tebe, twój genialny MadPascal dzięki życiu w GH ma aktywność i zmierza w dobrym kierunku - fakt, nie każdy w Polsce jeszcze proponuje zmiany w kodzie, zamiast tylko "opisać problem".
    
    
    @gienekp nie zrażaj się, kod to kod - warto zadbać o jego przyszłość, forum nie ma mechanizmów powiadomień, które są praktyczne w przypadku współpracy nad kodem -
22. • 22: CommentAuthoremkay
    • CommentTime31 Dec 2021

     
    This is a very nice approach.
    Actually THE real 256 color mode for the Atari.
23. • 23:
       
      CommentAuthorgienekp
    • CommentTime1 Jan 2022 zmieniony

     
    @mkolodziejski
    bardziej wstyd, że nie umiem GH :) Ale wszystko jest dla ludzi...
    
    @mono & @pirx
    rozumiem, więc już pierwsze 240 "idzie na oparach". Najwyżej animacje zrobi się "na 180" takie niby 16:9 :) Bo taki pomysł mi nie daje spokoju: wygenerować kilka (kilkanaście dla cartridgea) klatek, takiego "niby wygaszacza". W sensie, że wodospad "chlupie", fale się przesuwają, liście na drzewach się ruszają. Na to nie potrzeba wiele klatek. Tak jak pisałem Gr9 lubi naturę a natura lubi random, więc już przy 3 klatkach: 1 2 3 2 3 1 3 2 i było by życie :)
    
    Jest jeszcze takie coś, wyszło mi, że jak podstawiamy obrazek gdzie jest ciemna noc (jakieś miasta, zachody słońca itp) To brakuje czarnego. I teraz tak, szeroki gracz-pocisk ma piksela dokładnie jak Gr.9 (czy się mylę?). Jakoś tak pasuje, że można by cały ekran tym pokryć i dodawać ten wyjątkowy kolor (w sumie to nie musi być czarny). Ponieważ wartość barwy dobieram według histogramu (robię taki lokalny) to można by teoretycznie tym graczem-pociskiem dostukać dodatkowe piksele odstające barwą.
    
    Pytanie tylko czy gracz-pocisk w trybach GTIA normalnie się zachowuje? Czy tam też jakieś cuda się dzieją, kolory mieszają albo coś podobnego? Np. czy gracz wielokolorowy interferuje z tłem?
    
    Teraz zauważyłem, że jeszcze jednej rzeczy nie robię. Używam tylko LDA/STA a przecież mogę na początku lini, gdzie jest kryzys cykli, dać LDA,LDX,LDY(akcja)STA,STX,STY i dalej już LDA/STA
24. • 24: CommentAuthorAdam
    • CommentTime1 Jan 2022 zmieniony

     

    gienekp:

    szeroki gracz-pocisk ma piksela dokładnie jak Gr.9 (czy się mylę?)

    
    Obiekt player/missile w podwójnej szerokości ma piksel takiej szerokości jak w GR.9, w poczwórnej jest 2 x szerszy.
    Natomiast jego pozycjonowanie w poziomie jest niezależne od ustawień szerokości, precyzyjniejsze niż piksele GR.9, więc można ustawić go tak, że zaczyna się w połowie piksela pola trybu GTIA.
    
    

    gienekp:

    Pytanie tylko czy gracz-pocisk w trybach GTIA normalnie się zachowuje? Czy tam też jakieś cuda się dzieją, kolory mieszają albo coś podobnego? Np. czy gracz wielokolorowy interferuje z tłem?

    
    Ograniczając się do trybu GR.9, bo jest specyficzny: piksele playerów nie interferują w nim w żaden sposób z pikselami pola (wielokolorowe czy nie), zasłaniają wszystko, za to niestandardowy jest efekt użycia missile'i:
    
    - przy ustawionej fladze piątego playera: po nałożeniu na piksele pola kolor jest brany bezpośrednio z koloru pocisku, a jasność jest OR-em bitów jasności piksela pola i pocisku.
    - przy nieustawionej fladze piątego playera: zachowują się jak playery, nie ma interferencji z polem.
    
    To oznacza, że - jeśli chcesz dodać za pomocą gracza/pocisku kolor czarny na obrazku w GR.9, musisz użyć albo gracza w kolorze 0 i nie przejmować się pikselami pola, a przy nakładaniu pocisku w zależności od ustawień może być tak, że musisz zadbać, aby piksele pola miały koniecznie jasność 0.
    
    [EDIT: dopisałem informacje o fladze 5. playera]
25. • 25:
       
      CommentAuthorpirx
    • CommentTime1 Jan 2022

     
    @gienekp przykrywka na player / missile - oczywiście, że jest jakoś pokręcone, ale da się zrobić. Są 2 sposoby:
    1. przeczytać i zrozumieć "Altirra Hardware Reference Manual" by Avery "phaeron" Lee.
    2. próbować wstawiać różne wartości do PRIOR i innych rejestrów GTIA aż się uzyska zadowalający wynik.
    
    Metoda 2. została przeze mnie zastosowana w ww. demku "NO SIGNAL", gdzie na P/M są zrobione przysłonki do grzebienia pixli na krawędziach trybu 9+10 oraz rameczki wokół mordek bohaterów demka.
26. • 26:
       
      CommentAuthorgienekp
    • CommentTime2 Jan 2022 zmieniony

     
    "Altirra Hardware Reference Manual" magluje w te i nazad. Tego za jednym podejściem nie idzie ogarnąć :)
    
    Poprosiłem Kaza o udostępnienie wersji 0.4. Zmieniłem kompletnie algorytm doboru koloru. Chodzi o to, że tak naprawdę ATARI ma tylko JEDEN bit nasycenia. 0 - brak; 1 - jest. To powoduje, że wszelkie algorytmy RGB dają wyniki takie sobie.
    
    W tej wersji 0.4 kolor RGB obrazka z JPG zamieniam na YUV. Y leci wprost do jasności Gr.9, a ze składowych UV liczę kąt przesunięcia (dokładnie ATAN2(V/U)). Następnie mając tablice z "manuala" przesunięć kątowych w systemie PAL dobieram najbliższą barwę. Do tego miejsca, jasność jest bardzo dokładna, barwa całkiem dobra.
    
    Pozostaje tylko zrobić coś z długością wektora UV (nasycenie). Ponieważ nie szło zrobić na to automatu, bo się nie da. Uznałem więc, że trzeba dodać ekstra wajchę i ustawiać ręcznie, gdzie jest próg, który decyduje czy dać barwę czy jednak szarość.
    
    Można sobie teraz robić obrazek szarawy, lub kolorowy jak obszar Toussaint z Wiedźmina 3 :)
    
    P.S. Przykład Lotusa z blokowaniem szarości, czyli kolor za wszelką cenę

    • LCgr92.png
      
      
      
      
    • lotus.png
      
      
      
      
    • lotus.asm
    • lotus.xex
27. • 27:
       
      CommentAuthorKaz
    • CommentTime2 Jan 2022

     
    Poprosiłem Kaza o udostępnienie wersji 0.4.

    
    
    Od paru godzin już jest. W tych samych katalogach.
28. • 28:
       
      CommentAuthorgienekp
    • CommentTime3 Jan 2022 zmieniony

     
    Obiecane źródła:
    
    ->link<-
    
    Kompilację dla Linux i MacOS proponuję robić w Qt Creatorze.
    
    Natomiast wersję dla Windows to proponuję kompilować pod Linuxem kompilatorem MXE ->link<-
    Wychodzi nam wtedy jeden plik EXE dla windowsa, zawierający w sobie wszystkie biblioteki i działający od Win98.
    
    Wersję dla Androida kompilowałem apką: C4droid
29. • 29:
       
      CommentAuthorgienekp
    • CommentTime8 Jan 2022 zmieniony

     
    Taki poboczny wątek mi wyskoczył. Teoretycznie Gr.8 to taki tryb GTIA bez GTIA :) ale jakby w pakiecie z Gr9/10/11.
    Zamiast podmieniać barwę na Gr.9 to to samo robię na Gr.8. Efekt ciekawy...
    Jednak jest mała mina. Zdaje się, że wynik będzie zależny od sprzętu (dokładnie TV). Gr8 zaczyna interferować z nośną sygnału chrominancji sygnału PAL.
    Czy ktoś ma jakieś doświadczenie z Gr.8? Kiedy na realnym sprzęcie idzie to w maliny a kiedy nie? Bo w dokumentacji Altirry to cały "doktorat" jest o tych artefaktach.

    • Fiat126p.png
      
      
      
      
    • Fiat126p.xex
30. • 30:
       
      CommentAuthorpirx
    • CommentTime8 Jan 2022

     
    bardzo fajne, ciekawe, jakby to wyglądało, jakbyś podmieniał jasność zamiast koloru - gr.8 z przejściami tonalnymi to mogłoby być coś b. fajnego.
    
    Artefakty - u phaerona jest na ten temat elaborat, bo to bardzo mocno wchodzi w NTSC - np. na CTR w NTSC w ogóle nie da się rozczytać napisów w 80 kolumnach, właśnie z powodu artefaktów. W PAL efekt jest ZNACZNIE mniej widoczny i w zasadzie na nowszych sprzętach do pominięcia. Za to jest PAL bleed (rozdzielczość kolorów w PAL jest 1/2 rozdzielczości pionowej, więc wystarczy machać kolorami co drugi wiersz, albo gdy machasz w każdym, to masz więcej kolorów, niż fabryka dała).
    Odpalę tego fiacika na ntsc i Ci pokażę :)
31. • 31:
       
      CommentAuthorpirx
    • CommentTime8 Jan 2022 zmieniony

     
    fiacik mryga:
    ->link<-
    
    
    A tutaj syscheck na nteescu
    
    
    ten zielony pionowy bar to właśnie artefuckt
32. • 32:
       
      CommentAuthorpirx
    • CommentTime8 Jan 2022

     
    oj SC dałoby się używać, jakby kolorki ustawić tak, jak w syscheck, std. jest źle
    
33. • 33:
       
      CommentAuthorgienekp
    • CommentTime8 Jan 2022

     
    @pirx
    Dzięki, za test!
    
    Z tymi kolorami co linię w PAL to już wiem o co chodzi... Bo to pamiętam ze specyfikacji PAL.
    
    Co do kodu to w zasadzie mam 7 zmian na linię, więc można by podmieniać też i jasność. Kłopot w tym, że jeszcze nie bardzo wiem jak przygotować obrazek pod to. Bo w tej wersji, to w GIMPie zrobiłem zwykłą redukcję do 1-bit. I miałem podkład Gr8. A potem dodałem zmianę barwy tym samym kodem co podmieniam w Gr9. Taki mix...
    
    Wyczytałem, że w Gr.0 i Gr.8 kolor piksela brany jest z tła. Ale jak jest Gracz-Pocisk to bierze z tego gracza. Chyba muszę się teraz wziąć za PM. Bo coś czuję, że jest miejsce na kolejną automatyzację.
    
    Czy Gr.0 i Gr.8 z punktu GTIA można traktować tak samo?
    
    Tak jak już wspominałem, chcę zrobić animację. Chociaż 3 klatki :)
    I teraz pytanie, czy jak w Gr.0 zrobię jedną klatkę, ale co 3 linie będę podmieniał fonty to czy lepiej się ułożę w pamięci? Czy tam też jakieś "wyrównania" adresów spowodują sieczkę w RAM?
    
    No bo jakby tak się to ładnie układało jeden za drugim. To w zasadzie bym tylko pogenerował tablicę fontów jeden za drugim.
    
    W sumie to mogę 3 wersje przetestować. Dla gołego ATARI. Dla carta XEGS 512kb i taki wypas dla RAMCarta (mam taki od Galtrona). Wtedy te animacje byłyby długie kolorowe... i pewnie do niczego nieprzydatne :)
34. • 34: CommentAuthortebe
    • CommentTime8 Jan 2022

     
    3 linie, czy 3 wiersze, w trybie bitmapy masz linie, w trybach znakowych wiersze
    
    w trybie znakowym masz "bad lines" co 8 linię (wiersz) ANTIC zabiera czas aby odczytać znaki z wiersza i wstawić je do swojego bufora
    
    program rastra co 8 linię musiałby odpuszczać sobie zmiany kolorów w linii
35. • 35:
       
      CommentAuthorgienekp
    • CommentTime8 Jan 2022

     
    @tebe
    WIERSZE, masz rację, źle sprecyzowałem.
    
    W trybach graficznych też musi ANTIC zrobić kopię, mało tego linia ma znacznie więcej danych. Więc kiedy to robi?
36. • 36: CommentAuthortebe
    • CommentTime8 Jan 2022

     
    w trybach graficznych tylko LMS zabiera 2 cykle więcej, dlatego G2F w trybach z programem rastra pamięć obrazu organizuje w sposób uporządkowany co 8 linii, np: :24 DTA $4E,A(ADRES+#*40),$0E,$0E,$0E,$0E,$0E,$0E,$0E
    
    linia 0: 57 cykli, linie 1-7: 59 cykli
37. • 37:
       
      CommentAuthorgienekp
    • CommentTime8 Jan 2022

     
    Rozumiem.
    
    Chyba źle robię, że co linię daje LMS. Z drugiej strony 2 cykle raczej nie wykorzystam, a przynajmniej mam równe wszystkie linie.
    
    Dzięki za info, wydaje mi się, że warunki brzegowe mam określone, więcej kolorów już nie wycisnę. Zostaje tylko poprawić dopasowanie do obrazka.
38. • 38: CommentAuthortebe
    • CommentTime8 Jan 2022

     
    można i co linię LMS
39. • 39:
       
      CommentAuthorgienekp
    • CommentTime30 Jan 2022 zmieniony

     
    Tak pobocznie, jaki efekt jest gdy zmieniamy jasność rejestru koloru w GR8.
    Wygląda na to, że ten tryb tak średnio nadaje się do kolorowania. Najpierw musimy zrobić trik, malowania w inwersji. Standardowo można ustawić barwę i jasność tła oraz tylko jasność malowanych pikseli. No więc za jednym zamachem nie da się podmienić ich koloru i jasności. Ale jak zacznie się malować w inwersji, to wtedy tło jest pikselem malowanym, a piksel "świecący" tłem. Wtedy CPU wpisując w rejestr tła wpisuje od razu nową barwę i jasność. Ponieważ dla tego trybu i tak muszą iść jakieś ditheringi to zmiana jasności daje słaby efekt (bo jasności jest tylko 8 poziomów). Podmiana barwy to tak jak na poprzednim 126p. Zależy od obrazka.
    
    No ale żeby nie było jałowo, to poniżej program w C, który to załatwi. Potrzebuje tylko mieć dwa obrazki RAW, jeden w palecie kolorów a drugi w skali szarości ale takiej w zasadzie monochromatycznej. Z PNG na RAW zamieniamy za pomocą ImageMagic. Na paletę kolorów rgb2atari. ASMa kompilujemy MADsem.
    
    Może gdzieś, kiedyś komuś na coś się to przyda.

    • result.png
      
      
      
      
    • cLineConverterGr8.7z
40. • 40:
       
      CommentAuthorjhusak
    • CommentTime30 Jan 2022 zmieniony

     
    @pirx dokładnie to w PAL kolor jest opóźniony o linię, ale rozdzielczość w pionie ma tę samą co luma. Stąd możliwy jest efekt nakładania się koloru z poprzedniej linii na jazność w aktualnej i mamy możliwość nadania każdemu pikslowi dowolnego koloru, jednak co drugą linię mamy czarną.