25.07.2015 23:09
[#1]
Wyciskanie OCS
Z racji wzrostu popularności demosceny na OCS i w związku z ostatnim demem scoopexa zainteresował mnie temat zwiększenia możliwości graficznych OCS. Wiadomo, jest HAM, jest multipalette, ale można więcej. Można pozornie zwiększyć liczbę bitów do 15-u wykorzystując interlace. Pomysł stary i często używany na 8-bitowcach i Atari ST/E, zwłaszcza ostatnio. Ktoś tam napisał prosty program w Amosie pokazujący 32 odcienie szarości na OCS z pewnym miganiem. Na WinUAE przy ustawieniu dużego odświeżania przestaje migać. Wiadomo, że na zwykłym CRT będzie migać. Chciałbym, żebyście się podzielili opiniami jak to widać na prawdziwym sprzęcie, zwłaszcza w przypadkach użycia flickerfixerów, lcd i podobnych manipulatorów obrazu. Program do ściągnięcia tu
06.09.2018 20:03
[#8]
Re: Wyciskanie OCS
@cholok, post #1
Step 1.
Jest taki tool przeznaczony dla Atari ST. Tworzy on 16 kolorowe obrazki w liczbie 2 wyświetlane naprzemiennie. Powoduje to namnożenie dodatkowych kolorów. Można je dość łatwo wyświetlić na Amidze i to faktycznie działa. Oczywiście jest to tylko krok pośredni do dalszych eksperymentów, bo uśrednienie dwóch palet 16-kolorowych stworzy ich kilkadziesiąt, ale ta paleta będzie dość daleka od rzeczywistej. U mnie na LCD odświeżanie musi być na poziomie min. 70 Hz, aby efekt był stabilny, choć lekkie drżenie jest widoczne.
Z tego co przetestowałem, WinUAE nie wyświetla poprawnie interlejsu, bo w rzeczywistości pola są przesunięte o pół linii, a w emulatorze nie. Dla powyższego efektu nie ma to znaczenia, bo interlejs jest nieużywany.
Jest taki tool przeznaczony dla Atari ST. Tworzy on 16 kolorowe obrazki w liczbie 2 wyświetlane naprzemiennie. Powoduje to namnożenie dodatkowych kolorów. Można je dość łatwo wyświetlić na Amidze i to faktycznie działa. Oczywiście jest to tylko krok pośredni do dalszych eksperymentów, bo uśrednienie dwóch palet 16-kolorowych stworzy ich kilkadziesiąt, ale ta paleta będzie dość daleka od rzeczywistej. U mnie na LCD odświeżanie musi być na poziomie min. 70 Hz, aby efekt był stabilny, choć lekkie drżenie jest widoczne.
Z tego co przetestowałem, WinUAE nie wyświetla poprawnie interlejsu, bo w rzeczywistości pola są przesunięte o pół linii, a w emulatorze nie. Dla powyższego efektu nie ma to znaczenia, bo interlejs jest nieużywany.
16.09.2018 13:28
[#9]
Re: Wyciskanie OCS
@cholok, post #8
Step 2.
Napisałem już wyświetlacz dla multipalette oraz konwerter dla danych typu raw. Co istotne, obsługuje wszystkie chunki przechowujące dane dla zmiennych palet w tym RAST używany przez atarowskie narzędzia. Jak wiadomo, tryb interlace używa 2-óch copperlist. Większość programów używa tylko pierwszej copperlisty, bo system nie za bardzo pozwala na ingerencje tej drugiej. Hamlab generuje obrazki ze zmianami co drugą linię, więc tu nie ma problemu, ale są programy, które generują zmiany dla każdej linii. Takie obrazki są wyświetlane nieprawidłowo. Czyha tutaj też nieoczywista pułapka. W chunku PCHG wszystkie zmiany rejestrów zapisywane są w stosunku do ostatniej linii. Jednak, aby taki obraz wyświetlić tworzymy 2 copperlisty osobno dla parzystych i nieparzystych linii, a więc zmiany są w stosunku dwóch ostatnich linii. Może to prowadzić przy używaniu trybów 32 col i EHB do niepożądanych kumulacji.
Napisałem już wyświetlacz dla multipalette oraz konwerter dla danych typu raw. Co istotne, obsługuje wszystkie chunki przechowujące dane dla zmiennych palet w tym RAST używany przez atarowskie narzędzia. Jak wiadomo, tryb interlace używa 2-óch copperlist. Większość programów używa tylko pierwszej copperlisty, bo system nie za bardzo pozwala na ingerencje tej drugiej. Hamlab generuje obrazki ze zmianami co drugą linię, więc tu nie ma problemu, ale są programy, które generują zmiany dla każdej linii. Takie obrazki są wyświetlane nieprawidłowo. Czyha tutaj też nieoczywista pułapka. W chunku PCHG wszystkie zmiany rejestrów zapisywane są w stosunku do ostatniej linii. Jednak, aby taki obraz wyświetlić tworzymy 2 copperlisty osobno dla parzystych i nieparzystych linii, a więc zmiany są w stosunku dwóch ostatnich linii. Może to prowadzić przy używaniu trybów 32 col i EHB do niepożądanych kumulacji.
16.09.2018 15:49
[#10]
Re: Wyciskanie OCS
@cholok, post #9
Specjalny soft do wyświetlania statycznego obrazka. Takie rozwiązanie z platform z poprzedniej względem amigi epoki.
Na amidze od zawsze był HAM, a od prawie zawsze (1992) HAM8 i karty 24 bit.
Jak już nie chcesz używać karty graficznej, to może trzeba poszukać jakiegoś lepszego softu do HAM. Np Image Studio?
Ostatnia aktualizacja: 16.09.2018 15:49:59 przez swinkamor12
Na amidze od zawsze był HAM, a od prawie zawsze (1992) HAM8 i karty 24 bit.
Jak już nie chcesz używać karty graficznej, to może trzeba poszukać jakiegoś lepszego softu do HAM. Np Image Studio?
Ostatnia aktualizacja: 16.09.2018 15:49:59 przez swinkamor12
16.09.2018 20:23
[#14]
Re: Wyciskanie OCS
@cholok, post #13
Przy dynamic hires i innych trybach paletach co linie chyba naprawde nie ma sensu bawic sie w emulowany interlace, szczegolnie jak na każdym wyswietlaczu bedzie działać inaczej. Można może by się było zastanowić czy da rade podbić liczbe kolorów sprite'ami ale nie wiem czy jest sens. Paleta co linie daje idealne obrazki, do samego wyswietlania ten tryb jest idealny.
16.09.2018 21:02
[#15]
Re: Wyciskanie OCS
@cholok, post #13
Na a500 się amiga nie skończyła. Chcesz więcej kolorów to bierzesz lepszy model amigi z lepszą grafiką.
Poza tym robienie apki żeby wyświetlić statyczny obrazek jest bez sensu.
Nawet na a500 jest HAM i tysiące kolorów. I całkiem dużo softu do konwersji na HAM. Wystarczy poszukać.
Poza tym robienie apki żeby wyświetlić statyczny obrazek jest bez sensu.
Nawet na a500 jest HAM i tysiące kolorów. I całkiem dużo softu do konwersji na HAM. Wystarczy poszukać.
17.09.2018 08:38
[#17]
Re: Wyciskanie OCS
@teh_KaiN, post #16
Tak z ciekawości chciałem zapytać, bo na C64 się bawiłem z sukcesem jeżeli chodzi o zabawę z grafiką oraz "sprajtami" (udane wyświetlenie 80 sprajtów jednocześnie), latające belki itp., natomiast na Amidze to tego nie doszedłem. Czy trudno w sensie ilości kodu i jego zrozumienia w ASM jest wczytać z dyskietki lub z dysku plik graficzny i go wyświetlić na ekranie?
17.09.2018 08:47
[#18]
Re: Wyciskanie OCS
@Adinfo, post #17
Czy trudno w sensie ilości kodu i jego zrozumienia w ASM jest wczytać z dyskietki lub z dysku plik graficzny i go wyświetlić na ekranie?
Najprościej to robisz copperlistę (lub otwierasz ekran/okno systemowe) i załączasz plik graficzny za pomocą dyrektywy INCIFF lub INCBIN.
Kwestia zrozumienia jak się tworzy copperlistę, lub - w drugim przypadku - korzysta z funkcji systemowych.Jeśli ten plik graficzny ma być wczytywany dynamicznie, to jest już trudniej - wówczas musisz zapoznać się z funkcjami bibliotek DOS oraz IFFParse (ew. DataTypes).
17.09.2018 08:51
[#19]
Re: Wyciskanie OCS
@Adinfo, post #17
Generalnie - łatwo (jeśli wiesz jak ustawić swój ekran bądź otworzyć systemowy, i jak ewentualnie skopiować zdekodowane dane do pamięci ekranu) jeśli mówimy o pliku typu RAW 
A jeśli chodzi o inne formaty - np. IFF to już trzeba albo skorzystać z odpowiedniej biblioteki (co samo w sobie jakieś trudne nie jest) albo samemu ogarnać parsowanie i dekodowanie obrazka (np. dekompresję RLE w formacie IFF czy BMP) co będzie tym trudniejsze im bardziej zaawansowany format pliku.
Ostatnia aktualizacja: 17.09.2018 08:55:28 przez pisklak
A jeśli chodzi o inne formaty - np. IFF to już trzeba albo skorzystać z odpowiedniej biblioteki (co samo w sobie jakieś trudne nie jest) albo samemu ogarnać parsowanie i dekodowanie obrazka (np. dekompresję RLE w formacie IFF czy BMP) co będzie tym trudniejsze im bardziej zaawansowany format pliku.Ostatnia aktualizacja: 17.09.2018 08:55:28 przez pisklak
17.09.2018 13:44
[#20]
Re: Wyciskanie OCS
@pisklak, post #19
Dzięki za podpowiedź, na pewno zacznę od analizy jakiegoś prostego przykładu w ASM i poeksperymentuję. Docelowo zależało mi na formacie IFF, ale to się zobaczy. Jesień blisko i zima to będzie więcej czasu na programowanie. Muszę jeszcze jakiś kurs ASM przestudiować i powoli iść do przodu.
17.09.2018 14:06
[#21]
Re: Wyciskanie OCS
@Adinfo, post #20
Jak chcesz wyświetlić obrazek IFF, to polecam jedną z dwóch możliwości:
Przykład:
Pod etykietą "dane" znajdzie się obraz IFF o nazwie "Obrazek.iff".
Z książek i kursów to polecam Asm-One Adama Doligalskiego. Tam dowiesz się jak używać dyrektyw asemblera, w tym INCIFF.
Powodzenia.
- Dyrektywa INCIFF, która dołącza obrazek IFF do kodu
- Biblioteka iffparse.library, która służy do czytania obrazków IFF z plików.
Przykład:
dane: INCIFF "Obrazek.iff"
Pod etykietą "dane" znajdzie się obraz IFF o nazwie "Obrazek.iff".
Z książek i kursów to polecam Asm-One Adama Doligalskiego. Tam dowiesz się jak używać dyrektyw asemblera, w tym INCIFF.
Powodzenia.
17.11.2018 22:25
[#25]
Re: Wyciskanie OCS
@cholok, post #9
Step 3.
Twierdzenie z tego wątku nie potwierdziło się w praktyce, więc porzuciłem temat zmiany kolorów poprzez cpu. Jego konwerter z dema frazetta niepoprawnie generuje copperlistę dla nieparzystych linii, zaś konwersacja z nim do niczego doprowadziła. Jak na jego umiejętności to wykazywał dziwną niewiedzę w pewnych kwestiach.
Wracając do tematu: wyświetlanie 15-bit. Na teraz są 3 opcje, z czego zająłem się dwiema. Pierwsza to ham32k. Zdaje egzamin, ale szału nie ma. Druga to mpp. Jest to narzędzie specyficzne dla AtariST, posiada kilka trybów zmiany kolorów, w tym jeden prawie idealnie kompatybilny z copperem. Jest to tryb używający blittera, który zmienia kolor co 8 pikseli, tak jak copper. Amiga ma tą przewagę, że nie musi używać żadnych zmian kolorów, gdyż wystarczy wygenerować 2 obrazki HAM, które uśrednione dadzą większą paletę niż pojedynczy HAM. No i tutaj mpp sprawuje się dużo lepiej niż ham32k.
Twierdzenie z tego wątku nie potwierdziło się w praktyce, więc porzuciłem temat zmiany kolorów poprzez cpu. Jego konwerter z dema frazetta niepoprawnie generuje copperlistę dla nieparzystych linii, zaś konwersacja z nim do niczego doprowadziła. Jak na jego umiejętności to wykazywał dziwną niewiedzę w pewnych kwestiach.
Wracając do tematu: wyświetlanie 15-bit. Na teraz są 3 opcje, z czego zająłem się dwiema. Pierwsza to ham32k. Zdaje egzamin, ale szału nie ma. Druga to mpp. Jest to narzędzie specyficzne dla AtariST, posiada kilka trybów zmiany kolorów, w tym jeden prawie idealnie kompatybilny z copperem. Jest to tryb używający blittera, który zmienia kolor co 8 pikseli, tak jak copper. Amiga ma tą przewagę, że nie musi używać żadnych zmian kolorów, gdyż wystarczy wygenerować 2 obrazki HAM, które uśrednione dadzą większą paletę niż pojedynczy HAM. No i tutaj mpp sprawuje się dużo lepiej niż ham32k.
06.12.2018 21:08
[#28]
Re: Wyciskanie OCS
@cholok, post #25
Step 4.
Usprawniłem ham32k. Generuje obraz 15-bit z 24-bitowego źródła (a raczej 2 obrazy 12-bit). Old style to algorytm ze starego ham32k, mpp style to algorytm z mpp. Mixed image to teoretyczny wzorzec, do którego wyświetlenia dążymy, a którego nigdy nie osiągniemy.
Jak to teraz wyświetlić? To jest proste, choć nieoczywiste. Wygenerowany obraz (lub obrazy) renderujemy do ham6 bez ditheringu w np. adpro, hamlab itp. Teraz można to wyświetlić tworząc 2 ramkową animkę w dpaint lub pisząc prosty program w amosie.
Usprawniłem ham32k. Generuje obraz 15-bit z 24-bitowego źródła (a raczej 2 obrazy 12-bit). Old style to algorytm ze starego ham32k, mpp style to algorytm z mpp. Mixed image to teoretyczny wzorzec, do którego wyświetlenia dążymy, a którego nigdy nie osiągniemy.
Jak to teraz wyświetlić? To jest proste, choć nieoczywiste. Wygenerowany obraz (lub obrazy) renderujemy do ham6 bez ditheringu w np. adpro, hamlab itp. Teraz można to wyświetlić tworząc 2 ramkową animkę w dpaint lub pisząc prosty program w amosie.
20.03.2022 22:24
[#29]
Re: Wyciskanie OCS
@cholok, post #28
Udostępniam zestaw kilku konwerterów: tools
duo to konwerter plików degas, duo i pl4 (przy okazji dekompresor unlz4).
kreator: duo
mpp2iff - konwerter atarowskich plików mpp do iff.
mpp
ham32k - konwerter do 15 bit (2x12 bit), tworzy pliki, które trzeba jeszcze dodatkowo zrenderować do możliwości OCS.
pierwowzór: ham32k
tomp - konwerter wszystkich mi znanych formatów do multipalette, uwzględnia nieparzystą copperlistę (SHAM, CTBL, RAST, BEAM, PCHG), konwertuje też mp do 24bit.
retro image tool
mpraw - konwerter iff do raw uwzględniający multipalette oraz może zapisać 2 obrazki 12-bit
rasta - konwerter omówiony w wątek
hcsl, hcsh - konwerter oparty na mpp, ale dostosowany do coppera, czyli zmienia paletę nie tylko w hbl, ale także w trakcie wyświetlania, wykorzystuje tryb lores 4 bitplany i hires 3 bitplany. Algorytm jest ściśle skopiowany z mpp, jak na możliwości Atari daje świetne rezultaty, ale jak na OCS to dość słabo. Jego zaletą jest generowanie dwóch obrazów dających wspólnie 15-bit gotowych do wyświetlenia (w formacie hcs).
hcs2iff - konwerter z hcs do iff.
hv - wyświetlacz hcs, wykorzystuje bezpośrednio hardware
dv - wyświetlacz mpraw, hardwarowy, uwzględnia nieparzystą copperlistę oraz 15-bit
Co do 15-bit. Jakość jest ewidentnie lepsza niż zwykłe 12-bit, ale odświeżanie 60 Hz to za mało. Elektornika LCD czy scandoublerów może pomóc w uśrednianiu kolorów.
Wyświetlacze testowane na winuae, więc nie wiem jak i czy działają na prawdziwym sprzęcie. Powinny.
Dołaczyłem kilka przykładów jednego obrazka w kilku trybach: l4.hcs, h3.hcs, ham.raw (ham+mp+lace), duo.raw (2x16 kolorów), ehb.raw (ehb+mp+lace), dham.raw (dynamic hires lace, błędnie nazwany), h.raw (15-bit ham32k+hamlab)
duo to konwerter plików degas, duo i pl4 (przy okazji dekompresor unlz4).
kreator: duo
mpp2iff - konwerter atarowskich plików mpp do iff.
mpp
ham32k - konwerter do 15 bit (2x12 bit), tworzy pliki, które trzeba jeszcze dodatkowo zrenderować do możliwości OCS.
pierwowzór: ham32k
tomp - konwerter wszystkich mi znanych formatów do multipalette, uwzględnia nieparzystą copperlistę (SHAM, CTBL, RAST, BEAM, PCHG), konwertuje też mp do 24bit.
retro image tool
mpraw - konwerter iff do raw uwzględniający multipalette oraz może zapisać 2 obrazki 12-bit
rasta - konwerter omówiony w wątek
hcsl, hcsh - konwerter oparty na mpp, ale dostosowany do coppera, czyli zmienia paletę nie tylko w hbl, ale także w trakcie wyświetlania, wykorzystuje tryb lores 4 bitplany i hires 3 bitplany. Algorytm jest ściśle skopiowany z mpp, jak na możliwości Atari daje świetne rezultaty, ale jak na OCS to dość słabo. Jego zaletą jest generowanie dwóch obrazów dających wspólnie 15-bit gotowych do wyświetlenia (w formacie hcs).
hcs2iff - konwerter z hcs do iff.
hv - wyświetlacz hcs, wykorzystuje bezpośrednio hardware
dv - wyświetlacz mpraw, hardwarowy, uwzględnia nieparzystą copperlistę oraz 15-bit
Co do 15-bit. Jakość jest ewidentnie lepsza niż zwykłe 12-bit, ale odświeżanie 60 Hz to za mało. Elektornika LCD czy scandoublerów może pomóc w uśrednianiu kolorów.
Wyświetlacze testowane na winuae, więc nie wiem jak i czy działają na prawdziwym sprzęcie. Powinny.
Dołaczyłem kilka przykładów jednego obrazka w kilku trybach: l4.hcs, h3.hcs, ham.raw (ham+mp+lace), duo.raw (2x16 kolorów), ehb.raw (ehb+mp+lace), dham.raw (dynamic hires lace, błędnie nazwany), h.raw (15-bit ham32k+hamlab)
