Spektroskop by Kaz 2008-09-23 23:05:19
Jeszcze nie opadł kurz, który wzbił się dzięki tumultowi
rozentuzjazmowanego tłumu Atarowców podnieconych emulatorem Apple
II, do których i ja należę, a już mamy kolejne sensacyjne
doniesienia w temacie przenoszenia oprogramowania z innych
komputerów.
Numer z wejściem smoka wykona dzisiaj kolega Jerzy "Mono" Kut znany z nieukończonej jeszcze gry "Samobójcy", programu graficznego Graph8 oraz niezłej grafiki. Jurek objawił się nam w społeczności całkiem niedawno, a już uzyskał status członka panteonu sław kodujących na Atari :).
Program, do którego zaproponowałem nazwę Spectroscope vel Spektroskop, służy do konwertowania grafiki z ZX Spectrum na taką postać, którą może wyświetlić Atari. Duszki naszego 8-bitowca służą do podkolorowania trybu hi-res i są odpowiednikiem atrybutów na trumience. Najciekawsze jest to, że program robi konwersję w czasie rzeczywistym i to dość szybko, dzięki czemu można to zastosować w ewentualnym emulatorze czy innym programie, który wymaga dynamicznej, kolorowej grafiki z ZX Spectrum.
Kiedy Jurek napisał do mnie kilka miesięcy temu o tym, że ma zamiar napisać taki konwerter, ale nie ma na niego czasu, to sądziłem, że kolejny ciekawy projekt będzie ciągnął się latami. Oto co pisał Mono w marcu: "Skoro pytasz, to powiem, że w niewielkiej tajemnicy (wtajemniczone są 4 osoby :D) dla Atari mam otwarty projekt konwertera grafiki ZX Spectrum na Atari XL/XE :).
Jak wiadomo ZX Spectrum posiada dostępną paletę 15 kolorów. Spectrumowcy mówią, że dostępnych jest 16, ale mają dostępny kolor czarny i czarny jasny. Na oryginalnym ZX Spectrum 48k widoczne są one jako identyczne barwy; na niektórych rosyjskich klonach, jako oddzielne kolory. Ekran podzielony jest na chunki 8x8 i dla każdego z nich określony jest osobny kolor atramentu i osobny kolor tła. Mniejsza zresztą o to, bo będzie można to parametryzować. Piszę konwerter, który na podstawie obrazka z ZX Spectrum automatycznie wygeneruje odpowiednią optymalną konfigurację, lub konfiguracje, bo może ich być kilka(-naście,-dziesiąt) dla przerwań DLI. Konfiguracje oczywiście będą optymalizowane pod kątem jak najlepszego wykorzystania przerwań DLI i liczby kolorów w wierszu. Ekran dostępny jest oczywiście w trybie 32 znaków w wierszu (ZX Spectrum 48k ma hires 256x192).
Mam cichą nadzieję, że kiedy mój konwerter zadziała, wtedy usiądę i napiszę też engine do przeliczania w locie procedur DLI dla grafiki pod kątem wykorzystania go w grach XXL'a. Modyfikacja w locie jest niezbędna kiedy na ekranie zachodzą dynamiczne zmiany. Liczyłem, że bez obciążania procesora (tylko proste DLI na początku wiersza) dałoby się uzyskać na ekranie w wierszu (8 linii skaningowych) 7 kolorów za pomocą GTIA i PMG. Z obciążeniem procesora (przełączanie pozycji i kolorów PMG w każdej linii skaningowej) być może kilka więcej zależnie od zawartości grafiki. Wtedy wszystkie sprajty w grach byłyby robione programowo, a ograniczona mapa kolorów realizowana za pomocą PMG. Automat musiałby być bardzo szybki, żeby DLI można było modyfikować w obszarze VBLK (podczas modyfikacji oczywiście nie może sie wykonywać żadne przerwanie DLI), a to może się okazać niewykonalne - zobaczymy. Myślę, że przy odpowiedniej konstrukcji engine dałoby się to zrobić :D.
W planie (po zakończeniu eksperymentów z konwereterem) jest jeszcze porządna konwersja gier "Droga do Duplandu" i "Ucieczka ze Spejsszipu" Yerzmyey'a, których jestem miłośnikiem (takie mam absurdalne skrzywienie). Może też uda mi się Yerzmyey'a namówić na jakiś slideshow jego grafik przerobionych na Atari XL/XE i pokazalibyśmy to na jakimś party. Ale warunkiem koniecznym jest oczywiście pozytywny efekt działania konwertera."
Nic nie mówiąc nikomu Mono postanowił działać i oto ponownie mogę oddać mu głos, tym razem jako autorowi konwertera: "Program pokazuje grafiki zapisane w formacie .scr czyli żywy zrzut ekranu z atrybutami ($1b00 bajtów począwszy od $4000). Dowolną grafikę z ZX Spectrum można w zasadzie zgrać na emulatorze i spróbować obejrzeć - program przeprowadza konwersję "w locie". Nie jest to jeszcze skończone, co możesz wywnioskować po błędach w pokazywanej grafice. Niestety nie wszystkie konwersje da się przeprowadzić bezbłędnie, ze względu na możliwości Atari w trybie hires i ograniczenia ilości sprajtów.
Obecnie program przeprowadza małą optymalizację grafiki - jeśli w obrazkach znajdują się chunki 8x8 z tłem w kolorze czarnym, to taki chunk wypełniany jest kolorem atramentu, który z założenia jest czarny. Dodatkowo statystycznie określa się wykorzystanie kolorów w linii i na tej podstawie rozmieszcza playery i ustalane są ich kolory. Missiles są łączone w 5 playera, ale są rozmieszczane błędnie - chodziło mi tylko o sprawdzenie czy da się pokryć pokazywane grafiki we wszystkich miejscach dostępnymi sprajtami. Optymalizowane są również zmiany kolorów w następujących po sobie wierszach oraz zmiany pozycji sprajtów. Optymalizacje te nie są pełne, tzn. nie są testowane wszystkie kombinacje (co niestety ogromnie spowolniło by algorytm). Planuję jednak zrobić w finalnej wersji wybór lepszej jakości kosztem czasu wyświetlania. No i wybieraczkę plików.
Dodatkowo generowany jest kod przerwań DLI, dzięki czemu procedura DLI działa maksymalnie szybko. Brakuje optymalizacji pełnych (albo przynajmniej lepszego dobierania rozłożenia sprajtów zależnie od treści ekranu), przełączania trybów 5/4 graczy co wiersz DLI (tam gdzie to oczywiście potrzebne), ale jak będę miał trochę czasu to dorobię.
Obecnie widział to Yerzmyey (który nie wierzył, że taki viewer w ogóle zrobię haha), no i XXL, bo uproszczone algorytmy sprawdzałem z myślą generowania mapy duchów w locie dla jego konwersji z ZX Spectrum. Ale póki co to jeszcze się to do tego nie nadaje, bo jest za wolne i niedokładne. Na oryginalnym Atari widziałem to dzięki SIO2PC/SIO2BSD i wygląda znacznie lepiej niż na emulcu.
Front prac nad tym jest w sumie dość jasno określony: dopracowanie algorytmów rozkładania sprajtów (parę pomysłów jeszcze mam), a potem upraszczanie w celu jak najszybszego generowania zmian mapy sprajtów dla gier XXL (o ile się da). No i nie wiem, czy XXL będzie chciał tego użyć, bo zabierze mu to cenne cykle procesora :)."
Tyle od niesamowitego Jerzego, który uparcie próbuje zaprzeczyć, że jego nick wziął się od zamiłowania do grafiki monochromatycznej :). Downloadu nie ma, ale jak tylko Mono poprawi błędy i dokończy program dostaniemy linkę do programu. Na razie trochę zrzutów ekranowych z różnych wersji programu Spectroscope.
Numer z wejściem smoka wykona dzisiaj kolega Jerzy "Mono" Kut znany z nieukończonej jeszcze gry "Samobójcy", programu graficznego Graph8 oraz niezłej grafiki. Jurek objawił się nam w społeczności całkiem niedawno, a już uzyskał status członka panteonu sław kodujących na Atari :).
Program, do którego zaproponowałem nazwę Spectroscope vel Spektroskop, służy do konwertowania grafiki z ZX Spectrum na taką postać, którą może wyświetlić Atari. Duszki naszego 8-bitowca służą do podkolorowania trybu hi-res i są odpowiednikiem atrybutów na trumience. Najciekawsze jest to, że program robi konwersję w czasie rzeczywistym i to dość szybko, dzięki czemu można to zastosować w ewentualnym emulatorze czy innym programie, który wymaga dynamicznej, kolorowej grafiki z ZX Spectrum.
twórczość Spectrumowa Yerzmeya - z gry
"Droga do Duplandu" oraz z dema "Bunch of Arse" - na górze
Spectrum, na dole Atari
Kiedy Jurek napisał do mnie kilka miesięcy temu o tym, że ma zamiar napisać taki konwerter, ale nie ma na niego czasu, to sądziłem, że kolejny ciekawy projekt będzie ciągnął się latami. Oto co pisał Mono w marcu: "Skoro pytasz, to powiem, że w niewielkiej tajemnicy (wtajemniczone są 4 osoby :D) dla Atari mam otwarty projekt konwertera grafiki ZX Spectrum na Atari XL/XE :).
Jak wiadomo ZX Spectrum posiada dostępną paletę 15 kolorów. Spectrumowcy mówią, że dostępnych jest 16, ale mają dostępny kolor czarny i czarny jasny. Na oryginalnym ZX Spectrum 48k widoczne są one jako identyczne barwy; na niektórych rosyjskich klonach, jako oddzielne kolory. Ekran podzielony jest na chunki 8x8 i dla każdego z nich określony jest osobny kolor atramentu i osobny kolor tła. Mniejsza zresztą o to, bo będzie można to parametryzować. Piszę konwerter, który na podstawie obrazka z ZX Spectrum automatycznie wygeneruje odpowiednią optymalną konfigurację, lub konfiguracje, bo może ich być kilka(-naście,-dziesiąt) dla przerwań DLI. Konfiguracje oczywiście będą optymalizowane pod kątem jak najlepszego wykorzystania przerwań DLI i liczby kolorów w wierszu. Ekran dostępny jest oczywiście w trybie 32 znaków w wierszu (ZX Spectrum 48k ma hires 256x192).
gra "Back to Skool" - na górze oryginały ze
Spectrum, na dole efekt działania Spectroscope
Mam cichą nadzieję, że kiedy mój konwerter zadziała, wtedy usiądę i napiszę też engine do przeliczania w locie procedur DLI dla grafiki pod kątem wykorzystania go w grach XXL'a. Modyfikacja w locie jest niezbędna kiedy na ekranie zachodzą dynamiczne zmiany. Liczyłem, że bez obciążania procesora (tylko proste DLI na początku wiersza) dałoby się uzyskać na ekranie w wierszu (8 linii skaningowych) 7 kolorów za pomocą GTIA i PMG. Z obciążeniem procesora (przełączanie pozycji i kolorów PMG w każdej linii skaningowej) być może kilka więcej zależnie od zawartości grafiki. Wtedy wszystkie sprajty w grach byłyby robione programowo, a ograniczona mapa kolorów realizowana za pomocą PMG. Automat musiałby być bardzo szybki, żeby DLI można było modyfikować w obszarze VBLK (podczas modyfikacji oczywiście nie może sie wykonywać żadne przerwanie DLI), a to może się okazać niewykonalne - zobaczymy. Myślę, że przy odpowiedniej konstrukcji engine dałoby się to zrobić :D.
gra "Navy Seal" w dwóch wersjach
W planie (po zakończeniu eksperymentów z konwereterem) jest jeszcze porządna konwersja gier "Droga do Duplandu" i "Ucieczka ze Spejsszipu" Yerzmyey'a, których jestem miłośnikiem (takie mam absurdalne skrzywienie). Może też uda mi się Yerzmyey'a namówić na jakiś slideshow jego grafik przerobionych na Atari XL/XE i pokazalibyśmy to na jakimś party. Ale warunkiem koniecznym jest oczywiście pozytywny efekt działania konwertera."
Nic nie mówiąc nikomu Mono postanowił działać i oto ponownie mogę oddać mu głos, tym razem jako autorowi konwertera: "Program pokazuje grafiki zapisane w formacie .scr czyli żywy zrzut ekranu z atrybutami ($1b00 bajtów począwszy od $4000). Dowolną grafikę z ZX Spectrum można w zasadzie zgrać na emulatorze i spróbować obejrzeć - program przeprowadza konwersję "w locie". Nie jest to jeszcze skończone, co możesz wywnioskować po błędach w pokazywanej grafice. Niestety nie wszystkie konwersje da się przeprowadzić bezbłędnie, ze względu na możliwości Atari w trybie hires i ograniczenia ilości sprajtów.
gra "Where Time Stood Still"
Obecnie program przeprowadza małą optymalizację grafiki - jeśli w obrazkach znajdują się chunki 8x8 z tłem w kolorze czarnym, to taki chunk wypełniany jest kolorem atramentu, który z założenia jest czarny. Dodatkowo statystycznie określa się wykorzystanie kolorów w linii i na tej podstawie rozmieszcza playery i ustalane są ich kolory. Missiles są łączone w 5 playera, ale są rozmieszczane błędnie - chodziło mi tylko o sprawdzenie czy da się pokryć pokazywane grafiki we wszystkich miejscach dostępnymi sprajtami. Optymalizowane są również zmiany kolorów w następujących po sobie wierszach oraz zmiany pozycji sprajtów. Optymalizacje te nie są pełne, tzn. nie są testowane wszystkie kombinacje (co niestety ogromnie spowolniło by algorytm). Planuję jednak zrobić w finalnej wersji wybór lepszej jakości kosztem czasu wyświetlania. No i wybieraczkę plików.
Dodatkowo generowany jest kod przerwań DLI, dzięki czemu procedura DLI działa maksymalnie szybko. Brakuje optymalizacji pełnych (albo przynajmniej lepszego dobierania rozłożenia sprajtów zależnie od treści ekranu), przełączania trybów 5/4 graczy co wiersz DLI (tam gdzie to oczywiście potrzebne), ale jak będę miał trochę czasu to dorobię.
gra "Skool Daze"
Obecnie widział to Yerzmyey (który nie wierzył, że taki viewer w ogóle zrobię haha), no i XXL, bo uproszczone algorytmy sprawdzałem z myślą generowania mapy duchów w locie dla jego konwersji z ZX Spectrum. Ale póki co to jeszcze się to do tego nie nadaje, bo jest za wolne i niedokładne. Na oryginalnym Atari widziałem to dzięki SIO2PC/SIO2BSD i wygląda znacznie lepiej niż na emulcu.
Front prac nad tym jest w sumie dość jasno określony: dopracowanie algorytmów rozkładania sprajtów (parę pomysłów jeszcze mam), a potem upraszczanie w celu jak najszybszego generowania zmian mapy sprajtów dla gier XXL (o ile się da). No i nie wiem, czy XXL będzie chciał tego użyć, bo zabierze mu to cenne cykle procesora :)."
Tyle od niesamowitego Jerzego, który uparcie próbuje zaprzeczyć, że jego nick wziął się od zamiłowania do grafiki monochromatycznej :). Downloadu nie ma, ale jak tylko Mono poprawi błędy i dokończy program dostaniemy linkę do programu. Na razie trochę zrzutów ekranowych z różnych wersji programu Spectroscope.
luka 2008-09-24 00:09:55
był chyba pomysł pewnej drobnej przeróbki sprzętowej, która mogłaby idealnie wykorzystać możliwości tego programu
nosty 2008-09-24 00:43:30
aha... takie cus co po zaprogramowaniu odciazyloby procka przy przelaczaniu kolorow w srodku linii? Niestety jest na razie tylko w teorii, bo przerobka nie jest taka "drobna". Imho rozszerzenie byloby swietne i bardzo zgodne z "duchem Atari".
atari800xe 2008-09-24 01:04:03
Lał! Nie zdążyłem ochłonąć po emulatorze Apple II a tu taki numer. Jakość podkolorowania grafiki konwersji screnów jest wręcz idealna. Z niedowierzaniem patrze, że większość nie ustępuje oryginałom. Wiele bym dał aby obejrzeć to na oryginalnym atari.
Szczęśliwy jestem bom zobaczył tą nowinkę jako jeden z pierwszych:)
luka 2008-09-24 01:04:56
ooo, tu jest o tym, chyba jest to dosyć sensowne
http://atariarea.krap.pl/forum/viewtopic.php?id=5688
sikor 2008-09-24 08:04:13
Ładne, ładne... I zacne. JAk pisałem na forum - potrzebujemy kolejny katalog u KAZa. Należy już wyodrębnić emulatory - bo w sumie to też taki emulator, tylko tyle, że grafiki...
Gratulacje dla MONO!!!
pavros 2008-09-24 09:46:25
luka: Dzięki za przypomnienie tematu. Właśnie sam to chciałem uczynić. Dodam tylko, że schemat urządzenia już istnieje, a Zenon/Dial pracuje nad budową prototypu.
irwin 2008-09-24 09:50:35
No jak dla mnie BOMBA! jak to swego czasu powiedział kolega Nobla widząc jego prezentację dynamitu ;-)
Mam takie pytanie - czy sam algorytm tej konwersji dałoby się zaprząść do programu... Graph2Font Tebe'go? Program pozwalałby wtedy na wczytanie 16 kolorowego bmp a nowa metoda wynikła z algorytmu, sama poustawiała by sprity. Kaz, Tebe - dałoby się?
Kaz 2008-09-24 10:03:45
Pavros - bardzo sie ciesze, ze prace nad rozszerzeniem postepuja. A udalo sie tez namowic Electrona na implementacje w VBXE? Bo on chyba wlasnie konczy prace nad rdzeniem, wiec chyba jest najlepszy moment. I ustalcie jakas nazwe dla rozszerzenia, zeby latwiej sie o nim dyskutowalo. Widzialem, ze uzywa sie "ikplus", ale czy to oficjalna nazwa? :)
Irwin - to nie pytanie do mnie czy TeBe, raczej do Mono (czy chcialby przepisac program z Atari na PC). Moze to nawet istniec jako osobny konwerter, niekoniecznie w G2F.
irwin 2008-09-24 10:14:14
Racja, tylko że w G2F taką grafikę możnaby poddać dalszej obróbce już ręcznej. Tym sposobem dzięki kombinacji alogrytm/konwersja Mono+G2F Tebe dostalibyśmy znakomite narzędzie do malowania, konwersji obrazków.
Kaz 2008-09-24 10:20:21
Ale jedno nie wyklucza drugiego - konwerter nie musi byc wbudowany w program G2F, moze zapisywac w formacie G2F (na przyklad sama warstwe duszkow - plik PMG).
Twoj pomysl jest bardzo dobry - pozwoli miec juz gotowa podkolorowanie, w ktorej bedzie mozna sie skupic tylko na szczegolach, zeby je dopiescic.
pavros 2008-09-24 10:27:31
Kaz: Rozmawialem z Electronem wstępnie w Głuchołazach i nie miał on raczej nic przeciwko. Skontaktuję się z nim w takim razie na dniach. Co do nazwy, to najciekawsza, jaką udało mi się wymyslić to "Fade to black" czyli "ściemnij do czarnego". Fraza ta, odnosząca się do regulacji odbiornika TV, jest dość chwytliwa i była wielokrotnie wykorzystywana (utwór Metallic[k]-i, tytuł gry komputerowej). Dlatego sądzę, że będzie łatwa do zapamiętania. Ja proponuję używać jednego ze skrótów: FTB, F2B albo po prostu FADE. Zarówno dla nazwy nowego trybu graficznego jak i samego rozszerzenia.
irwin 2008-09-24 10:31:26
Tak też można by to zrobić, masz całkowitą rację. Ewentualnie w takim konwerterze byłaby opcja zapisywać w *.g2f (oczywiście za zgodą tebe)
Ponadto jak czytam Mono usiłuje na Atari wszystko zoptymalizować, to jasne - w końcu na realnym Atari chcąc grać w gry Zx taka konwersja musi być szybka. Może miał jakiś pomysł który zarzucił właśnie z uwagi na szykość. Na PC nie ma tych ograniczeń, może skorzystać z jakiejś dokładniejszej i czasochłonej wersji swojej metody - wszak tu nie musimy martwić się o szybkość, a o jakość.
Ponadto2 - można spróbować tej zadaptować tę metodę nie tylko na trybie Hires ale i 160xXXX.
MDW 2008-09-24 11:03:57
Rety, co się dzieje z tym Atari... Normalnie sto razy lepiej niż w czasach świetności małego Atari. Jestem pełen podziwu. Chylę czoła przed takimi ludźmi.
Kaz 2008-09-24 11:11:08
To moze po prostu Fader. Albo Black Fader - to juz znaczeniowo nie to samo, ale za to latwiej sie wymawia :).
irwin - z tego co wiem to Mono chce zrobic co najmniej dwie wersje konwersji - szybką i mniej dokladną oraz wolną i bardziej dokladna.
Kaz 2008-09-24 11:12:11
MDW - czasy swietnosci Atari dopiero nadchodza :)
irwin 2008-09-24 11:17:47
np Mono pisze: "Optymalizacje te nie są pełne, tzn. nie są testowane wszystkie kombinacje (co niestety ogromnie spowolniło by algorytm)." Na PC w konwerterze, czas nie grałby roli i efekty konwersji myślę że byłby nawet lepsze (a i tak chylę czoła na to co widzę powyżej) Jeśliby Mono/Tebe/ktokolwiek zrobiłby taki konwenter (algorytm już jest a to w sumie najważniejsze) to byłaby super sprawa, SUPER BOMBA ;-)
bob_er 2008-09-24 11:21:09
ja troche pomarudze :P
podkolorywanie atarowskiego hi-resu roznymi kolorami wg mnie wyglada strasznie. ni z gruchy, ni z pietruchy pojawiaja sie jakies kosmiczne kwadraty. takie cos trzeba bardzo umiejetnie stosowac (np. logo na srodku ekranu na stronie tytulowej w grze vicky - chyba z copyrightem lub w sposob, ktory robi to graph2font - ale tam cala moc proca na to idzie).
o wiele lepiej to wyglada, jesli sie robi to tym samym kolorem, ale inna jasnoscia. wtedy kwadraty znikaja i mamy 3-kolorowy (lub 3-jasnosciowy jak kto woli) hires. takie cos mozna robic dynamicznie, i lepiej to wyglada (imho).
irwin 2008-09-24 11:33:31
@Bob_er - no każdy ma inny gust, mnie akurat się podoba, bo po pierwsze bo wszyscy znamy ograniczenia Atari i cudów na miarę grafiki z Amigi oczekiwać nie należy, a po drugie to jak sam autor pisze nie jest jeszcze ostatnie słowo.
@Kaz, @Mono - sam konwerter nie musiałby być jakiś super wypasiony, może na początek prosty, z komendami w wierszu poleceń, w sumie chodzi tylko oto aby zapisał grafikę do *.g2f lub jak Kaz pisze do *.pmg . Ewentualnie jakby doszło do porozumienia na linii Mono-Tebe ;-) - jako dodatkowy, wybieralny w opcjach programu Graph2Font, nowy tryb konwersji.
Kaz 2008-09-24 11:34:58
irwin - tyż racja.
bob_er - oczywiscie, ze najlepsza jest reczna, dokladna konwersja, ale to jest automat do konwersji, wiec trudno wymagac, zeby decydowal co jest na obrazku wazniejsze :). No chyba, zeby Mono wprowadzil jakies metody heurystyczne do oceny obrazka albo sztuczna inteligencje :).
Pomysl ze zmiana jasnosci jest jednak zacny - taka opcja tez byla by fajna! Mono, co Ty na to?
pavros 2008-09-24 11:39:45
Kaz: Fader albo Black Fader - może też tak być. Albo Color Fader. Nazwa w tym stylu jest może rzeczywiście bardziej adekwatna, bo w sumie to jest bardziej funkcja niż samodzielny tryb graficzny. Funkcja, która może być zastosowana do każdego trybu graficznego, choć nie w każdym ma sens.
Sprawdziłem w słowniku:
Fader - tłumik; regulator, potencjometr funkcji fade
Black fader - ściemniacz w kamerze [TV]
Kaz 2008-09-24 11:43:39
To ja jestem za Color Fader (CFR) - bo w koncu tak to chyba dziala :).
pavros 2008-09-24 12:28:12
Dokladnie. To rozszerzenie jest "tłumikiem koloru" sterowanym luminancją. BTW Email do Electrona już poszedł.
mono 2008-09-24 15:42:46
@luka, @nosty: Bardzo fajnie, że poruszyliście sprawę rozszerzenia zaproponowanego przez pavros'a na atariarea. Tablica mapowania kolorów w moim programie wygląda tak:
; mapowanie kolorow zx spectrum
colmap equ *
dta b($00) ;czarny
dta b($82) ;niebieski
dta b($22) ;czerwien
dta b($44) ;fiolet
dta b($c4) ;zielony
dta b($a8) ;b($98) ;blekitny / turkusowy
dta b($ea) ;ciemny zolty/oliwkowy
dta b($08) ;jasny szary
dta b($02) ;szary
dta b($84) ;jasny niebieski
dta b($24) ;jasny czerwien
dta b($36) ;rozowy
dta b($ca) ;jasna zielen
dta b($ae) ;b($9a) ;jasny blekit / jasny turkusowy?
dta b($ee) ;zolty
dta b($0e) ;bialy
Jak widać luminancję $x0 posiada tylko kolor czarny, więc i modyfikacja pavros'a nie kolidowałaby z niczym. Tablica nie jest finalna, ale subiektywnie najlepsza, jaką udało mi się na emulatorze atari800 uzyskać. Jeśli ktoś potrafi ją poprawić i wierniej dobrać kolory, jest mile widziany :)
Tak w ogóle, to tryb pavrosa daje nam możliwości kolorystyczne zbliżone do Commodore 16 (112 kolorów i 16 czerni) więc może pokusić się o konwersję z c16? :).
Wiem, że wbiję kij w mrowisko, ale ciekawi mnie jak bardzo pracochłonne byłoby stworzenie przystawki umożliwiającej ustawienie dowolnej palety kolorów na oryginalnym Atari? I na ile rozwiązanie zbliżyłoby się kosztem i ceną do vbxe. Być może jest to niemożliwe bez konstruowania vbxe, bo przecież informacje o kolorach są pobierane z wewnętrznych rejestrów gtia... Ale taka przystawka pozwalałaby na uzyskanie normalnego czerwonego, soczystego zielonego, i in. kolorów, które ma ZX Spectrum a nie mamy my.
@irwin: Jeśli chodzi o integrację z g2f nie widzę problemów innych niż moja ignorancja w progamowaniu w Delphi (o ile wiem g2f jest napisany w obiektowym pascalu?), którego po prostu nie znam :( Najbliższy mi język programowania wysokiego poziomu to Java (może być też C++) i w nim mogę zrobić odpowiedni konwerter (tak zresztą miało być na początku, ale zarzuciłem pomysł kiedy usiadłem przy Atari :D). Niezależnie jednak od tego do konwertera będą dostępne źródła (xasm), więc jeśli ktoś będzie chciał go wykorzystać/poprawić/coś dodać może czuć się wolny.
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. Trzeba by to przemyśleć.
Jakkolwiek konwerter nie jest jeszcze skończony i myślę, że mowa o integracji z czymkolwiek, albo w ogóle o jakimś sensownym wykorzystaniu go jest jeszcze przedwczesna.
@bob_er: Podkolorowywanie hiresu wygląda strasznie. Niestety. Winne są przebarwienia i gdyby to u nas działało, jak na Spectrumie nie byłoby problemu. Myślę jednak, że korzyść z posiadania mapy kolorów w hiresie jest na tyle duża, że można przymknąć oko na te ograniczenia (ja przymykam) :) Nie jestem niestety w stanie wyeliminować tych przebarwień na stock Atari.
Jeśli zaś chodzi o kwadraty, które pojawiają się w różnych miejscach - technika wykorzystywana przeze mnie polega na określeniu, który kolor jest najczęściej użyty w wierszu i ustaleniu koloru tła COLPF2. Rzadziej wykorzystywane kolory są podkładane sprajtami. Jeśli gdzieś w takim wierszu mam cały kwadrat czarny, nie podkładam tam nic, a jedynie wypełniam go kolorem znaku COLPF1, który ma zawsze jasność ustawioną na $x0. Niestety przebarwienie powoduje, że taki kwadrat jest zielony, lub niebieski, albo purpurowy zależnie od tego jaki kolor dominuje w wierszu. Jeśli przy takim kwadracie znajdzie się sprajt, to efekt jest nieładny :( Może przy innym algorytmie uzyskalibyśmy lepszy efekt, ale mogłoby zabraknąć sprajtów (często i tak już teraz ich brakuje). Efekt działania algorytmu oglądany na emulatorze wygląda niestety źle. Widzieliśmy te obrazki z Yerzmyey'em na tv (crt) i ja tych przebarwień nie widziałem (!). Może to specyfika Yerzmyey'owego tv, może na lcd tv, albo na monitorze kolorowym znowu przebarwienia będą. Nie mam zielonego pojęcia, bo do oryginalnego Atari sam posiadam tylko monitor mono.
Pomysł z 3-jasnościowym hiresem jest bardzo dobry. Gdyby zastosować jeszcze nakładanie sprajtów dałoby się uzyskać 4 poziomy szarości, a to już chyba nie najgorzej. Policzmy: 2 jasności COLPF1/2, 4 sprajty (player+missiles) + nakładanie, 5 player; to nam daje 7/8 odcieni w wierszu. Bez przebarwień.
Bardzo twórcza dyskusja :)
mono 2008-09-24 15:50:20
Commodore 16 ma oczywiście 121 kolorów (8 czerni liczy się za 1 kolor).
irwin 2008-09-24 17:05:37
@Mono - dzięki za wyjaśnienie, a więc sumując: taki konwerter na PC jest możliwy, i do tego będzie po tych zmianach co powyżej piszesz produkował jeszcze lepszą konwersję sprajtów. I będzie możliwość pracy w trybach 160px. No czegóż chcieć więcej! - Oj Kaz ma rację pisząc powyżej: "czasy swietnosci Atari dopiero nadchodza :)"
O szybkość pracy rozbudowanego algorytmu tu się raczej nie ma co się martwić - wszak zamiast 1.79mhz na piecykach mamy czasem i 1ghz (choć u mnie jedynie 600mhz)
Tak więc pozostaje jedynie dopingować Cię do jak najszybszego zakończenia prac a nie tylko emumaniacy ;-) ale i graficy a w domyśle wszyscy atarianie ;-) z tego skorzystają.
tebe 2008-09-24 20:04:12
przebarwienia w HiRes są widoczne jeśli kolor tła <> koloru ducha/pocisku, jeśli jest równy wówczas nie będzie widać przebarwień, chęć usunięcia przebarwień ograniczy nas wówczas tylko do używania jasności
w formacie G2F czy innym skojarzonym z G2F można zapisywać bez potrzeby pytania mnie o zdanie, jeśli tylko ktoś czuje się na siłach aby zmierzyć się z takim plikiem, taki plik PMG dla G2F to nie są dane które wczytuje się do Atari
GTIA generuje kolory na podstawie opóźnień czasowych, bez przebudowania wewnętrznej struktury układu GTIA nie da sie uzyskać innych kolorów (potrzebne informacje można znaleźć w dokumentacji układu GTIA), ogólnie sprawa sprowadza się do VBXE
bob_er 2008-09-24 22:17:18
jak wyglada 3-jasnosciowy hires mozna zobaczyc pod koniec dema 'unfused' - ostatnia kolorowa akcja. sa tam 2 rozne patterny na znakach oraz dynamicznie generowanych sprite'ach (kolor tla+kolor fontow+kolor sprite'ow).
andygroo 2008-09-27 01:39:16
no wlasnie tu jest przyklad braku nasycenia kolorami waszego komputerka...boze co oni wam zrobili...nie idzie w jakis prosty sposob naprawic to u was? pomijam regulacje tv.... gdzie tkwi blad konstrukcyjny???? skad taki rozklad kolorow... naprawde to powazna wada i nie mial tego chyba zaden innym komputer domowy
Kaz 2008-09-27 18:53:43
Z mojego punktu widzenia to barwy Spectrum sa przejaskrawione... boze co oni wam zrobili? :) Nie, no sorki, ale o mowienie, ze kolory Atari czy Commodore maja "wade" w porownaniu ze Spectrum to troche.. teges :).
sikor 2008-09-27 21:36:47
Co do kolorystyki - rzecz gustu. W Atari naprawdę można wyregulować dobrze kolory - i nie chodzi tu o telewizor/monitor, jest taki mały potencjometr... Brak czerwonego? Nie zauważyłem, może za krótko używam Atari (hmm, chyba od 1987 roku), ktoś mi mówił, że nie ma. Może mam uszkodzony egzemplarz, nie wiem - w moim jest ;) Dla mnie kolory na ZX są za jaskrawe (działają na mnie jak interlejs albo i gorzej), ale i tak część grafik mi się podoba. Wykorzystanie zbyt wielu kolorów czasem zaciemnia rzecz, nawet w grach (niektóre w C64). Nie podobają mi się atrybuty na ZX-sie (te kwadraty przy postaciach), w Atari tego nie ma.
Co powiedzieć? Każdy komputer ma swoje wady i zalety, ja tam swoje małe Atari lubię i przy nim pozostanę.
mono 2008-09-28 01:31:55
O ile się orientuję, na C64 były podobne tonacje. Wezmę jednak trochę w obronę moje Atari. Mamy 128 kolorów dostępnych naraz na ekranie (na podobnej zasadzie posiadacze C16 mieli 121 kolorów). W niektórych trybach dostępne jest 2x więcej a więc 256. Bez interlace! To jest 16 kolorów po 8 lub po 16 odcieni. Dzięki temu w zasadzie nie ma problemu z dobraniem kolorystyki przy portowaniu gier. ALE...! Ale faktycznie w dostępnej palecie nie mamy dostępnych niektórych chrominancji... :( jeśli chodzi o paletę to Kaz ostatnio pokazywał jak wygląda (http://atarionline.pl/v01/index.php?subaction=showfull&id=1218504159
&archive=&start_from=&ucat=1&ct=nowinki); tutaj (http://en.wikipedia.org/wiki/MOS_Technology_TED) jest za to paleta C16 - można porównać. Generalnie moim zdaniem - tak - nie mamy nasyconych kolorów (ta Spectrumowska czy BBC'owska czerwień!). Ale nie zielonego :) Zielonych akurat mamy chyba ze 3. Mamy też morski (navy), parę niebieskich, żółty, brąz i inne. Zapraszam na strony z paletami dla porównania. Za to VBXE (jak któryś z przedmówców wspomniał) rozwiązuje te problemy :)
Kaz 2008-09-28 12:31:51
Na ostatnim KWAS-ie byl moj XEGS z VBXE podlaczony do telewizora przez RGB (dzieki Electron!). Kolorki swietne, obraz jak brzytwa, sa swiadkowie.
homek 2008-09-28 15:16:14
jehowy? ;-]
Kaz 2008-09-28 17:10:12
Dla krytykantow palety Atari proponuje nastepujacy eksperyment naukowy: jesli masz Spectrum - napisz na nim program konwertujacy cala palete kolorow z Atari i pokaz nam efekty. To samo proponuje na Commodore, Amstradzie, BBC i innych komputerach 8-bitowych. Wtedy porownamy wady i zalety kolorow, moze sie nawet wspolnie posmiejemy :)
José Pereira 2009-07-08 20:17:56
What hapen?
Something was done? Any code?
Can I contact the author?
Thanks.
José Pereira
Kaz 2009-07-09 17:14:54
As far as I know, Spektroskop is still under development. Code is not available (yet?). Mono is the author, ask question to him by forum, more people is interesting in answers :).
Kaz 2009-07-10 13:00:12
Mono wrote that one point from his to-do list had left to do. He will try to finish it during or after his holiday he just started today :).
José Pereira 2009-07-10 23:31:21
Many thanks.
Hope he finish the project soon.
Congratulations to him.
Bye.
José Pereira.
był chyba pomysł pewnej drobnej przeróbki sprzętowej, która mogłaby idealnie wykorzystać możliwości tego programu
nosty 2008-09-24 00:43:30
aha... takie cus co po zaprogramowaniu odciazyloby procka przy przelaczaniu kolorow w srodku linii? Niestety jest na razie tylko w teorii, bo przerobka nie jest taka "drobna". Imho rozszerzenie byloby swietne i bardzo zgodne z "duchem Atari".
atari800xe 2008-09-24 01:04:03
Lał! Nie zdążyłem ochłonąć po emulatorze Apple II a tu taki numer. Jakość podkolorowania grafiki konwersji screnów jest wręcz idealna. Z niedowierzaniem patrze, że większość nie ustępuje oryginałom. Wiele bym dał aby obejrzeć to na oryginalnym atari.
Szczęśliwy jestem bom zobaczył tą nowinkę jako jeden z pierwszych:)
luka 2008-09-24 01:04:56
ooo, tu jest o tym, chyba jest to dosyć sensowne
http://atariarea.krap.pl/forum/viewtopic.php?id=5688
sikor 2008-09-24 08:04:13
Ładne, ładne... I zacne. JAk pisałem na forum - potrzebujemy kolejny katalog u KAZa. Należy już wyodrębnić emulatory - bo w sumie to też taki emulator, tylko tyle, że grafiki...
Gratulacje dla MONO!!!
pavros 2008-09-24 09:46:25
luka: Dzięki za przypomnienie tematu. Właśnie sam to chciałem uczynić. Dodam tylko, że schemat urządzenia już istnieje, a Zenon/Dial pracuje nad budową prototypu.
irwin 2008-09-24 09:50:35
No jak dla mnie BOMBA! jak to swego czasu powiedział kolega Nobla widząc jego prezentację dynamitu ;-)
Mam takie pytanie - czy sam algorytm tej konwersji dałoby się zaprząść do programu... Graph2Font Tebe'go? Program pozwalałby wtedy na wczytanie 16 kolorowego bmp a nowa metoda wynikła z algorytmu, sama poustawiała by sprity. Kaz, Tebe - dałoby się?
Kaz 2008-09-24 10:03:45
Pavros - bardzo sie ciesze, ze prace nad rozszerzeniem postepuja. A udalo sie tez namowic Electrona na implementacje w VBXE? Bo on chyba wlasnie konczy prace nad rdzeniem, wiec chyba jest najlepszy moment. I ustalcie jakas nazwe dla rozszerzenia, zeby latwiej sie o nim dyskutowalo. Widzialem, ze uzywa sie "ikplus", ale czy to oficjalna nazwa? :)
Irwin - to nie pytanie do mnie czy TeBe, raczej do Mono (czy chcialby przepisac program z Atari na PC). Moze to nawet istniec jako osobny konwerter, niekoniecznie w G2F.
irwin 2008-09-24 10:14:14
Racja, tylko że w G2F taką grafikę możnaby poddać dalszej obróbce już ręcznej. Tym sposobem dzięki kombinacji alogrytm/konwersja Mono+G2F Tebe dostalibyśmy znakomite narzędzie do malowania, konwersji obrazków.
Kaz 2008-09-24 10:20:21
Ale jedno nie wyklucza drugiego - konwerter nie musi byc wbudowany w program G2F, moze zapisywac w formacie G2F (na przyklad sama warstwe duszkow - plik PMG).
Twoj pomysl jest bardzo dobry - pozwoli miec juz gotowa podkolorowanie, w ktorej bedzie mozna sie skupic tylko na szczegolach, zeby je dopiescic.
pavros 2008-09-24 10:27:31
Kaz: Rozmawialem z Electronem wstępnie w Głuchołazach i nie miał on raczej nic przeciwko. Skontaktuję się z nim w takim razie na dniach. Co do nazwy, to najciekawsza, jaką udało mi się wymyslić to "Fade to black" czyli "ściemnij do czarnego". Fraza ta, odnosząca się do regulacji odbiornika TV, jest dość chwytliwa i była wielokrotnie wykorzystywana (utwór Metallic[k]-i, tytuł gry komputerowej). Dlatego sądzę, że będzie łatwa do zapamiętania. Ja proponuję używać jednego ze skrótów: FTB, F2B albo po prostu FADE. Zarówno dla nazwy nowego trybu graficznego jak i samego rozszerzenia.
irwin 2008-09-24 10:31:26
Tak też można by to zrobić, masz całkowitą rację. Ewentualnie w takim konwerterze byłaby opcja zapisywać w *.g2f (oczywiście za zgodą tebe)
Ponadto jak czytam Mono usiłuje na Atari wszystko zoptymalizować, to jasne - w końcu na realnym Atari chcąc grać w gry Zx taka konwersja musi być szybka. Może miał jakiś pomysł który zarzucił właśnie z uwagi na szykość. Na PC nie ma tych ograniczeń, może skorzystać z jakiejś dokładniejszej i czasochłonej wersji swojej metody - wszak tu nie musimy martwić się o szybkość, a o jakość.
Ponadto2 - można spróbować tej zadaptować tę metodę nie tylko na trybie Hires ale i 160xXXX.
MDW 2008-09-24 11:03:57
Rety, co się dzieje z tym Atari... Normalnie sto razy lepiej niż w czasach świetności małego Atari. Jestem pełen podziwu. Chylę czoła przed takimi ludźmi.
Kaz 2008-09-24 11:11:08
To moze po prostu Fader. Albo Black Fader - to juz znaczeniowo nie to samo, ale za to latwiej sie wymawia :).
irwin - z tego co wiem to Mono chce zrobic co najmniej dwie wersje konwersji - szybką i mniej dokladną oraz wolną i bardziej dokladna.
Kaz 2008-09-24 11:12:11
MDW - czasy swietnosci Atari dopiero nadchodza :)
irwin 2008-09-24 11:17:47
np Mono pisze: "Optymalizacje te nie są pełne, tzn. nie są testowane wszystkie kombinacje (co niestety ogromnie spowolniło by algorytm)." Na PC w konwerterze, czas nie grałby roli i efekty konwersji myślę że byłby nawet lepsze (a i tak chylę czoła na to co widzę powyżej) Jeśliby Mono/Tebe/ktokolwiek zrobiłby taki konwenter (algorytm już jest a to w sumie najważniejsze) to byłaby super sprawa, SUPER BOMBA ;-)
bob_er 2008-09-24 11:21:09
ja troche pomarudze :P
podkolorywanie atarowskiego hi-resu roznymi kolorami wg mnie wyglada strasznie. ni z gruchy, ni z pietruchy pojawiaja sie jakies kosmiczne kwadraty. takie cos trzeba bardzo umiejetnie stosowac (np. logo na srodku ekranu na stronie tytulowej w grze vicky - chyba z copyrightem lub w sposob, ktory robi to graph2font - ale tam cala moc proca na to idzie).
o wiele lepiej to wyglada, jesli sie robi to tym samym kolorem, ale inna jasnoscia. wtedy kwadraty znikaja i mamy 3-kolorowy (lub 3-jasnosciowy jak kto woli) hires. takie cos mozna robic dynamicznie, i lepiej to wyglada (imho).
irwin 2008-09-24 11:33:31
@Bob_er - no każdy ma inny gust, mnie akurat się podoba, bo po pierwsze bo wszyscy znamy ograniczenia Atari i cudów na miarę grafiki z Amigi oczekiwać nie należy, a po drugie to jak sam autor pisze nie jest jeszcze ostatnie słowo.
@Kaz, @Mono - sam konwerter nie musiałby być jakiś super wypasiony, może na początek prosty, z komendami w wierszu poleceń, w sumie chodzi tylko oto aby zapisał grafikę do *.g2f lub jak Kaz pisze do *.pmg . Ewentualnie jakby doszło do porozumienia na linii Mono-Tebe ;-) - jako dodatkowy, wybieralny w opcjach programu Graph2Font, nowy tryb konwersji.
Kaz 2008-09-24 11:34:58
irwin - tyż racja.
bob_er - oczywiscie, ze najlepsza jest reczna, dokladna konwersja, ale to jest automat do konwersji, wiec trudno wymagac, zeby decydowal co jest na obrazku wazniejsze :). No chyba, zeby Mono wprowadzil jakies metody heurystyczne do oceny obrazka albo sztuczna inteligencje :).
Pomysl ze zmiana jasnosci jest jednak zacny - taka opcja tez byla by fajna! Mono, co Ty na to?
pavros 2008-09-24 11:39:45
Kaz: Fader albo Black Fader - może też tak być. Albo Color Fader. Nazwa w tym stylu jest może rzeczywiście bardziej adekwatna, bo w sumie to jest bardziej funkcja niż samodzielny tryb graficzny. Funkcja, która może być zastosowana do każdego trybu graficznego, choć nie w każdym ma sens.
Sprawdziłem w słowniku:
Fader - tłumik; regulator, potencjometr funkcji fade
Black fader - ściemniacz w kamerze [TV]
Kaz 2008-09-24 11:43:39
To ja jestem za Color Fader (CFR) - bo w koncu tak to chyba dziala :).
pavros 2008-09-24 12:28:12
Dokladnie. To rozszerzenie jest "tłumikiem koloru" sterowanym luminancją. BTW Email do Electrona już poszedł.
mono 2008-09-24 15:42:46
@luka, @nosty: Bardzo fajnie, że poruszyliście sprawę rozszerzenia zaproponowanego przez pavros'a na atariarea. Tablica mapowania kolorów w moim programie wygląda tak:
; mapowanie kolorow zx spectrum
colmap equ *
dta b($00) ;czarny
dta b($82) ;niebieski
dta b($22) ;czerwien
dta b($44) ;fiolet
dta b($c4) ;zielony
dta b($a8) ;b($98) ;blekitny / turkusowy
dta b($ea) ;ciemny zolty/oliwkowy
dta b($08) ;jasny szary
dta b($02) ;szary
dta b($84) ;jasny niebieski
dta b($24) ;jasny czerwien
dta b($36) ;rozowy
dta b($ca) ;jasna zielen
dta b($ae) ;b($9a) ;jasny blekit / jasny turkusowy?
dta b($ee) ;zolty
dta b($0e) ;bialy
Jak widać luminancję $x0 posiada tylko kolor czarny, więc i modyfikacja pavros'a nie kolidowałaby z niczym. Tablica nie jest finalna, ale subiektywnie najlepsza, jaką udało mi się na emulatorze atari800 uzyskać. Jeśli ktoś potrafi ją poprawić i wierniej dobrać kolory, jest mile widziany :)
Tak w ogóle, to tryb pavrosa daje nam możliwości kolorystyczne zbliżone do Commodore 16 (112 kolorów i 16 czerni) więc może pokusić się o konwersję z c16? :).
Wiem, że wbiję kij w mrowisko, ale ciekawi mnie jak bardzo pracochłonne byłoby stworzenie przystawki umożliwiającej ustawienie dowolnej palety kolorów na oryginalnym Atari? I na ile rozwiązanie zbliżyłoby się kosztem i ceną do vbxe. Być może jest to niemożliwe bez konstruowania vbxe, bo przecież informacje o kolorach są pobierane z wewnętrznych rejestrów gtia... Ale taka przystawka pozwalałaby na uzyskanie normalnego czerwonego, soczystego zielonego, i in. kolorów, które ma ZX Spectrum a nie mamy my.
@irwin: Jeśli chodzi o integrację z g2f nie widzę problemów innych niż moja ignorancja w progamowaniu w Delphi (o ile wiem g2f jest napisany w obiektowym pascalu?), którego po prostu nie znam :( Najbliższy mi język programowania wysokiego poziomu to Java (może być też C++) i w nim mogę zrobić odpowiedni konwerter (tak zresztą miało być na początku, ale zarzuciłem pomysł kiedy usiadłem przy Atari :D). Niezależnie jednak od tego do konwertera będą dostępne źródła (xasm), więc jeśli ktoś będzie chciał go wykorzystać/poprawić/coś dodać może czuć się wolny.
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. Trzeba by to przemyśleć.
Jakkolwiek konwerter nie jest jeszcze skończony i myślę, że mowa o integracji z czymkolwiek, albo w ogóle o jakimś sensownym wykorzystaniu go jest jeszcze przedwczesna.
@bob_er: Podkolorowywanie hiresu wygląda strasznie. Niestety. Winne są przebarwienia i gdyby to u nas działało, jak na Spectrumie nie byłoby problemu. Myślę jednak, że korzyść z posiadania mapy kolorów w hiresie jest na tyle duża, że można przymknąć oko na te ograniczenia (ja przymykam) :) Nie jestem niestety w stanie wyeliminować tych przebarwień na stock Atari.
Jeśli zaś chodzi o kwadraty, które pojawiają się w różnych miejscach - technika wykorzystywana przeze mnie polega na określeniu, który kolor jest najczęściej użyty w wierszu i ustaleniu koloru tła COLPF2. Rzadziej wykorzystywane kolory są podkładane sprajtami. Jeśli gdzieś w takim wierszu mam cały kwadrat czarny, nie podkładam tam nic, a jedynie wypełniam go kolorem znaku COLPF1, który ma zawsze jasność ustawioną na $x0. Niestety przebarwienie powoduje, że taki kwadrat jest zielony, lub niebieski, albo purpurowy zależnie od tego jaki kolor dominuje w wierszu. Jeśli przy takim kwadracie znajdzie się sprajt, to efekt jest nieładny :( Może przy innym algorytmie uzyskalibyśmy lepszy efekt, ale mogłoby zabraknąć sprajtów (często i tak już teraz ich brakuje). Efekt działania algorytmu oglądany na emulatorze wygląda niestety źle. Widzieliśmy te obrazki z Yerzmyey'em na tv (crt) i ja tych przebarwień nie widziałem (!). Może to specyfika Yerzmyey'owego tv, może na lcd tv, albo na monitorze kolorowym znowu przebarwienia będą. Nie mam zielonego pojęcia, bo do oryginalnego Atari sam posiadam tylko monitor mono.
Pomysł z 3-jasnościowym hiresem jest bardzo dobry. Gdyby zastosować jeszcze nakładanie sprajtów dałoby się uzyskać 4 poziomy szarości, a to już chyba nie najgorzej. Policzmy: 2 jasności COLPF1/2, 4 sprajty (player+missiles) + nakładanie, 5 player; to nam daje 7/8 odcieni w wierszu. Bez przebarwień.
Bardzo twórcza dyskusja :)
mono 2008-09-24 15:50:20
Commodore 16 ma oczywiście 121 kolorów (8 czerni liczy się za 1 kolor).
irwin 2008-09-24 17:05:37
@Mono - dzięki za wyjaśnienie, a więc sumując: taki konwerter na PC jest możliwy, i do tego będzie po tych zmianach co powyżej piszesz produkował jeszcze lepszą konwersję sprajtów. I będzie możliwość pracy w trybach 160px. No czegóż chcieć więcej! - Oj Kaz ma rację pisząc powyżej: "czasy swietnosci Atari dopiero nadchodza :)"
O szybkość pracy rozbudowanego algorytmu tu się raczej nie ma co się martwić - wszak zamiast 1.79mhz na piecykach mamy czasem i 1ghz (choć u mnie jedynie 600mhz)
Tak więc pozostaje jedynie dopingować Cię do jak najszybszego zakończenia prac a nie tylko emumaniacy ;-) ale i graficy a w domyśle wszyscy atarianie ;-) z tego skorzystają.
tebe 2008-09-24 20:04:12
przebarwienia w HiRes są widoczne jeśli kolor tła <> koloru ducha/pocisku, jeśli jest równy wówczas nie będzie widać przebarwień, chęć usunięcia przebarwień ograniczy nas wówczas tylko do używania jasności
w formacie G2F czy innym skojarzonym z G2F można zapisywać bez potrzeby pytania mnie o zdanie, jeśli tylko ktoś czuje się na siłach aby zmierzyć się z takim plikiem, taki plik PMG dla G2F to nie są dane które wczytuje się do Atari
GTIA generuje kolory na podstawie opóźnień czasowych, bez przebudowania wewnętrznej struktury układu GTIA nie da sie uzyskać innych kolorów (potrzebne informacje można znaleźć w dokumentacji układu GTIA), ogólnie sprawa sprowadza się do VBXE
bob_er 2008-09-24 22:17:18
jak wyglada 3-jasnosciowy hires mozna zobaczyc pod koniec dema 'unfused' - ostatnia kolorowa akcja. sa tam 2 rozne patterny na znakach oraz dynamicznie generowanych sprite'ach (kolor tla+kolor fontow+kolor sprite'ow).
andygroo 2008-09-27 01:39:16
no wlasnie tu jest przyklad braku nasycenia kolorami waszego komputerka...boze co oni wam zrobili...nie idzie w jakis prosty sposob naprawic to u was? pomijam regulacje tv.... gdzie tkwi blad konstrukcyjny???? skad taki rozklad kolorow... naprawde to powazna wada i nie mial tego chyba zaden innym komputer domowy
Kaz 2008-09-27 18:53:43
Z mojego punktu widzenia to barwy Spectrum sa przejaskrawione... boze co oni wam zrobili? :) Nie, no sorki, ale o mowienie, ze kolory Atari czy Commodore maja "wade" w porownaniu ze Spectrum to troche.. teges :).
sikor 2008-09-27 21:36:47
Co do kolorystyki - rzecz gustu. W Atari naprawdę można wyregulować dobrze kolory - i nie chodzi tu o telewizor/monitor, jest taki mały potencjometr... Brak czerwonego? Nie zauważyłem, może za krótko używam Atari (hmm, chyba od 1987 roku), ktoś mi mówił, że nie ma. Może mam uszkodzony egzemplarz, nie wiem - w moim jest ;) Dla mnie kolory na ZX są za jaskrawe (działają na mnie jak interlejs albo i gorzej), ale i tak część grafik mi się podoba. Wykorzystanie zbyt wielu kolorów czasem zaciemnia rzecz, nawet w grach (niektóre w C64). Nie podobają mi się atrybuty na ZX-sie (te kwadraty przy postaciach), w Atari tego nie ma.
Co powiedzieć? Każdy komputer ma swoje wady i zalety, ja tam swoje małe Atari lubię i przy nim pozostanę.
mono 2008-09-28 01:31:55
O ile się orientuję, na C64 były podobne tonacje. Wezmę jednak trochę w obronę moje Atari. Mamy 128 kolorów dostępnych naraz na ekranie (na podobnej zasadzie posiadacze C16 mieli 121 kolorów). W niektórych trybach dostępne jest 2x więcej a więc 256. Bez interlace! To jest 16 kolorów po 8 lub po 16 odcieni. Dzięki temu w zasadzie nie ma problemu z dobraniem kolorystyki przy portowaniu gier. ALE...! Ale faktycznie w dostępnej palecie nie mamy dostępnych niektórych chrominancji... :( jeśli chodzi o paletę to Kaz ostatnio pokazywał jak wygląda (http://atarionline.pl/v01/index.php?subaction=showfull&id=1218504159
&archive=&start_from=&ucat=1&ct=nowinki); tutaj (http://en.wikipedia.org/wiki/MOS_Technology_TED) jest za to paleta C16 - można porównać. Generalnie moim zdaniem - tak - nie mamy nasyconych kolorów (ta Spectrumowska czy BBC'owska czerwień!). Ale nie zielonego :) Zielonych akurat mamy chyba ze 3. Mamy też morski (navy), parę niebieskich, żółty, brąz i inne. Zapraszam na strony z paletami dla porównania. Za to VBXE (jak któryś z przedmówców wspomniał) rozwiązuje te problemy :)
Kaz 2008-09-28 12:31:51
Na ostatnim KWAS-ie byl moj XEGS z VBXE podlaczony do telewizora przez RGB (dzieki Electron!). Kolorki swietne, obraz jak brzytwa, sa swiadkowie.
homek 2008-09-28 15:16:14
jehowy? ;-]
Kaz 2008-09-28 17:10:12
Dla krytykantow palety Atari proponuje nastepujacy eksperyment naukowy: jesli masz Spectrum - napisz na nim program konwertujacy cala palete kolorow z Atari i pokaz nam efekty. To samo proponuje na Commodore, Amstradzie, BBC i innych komputerach 8-bitowych. Wtedy porownamy wady i zalety kolorow, moze sie nawet wspolnie posmiejemy :)
José Pereira 2009-07-08 20:17:56
What hapen?
Something was done? Any code?
Can I contact the author?
Thanks.
José Pereira
Kaz 2009-07-09 17:14:54
As far as I know, Spektroskop is still under development. Code is not available (yet?). Mono is the author, ask question to him by forum, more people is interesting in answers :).
Kaz 2009-07-10 13:00:12
Mono wrote that one point from his to-do list had left to do. He will try to finish it during or after his holiday he just started today :).
José Pereira 2009-07-10 23:31:21
Many thanks.
Hope he finish the project soon.
Congratulations to him.
Bye.
José Pereira.