HIP
From Atariki
Wersja z dnia 08:51, 23 kwi 2006 Miker (Dyskusja | wkład) (→4. Konwertery:) ← Previous diff |
Aktualna wersja Mono (Dyskusja | wkład) (linki i formatowanie) |
||
Linia 1: | Linia 1: | ||
- | ==1. Co to jest HIP ?== | + | [[grafika:Hip_16k-tro.png|przykładowy obrazek w trybie HIP]] |
+ | <br> | ||
+ | ==Co to jest HIP ?== | ||
- | HIP jest nową metodą wyświetlania obrazków na małym Atari... | + | HIP jest metodą wyświetlania obrazków na małym Atari. HIP to skrót od "HARD-Interlacing-Picture" i został wymyślony przez członków grupy [[HARD]] Software z Węgier w czerwcu 1996 r. Umożliwia on wyświetlenie obrazka w rozdzielczości 160×240 [[piksel]]i w 30 odcieniach, prawie bez żadnego migania (zależy to od konkretnego obrazka, którego używasz). "HARD" nie oznacza "ostrego" albo "wielkiego" migotania obrazu, lecz chodzi tu o nazwę grupy, która wymyśliła ten tryb. |
+ | ==Historia HIPa według [[Heaven]]a/[[Taquart]]== | ||
- | HIP to skrót od "HARD-Interlacing-Picture" i został wymyślony przez członków grupy [[HARD]] Software z Węgier w czerwcu 1996 r. | + | Tamás Bene i ja prowadziliśmy "konwersacje internetowe" przez ostatnie kilka miesięcy i rozmawialiśmy o starszych demach i efektach w nich używanych. W pewnym momencie zaczęliśmy rozmawiać o demie "Visdom II" JAComo Leopardiego, gdzie JAC zdołał wyświetlić 16 kolorów/odcieni w rozdzielczości [[Graphics 15]], która oznaczała 160×200 pikseli. Rozmawialiśmy także o demie [[UNITY]], gdzie grupa [[Our 5oft]] przełączała trzy tryby graficzne w jednej linii ekranowej: [[Graphics 8]], [[Graphics 9]] i coś podobnego do Graphics 15, wykorzystując do tego zmienianie rejestru [[Rejestry GTIA#GTIACTL|GPRIOR]] ($D01B) w przerwaniu DLI. |
+ | Jak myślisz, co się stanie, jeśli wpiszesz #$00 w ten rejestr (GPRIOR) na początku wyświetlania linii ekranowej, odczekasz trochę czasu (procesora). przełączysz wyświetlanie na Graphics 9 przez wpisanie #$40 do GPRIOR i po krótkiej chwili, w 1/3 ostatniej części tejże samej linii ekranowej przywrócisz z powrotem tryb 8, wpisując do GPRIOR ponownie wartość #$00??? Co pokaże [[GTIA]]? Nie, nie grafikę 8 (lub [[Graphics 0]]) jak normalnie - GTIA wyświetli coś podobnego do trybu 15!!! | ||
+ | Tamás opowiedział mi trochę historii o sesjach kodowania do dema [[Joyride]], w których brał udział ostatniego lata (1995) i stwierdził, że razem z resztą HARD'u odkryli jeszcze jakiś dodatkowy błąd w procedurze plazmy, lecz on dokończył ten efekt i zapomniał o wykrytym błędzie, aż do naszej rozmowy o błędach układu GTIA. | ||
- | Umożliwia on wyświetlenie obrazka w rozdzielczości 160 x 240 pixeli w 30 odcieniach, prawie bez żadnego migania (zależy to od konkretnego obrazka, którego używasz)... "HARD" nie oznacza "ostrego" albo "wielkiego" migotania obrazu, lecz chodzi tu o nazwę grupy, która wymyśliła ten tryb... | + | Tak więc zaczęliśmy teraz rozmawiać o znanych błędach w GTIA. Następnego dnia Tamás był zdenerwowany, gdyż stwierdził, że odkrył nowy "bug" i odtworzył stary błąd w plaźmie z "Joyride". Odkrył on, że niektóre linie ekranowe ("scanlines") były przesunięte o pół(!) piksela trybu 9, gdy zaczynał się scroller i oni (HARD) nie poprawili tego błędu w plaźmie. Jednak po odtworzeniu tego błędu Tamás przekonał się, iż powodem błędu nie był scroller. Błąd tkwił w specjalnej procedurze [[ANTIC Display List|Display-Listy]]. |
+ | ==Techniczne informacje o HIP== | ||
+ | Podstawowym założeniem jest, że wszystkie linie trybu [[Graphics 10]] są przesunięte o połowę piksela (albo o tzw. [[cykl koloru]]) w prawo w stosunku do pikseli trybu 9. Nikt jednak nawet nie próbował połączyć trybu 9 z 10. Wszyscy łączyli tryb 9 (16 odcieni) z trybem 11 (16 kolorów), aby wyświetlić 256 różnych kolorów (tak jak to widać w np. [[APAC View]]). Lecz wtedy rozdzielczość wynosiła wciąż 80×200 pikseli. | ||
+ | Tutaj znajduje się wytłumaczenie podstawowego pomysłu. | ||
- | ==2. Historia HIPa według [[Heaven]]a/[[Taquart]]== | + | Oto kombinacje, które są potrzebne do łączenia linii trybu grafiki 9 z 10, w celu wyświetlenia pożądanego koloru HIP: |
- | + | ||
- | + | ||
- | + | ||
- | Tamas Bene i ja prowadziliśmy "konwersacje internetowe" przez ostatnie kilka miesięcy i rozmawialiśmy o starszych demach i efektach w nich używanych... W pewnym momencie zaczęliśmy rozmawiać o demie "Visdom II" JAComo Leopardiego, gdzie JAC zdołał wyświetlić 16 kolorów/odcieni w rozdzielczości [[Graphics 15]], która oznaczała 160 x 200 pikseli... Rozmawialiśmy także o demie [[UNITY]], gdzie grupa [[Our 5oft]] przełączała trzy tryby graficzne w jednej linii ekranowej: [[Graphics 8]], [[Graphics 9]] i coś podobnego do Graphics 15, wykorzystując do tego zmienianie rejestru [[GPRIOR]] ($d01b) w przerwaniu DLI... | + | |
- | + | ||
- | Jak myślisz, co się stanie, jeśli wpiszesz #$00 w ten rejestr ($d01b) na początku wyświetlania linii ekranowej, odczekasz trochę czasu (procesora)... przełączysz wyświetlanie na Graphics 9 przez wpisanie #$40 do GPRIOR i po krótkiej chwili, w 1/3 ostatniej części tejże samej linii ekranowej przywrócisz z powrotem tryb 8, wpisując do GPRIOR ponownie wartość #$00...??? Co pokaże [[GTIA]]? Nie, nie grafikę 8 (lub [[Graphics 0]]) jak normalnie... GTIA wyświetli coś podobnego do trybu 15!!! | + | |
- | + | ||
- | + | ||
- | + | ||
- | Tamas opowiedział mi trochę historii o sesjach kodowania do dema [[Joyride]], w których brał udział ostatniego lata (1995) i stwierdził, że razem z resztą HARD'u odkryli jeszcze jakiś dodatkowy błąd w procedurze plazmy, lecz on dokończył ten efekt i zapomniał o wykrytym błędzie... aż do naszej rozmowy o błędach układu GTIA... | + | |
- | + | ||
- | Tak więc zaczęliśmy teraz rozmawiać o znanych błędach w GTIA. Następnego dnia Tamas był zdenerwowany, gdyż stwierdził, że odkrył nowy "bug" i odtworzył stary błąd w plaźmie z "Joyride"... Odkrył on, że niektóre linie ekranowe ("scanlines") były przesunięte o pół(!) pixla trybu 9, gdy zaczynał się scroller i oni (HARD) nie poprawili tego błędu w plaźmie... Jednak po odtworzeniu tego błędu Tamas przekonał się, iż powodem błędu nie był scroller... błąd tkwił w specjalnej procedurze [[ANTIC Display List|Display-Listy]]... | + | |
- | + | ||
- | ==3. Techniczne informacje o HIP== | + | |
- | + | ||
- | + | ||
- | + | ||
- | Podstawowym założeniem jest, że wszystkie linie trybu [[Graphics 10]] są przesunięte o połowę tzw. cyklu koloru (albo o piksel) przez GTIA i to zawsze!!! Nikt jednak nawet nie próbował połączyć trybu 9 z 10... Wszyscy łączyli tryb 9 (16 odcieni) z trybem 11 (16 kolorów), aby wyświetlić 256 różnych kolorów (tak jak to widać w np. "APACview")... Lecz wtedy rozdzielczość wynosiła wciąż 80x200 pikseli... | + | |
- | + | ||
- | + | ||
- | + | ||
- | Tutaj znajduje się wytłumaczenie podstawowego pomysłu... | + | |
- | + | ||
- | + | ||
- | + | ||
- | Oto kombinacje, które są potrzebne do łączenia linii trybu grafiki 9 z 10, w celu wyświetlena pożądanego koloru HIP: | + | |
- | + | ||
<pre> | <pre> | ||
Linia 62: | Linia 43: | ||
</pre> | </pre> | ||
- | OK... Tutaj istnieje 30 możliwości odcieni. Nasze oczy "uśredniają" dwie wartości jasności dzięki wzajemnym przełączaniu dwóch linii (w trybach 9 i 10) podczas każdego przerwania VBI. Dlatego troszkę to miga... | + | OK. Tutaj istnieje 30 możliwości odcieni. Nasze oczy "uśredniają" dwie wartości jasności dzięki wzajemnym przełączaniu dwóch linii (w trybach 9 i 10) podczas każdego przerwania VBI. Dlatego troszkę to miga. |
- | + | ||
- | + | ||
- | + | ||
- | Ale uważajcie... w trybie 10 możliwe jest wybranie każdego z rejestrów kolorów (704-712), więc w procedurze wyświetlania obrazu w HIP, jak i w procedurze DLI, rejestry muszą być ustawione w prawidłowy sposób!!!!! | + | |
- | + | ||
- | + | ||
- | + | ||
- | Dlatego, jeśli patrzysz w powyższą tabelę, zauważ, że tamte liczby oznaczają wartości jasności w Atari!!! Na przykład jeśli chcemy wyświetlić kolor HIP o wartości 6.5, musimy wtedy ustawić linii trybu graficznego 9 wartość 7 (w Basicu przez komendy: color 7, plot x,y).... Natomiast dla linii trybu 10 jest wartość 6, ale... byłoby niewłaściwie ustawiać piksel kolorem 6, ponieważ mamy właśnie 8 rejestrów koloru w trybie 10... Co powiecie na ustawienie rejestrów koloru w następujący sposób: | + | |
+ | Ale w trybie 10 możliwe jest wybranie każdego z rejestrów kolorów (704-712), więc w procedurze wyświetlania obrazu w HIP, jak i w procedurze DLI, rejestry muszą być ustawione w prawidłowy sposób! | ||
+ | Dlatego, jeśli patrzysz w powyższą tabelę, zauważ, że tamte liczby oznaczają wartości jasności w Atari! Na przykład jeśli chcemy wyświetlić kolor HIP o wartości 6.5, musimy wtedy ustawić linii trybu graficznego 9 wartość 7 (w Basicu przez komendy: <code>COLOR 7</code>, <code>PLOT x,y</code>). Natomiast dla linii trybu 10 jest wartość 6, ale byłoby niewłaściwie ustawiać piksel kolorem 6, ponieważ mamy właśnie 8 rejestrów koloru w trybie 10. Co powiecie na ustawienie rejestrów koloru w następujący sposób: | ||
704 = 0 | 704 = 0 | ||
Linia 84: | Linia 59: | ||
712 = 14 | 712 = 14 | ||
+ | Jeśli chcemy jasność 6, musimy ustawić piksel kolorem 4: plot x,y! W Graphics 10 wartość piksela wybiera rejestr koloru! Pusty/czarny piksel nie jest ustawiany kolorem 0! | ||
- | Więc... Jeśli chcemy jasność 6, musimy ustawić piksel kolorem 4: plot x,y!!!! W Graphics 10 wartość piksela wybiera rejestr koloru !!!! Pusty/czarny piksel nie jest ustawiany kolorem 0!!! | + | Kolor 0 "każe" GTIA postawić piksel z kolorze, który jest zdefiniowany przez rejestr koloru 704!!! Jeżeli więc wstawisz 0 do rejestru 704, będzie tam widoczny czarny piksel. |
- | Kolor 0 "każe" GTIA postawić piksel z kolorze, który jest zdefiniowany przez rejestr koloru 704!!! Jeżeli więc wstawisz 0 do rejestru 704, będzie tam widoczny czarny piksel... | + | W trybie 9 nie możemy wstawić 14 do rejestru 712, ponieważ tu rejestr 712 definiuje podstawowy kolor. Dlatego jeśli chcemy 30 odcieni szarości, musimy wstawić tam wartość 0, lecz wtedy w trybie 10 musi być 14 w tym rejestrze. |
- | + | ||
- | + | ||
- | + | ||
- | W trybie 9 nie możemy wstawić 14 do rejestru 712, ponieważ tu rejestr 712 definiuje podstawowy kolor... Dlatego jeśli chcemy 30 odcieni szarości, musimy wstawić tam wartość 0... Lecz wtedy w trybie 10 musi być 14 w tym rejestrze... | + | |
- | + | ||
- | Hmmm... Rozwiązaniem jest specjalne przerwanie [[DLI]] i Display Lista... | + | |
+ | Rozwiązaniem jest specjalne przerwanie [[DLI]] i Display Lista. | ||
<pre> | <pre> | ||
Linia 109: | Linia 80: | ||
</pre> | </pre> | ||
+ | (x) jest numerem linii ekranowej w każdej (z dwóch) pamięci obrazu. | ||
- | (x) jest numerem linii ekranowej w każdej (z dwóch) pamięci obrazu... | + | Gdy zapętlimy to, to stworzymy interlace pomiędzy tymi dwoma pamięciami ekranowymi (w trybach 9 i 10) i zrobimy tym sposobem tryb HIP; lecz musimy ustawić prawidłowe wartości w rejestrze COLBAK $d01a (712, zobacz powyżej). |
- | + | ||
- | + | ||
- | + | ||
- | Gdy zapętlimy to... stworzymy interlace pomiędzy tymi dwoma pamięciami ekranowymi (w trybach 9 i 10) i zrobimy tym sposobem tryb HIP... lecz musimy ustawić prawidłowe wartości w rejestrze Colbk $d01a (712, zobacz powyżej!!!)... | + | |
- | + | ||
<pre> | <pre> | ||
Linia 146: | Linia 113: | ||
</pre> | </pre> | ||
- | To jest technika, lecz jest "duży" problem z konwertowaniem obrazków... W trybie 9/10 każdy piksel jest wielki na 4 "bity" lub tzw. "nibble", a piksel w HIP ma 2 "bity" (nakładane na siebie bity)... | + | To jest technika, lecz jest "duży" problem z konwertowaniem obrazków. W trybie 9/10 każdy piksel jest wielki na 4 "bity" lub tzw. "nibble", a piksel w HIP ma 2 "bity" (nakładane na siebie bity). |
- | + | ||
- | + | ||
Tutaj jest przykład: | Tutaj jest przykład: | ||
- | |||
- | |||
gr.10: ..00002222... | gr.10: ..00002222... | ||
Linia 158: | Linia 121: | ||
HIP : ..00112233.. | HIP : ..00112233.. | ||
+ | Pamiętaj: GTIA przesuwa linie trybu 10 o pół piksla w trybie 9/10! | ||
- | Pamiętaj: GTIA przesuwa linie trybu 10 o pół piksla w trybie 9/10!!! | + | Tak więc będziemy zawsze sprawdzać jedną połówkę wartości piksela aż do kolejnego piksela w trybie HIP. I to jest trudność, bo kolorów w HIP nie można ustawiać oddzielnie. Istnieją ograniczenia takie, jak to główne: |
+ | * dwa następujące po sobie piksele w HIP nie powinny mieć różnicy między ich jasnością większej od 2, ponieważ wtedy nie moglibyśmy ustawić prawidłowych wartości i piksel w HIP zacznie migać. | ||
+ | Najlepszą metodą (używania trybu HIP) jest wykorzystywanie jako źródła digitalizowanych obrazków z 'wygładzoną' jasnością do konwersji na format HIP, albo przekonwertowanie jakiś raytrace'owanych obrazków. | ||
- | Tak więc... będziemy zawsze sprawdzać jedną połówkę wartości piksela aż do kolejnego piksela w trybie HIP... I to jest trudność, bo kolorów w HIP nie można ustawiać oddzielnie!!! Istnieją ograniczenia takie, jak to główne: | + | Spróbuj zakodować odpowiedni algorytm optymalizacji dla konwersji na HIP. |
- | + | ||
- | - dwa następujące po sobie piksele w HIP nie powinny mieć różnicy między ich jasnością większej od 2!!! Ponieważ wtedy nie moglibyśmy ustawić prawidłowych wartości i piksel w HIP zacznie migać!!! | + | |
- | + | ||
- | + | ||
- | + | ||
- | Najlepszą metodą (używania trybu HIP) jest wykorzystywanie jako źródła digitalizowanych obrazków z 'wygładzoną' jasnością do konwersji na format HIP, albo przekonwertowanie jakiś raytrace'owanych obrazków... | + | |
- | + | ||
- | + | ||
- | + | ||
- | Spróbuj zakodować odpowiedni algorytm optymalizacji dla konwersji na HIP... | + | |
- | + | ||
- | ==4. Konwertery== | + | |
- | + | ||
+ | ==Konwertery== | ||
Są one dostępne dla następujących systemów: | Są one dostępne dla następujących systemów: | ||
- | + | *Unix - kodowany przez Tamása Benego z HARD | |
- | *Unix - kodowany przez Tamasa Bene z HARD | + | *PC - kodowany przez Tamása Benego z HARD |
- | + | ||
- | *PC - kodowany przez Tamasa Bene z HARD | + | |
- | + | ||
*Amiga - kodowany i przerobiony przez [[Heaven]]a/[[Taquart]] | *Amiga - kodowany i przerobiony przez [[Heaven]]a/[[Taquart]] | ||
- | |||
*XL - moje algorytmy, napisane przez Heavena/Taquart | *XL - moje algorytmy, napisane przez Heavena/Taquart | ||
- | |||
- | |||
Do konwertowania potrzebujesz: | Do konwertowania potrzebujesz: | ||
- | |||
- | |||
*jeden z powyższych konwerterów | *jeden z powyższych konwerterów | ||
- | + | *program graficzny, w którym można tworzyć obrazki w PRAWDZIWEJ skali szarości i 64 kolorach, w rozdzielczości 320×200 pikseli (myślę, że nowa wersja konwertera "bmp2hip" na PC będzie mogła 'obrabiać' większe rozdzielczości i więcej kolorów). | |
- | *program graficzny, w którym można tworzyć obrazki w PRAWDZIWEJ skali szarości i 64 kolorach, w rozdzielczości 320x200 pixeli (myślę, że nowa wersja konwertera "bmp2hip" na PC będzie mogła 'obrabiać' większe rozdzielczości i więcej kolorów...). | + | *obrazek 320×200×64 musi być zapisany w formacie Windows-BMP |
- | + | ||
- | *obrazek 320x200x64 musi być zapisany w formacie Windows-BMP | + | |
- | + | ||
*program przenoszący dane na [[XL]]/[[XE]] | *program przenoszący dane na [[XL]]/[[XE]] | ||
- | |||
*procedurę wyświetlającą tryb HIP na XL | *procedurę wyświetlającą tryb HIP na XL | ||
- | |||
- | |||
<pre> | <pre> | ||
CrEdItS: | CrEdItS: | ||
- | |||
- tekst: Heaven | - tekst: Heaven | ||
- | + | - algorytmy: Sanyi i Tamás z HARD Soft | |
- | - algorytmy: Sanyi i Tamas z HARD Soft | + | - procedura wyświetlania trybu HIP: Tamás z HARD Soft |
- | + | ||
- | - procedura wyświetlania trybu HIP: Tamas z HARD Soft | + | |
- | + | ||
- inspiracja: JAC! | - inspiracja: JAC! | ||
- | |||
- tłumaczenie z angielskiego wraz z dostosowaniem tekstu do EED: Dracon of TQA | - tłumaczenie z angielskiego wraz z dostosowaniem tekstu do EED: Dracon of TQA | ||
</pre> | </pre> | ||
- | |||
- | |||
[[Kategoria:Atari 8-bit]] | [[Kategoria:Atari 8-bit]] | ||
[[Kategoria:Formaty plików]] | [[Kategoria:Formaty plików]] | ||
+ | [[Kategoria: Tryby graficzne]] |
Aktualna wersja
Spis treści |
Co to jest HIP ?
HIP jest metodą wyświetlania obrazków na małym Atari. HIP to skrót od "HARD-Interlacing-Picture" i został wymyślony przez członków grupy HARD Software z Węgier w czerwcu 1996 r. Umożliwia on wyświetlenie obrazka w rozdzielczości 160×240 pikseli w 30 odcieniach, prawie bez żadnego migania (zależy to od konkretnego obrazka, którego używasz). "HARD" nie oznacza "ostrego" albo "wielkiego" migotania obrazu, lecz chodzi tu o nazwę grupy, która wymyśliła ten tryb.
Historia HIPa według Heavena/Taquart
Tamás Bene i ja prowadziliśmy "konwersacje internetowe" przez ostatnie kilka miesięcy i rozmawialiśmy o starszych demach i efektach w nich używanych. W pewnym momencie zaczęliśmy rozmawiać o demie "Visdom II" JAComo Leopardiego, gdzie JAC zdołał wyświetlić 16 kolorów/odcieni w rozdzielczości Graphics 15, która oznaczała 160×200 pikseli. Rozmawialiśmy także o demie UNITY, gdzie grupa Our 5oft przełączała trzy tryby graficzne w jednej linii ekranowej: Graphics 8, Graphics 9 i coś podobnego do Graphics 15, wykorzystując do tego zmienianie rejestru GPRIOR ($D01B) w przerwaniu DLI.
Jak myślisz, co się stanie, jeśli wpiszesz #$00 w ten rejestr (GPRIOR) na początku wyświetlania linii ekranowej, odczekasz trochę czasu (procesora). przełączysz wyświetlanie na Graphics 9 przez wpisanie #$40 do GPRIOR i po krótkiej chwili, w 1/3 ostatniej części tejże samej linii ekranowej przywrócisz z powrotem tryb 8, wpisując do GPRIOR ponownie wartość #$00??? Co pokaże GTIA? Nie, nie grafikę 8 (lub Graphics 0) jak normalnie - GTIA wyświetli coś podobnego do trybu 15!!!
Tamás opowiedział mi trochę historii o sesjach kodowania do dema Joyride, w których brał udział ostatniego lata (1995) i stwierdził, że razem z resztą HARD'u odkryli jeszcze jakiś dodatkowy błąd w procedurze plazmy, lecz on dokończył ten efekt i zapomniał o wykrytym błędzie, aż do naszej rozmowy o błędach układu GTIA.
Tak więc zaczęliśmy teraz rozmawiać o znanych błędach w GTIA. Następnego dnia Tamás był zdenerwowany, gdyż stwierdził, że odkrył nowy "bug" i odtworzył stary błąd w plaźmie z "Joyride". Odkrył on, że niektóre linie ekranowe ("scanlines") były przesunięte o pół(!) piksela trybu 9, gdy zaczynał się scroller i oni (HARD) nie poprawili tego błędu w plaźmie. Jednak po odtworzeniu tego błędu Tamás przekonał się, iż powodem błędu nie był scroller. Błąd tkwił w specjalnej procedurze Display-Listy.
Techniczne informacje o HIP
Podstawowym założeniem jest, że wszystkie linie trybu Graphics 10 są przesunięte o połowę piksela (albo o tzw. cykl koloru) w prawo w stosunku do pikseli trybu 9. Nikt jednak nawet nie próbował połączyć trybu 9 z 10. Wszyscy łączyli tryb 9 (16 odcieni) z trybem 11 (16 kolorów), aby wyświetlić 256 różnych kolorów (tak jak to widać w np. APAC View). Lecz wtedy rozdzielczość wynosiła wciąż 80×200 pikseli.
Tutaj znajduje się wytłumaczenie podstawowego pomysłu.
Oto kombinacje, które są potrzebne do łączenia linii trybu grafiki 9 z 10, w celu wyświetlenia pożądanego koloru HIP:
GR10: 000 000 000 222 222 222 222 444 444 GR09: 000 111 222 111 222 333 444 333 444 HIP : 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 GR10: 444 444 666 666 666 666 888 888 888 GR09: 555 666 555 666 777 888 777 888 999 HIP : 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 GR10: 888 aaa aaa aaa aaa ccc ccc ccc ccc GR09: aaa 999 aaa bbb ccc bbb ccc ddd eee HIP : 9.0 9.5 a.0 a.5 b.0 b.5 c.0 c.5 d.0 GR10: eee eee eee GR09: ddd eee fff HIP : d.5 e.0 e.5
OK. Tutaj istnieje 30 możliwości odcieni. Nasze oczy "uśredniają" dwie wartości jasności dzięki wzajemnym przełączaniu dwóch linii (w trybach 9 i 10) podczas każdego przerwania VBI. Dlatego troszkę to miga.
Ale w trybie 10 możliwe jest wybranie każdego z rejestrów kolorów (704-712), więc w procedurze wyświetlania obrazu w HIP, jak i w procedurze DLI, rejestry muszą być ustawione w prawidłowy sposób!
Dlatego, jeśli patrzysz w powyższą tabelę, zauważ, że tamte liczby oznaczają wartości jasności w Atari! Na przykład jeśli chcemy wyświetlić kolor HIP o wartości 6.5, musimy wtedy ustawić linii trybu graficznego 9 wartość 7 (w Basicu przez komendy: COLOR 7
, PLOT x,y
). Natomiast dla linii trybu 10 jest wartość 6, ale byłoby niewłaściwie ustawiać piksel kolorem 6, ponieważ mamy właśnie 8 rejestrów koloru w trybie 10. Co powiecie na ustawienie rejestrów koloru w następujący sposób:
704 = 0 705 = 0 706 = 2 707 = 4 708 = 6 709 = 8 710 = 10 711 = 12 712 = 14
Jeśli chcemy jasność 6, musimy ustawić piksel kolorem 4: plot x,y! W Graphics 10 wartość piksela wybiera rejestr koloru! Pusty/czarny piksel nie jest ustawiany kolorem 0!
Kolor 0 "każe" GTIA postawić piksel z kolorze, który jest zdefiniowany przez rejestr koloru 704!!! Jeżeli więc wstawisz 0 do rejestru 704, będzie tam widoczny czarny piksel.
W trybie 9 nie możemy wstawić 14 do rejestru 712, ponieważ tu rejestr 712 definiuje podstawowy kolor. Dlatego jeśli chcemy 30 odcieni szarości, musimy wstawić tam wartość 0, lecz wtedy w trybie 10 musi być 14 w tym rejestrze.
Rozwiązaniem jest specjalne przerwanie DLI i Display Lista.
1. vbi 2. vbi DList1 DList2 gr9 (0) gr10(0) dli-bit ustawiony gr10(1) gr9 (1) gr9 (2) gr10(2) dli-bit ustawiony gr10(3) gr9 (3) gr9 (4) gr10(4) dli-bit ustawiony ... ...
(x) jest numerem linii ekranowej w każdej (z dwóch) pamięci obrazu.
Gdy zapętlimy to, to stworzymy interlace pomiędzy tymi dwoma pamięciami ekranowymi (w trybach 9 i 10) i zrobimy tym sposobem tryb HIP; lecz musimy ustawić prawidłowe wartości w rejestrze COLBAK $d01a (712, zobacz powyżej).
1. vbi 2. vbi DLI1 DLI2 pha pha lda #$40 lda #$80 ; przełączenie na ; odpow. tryb Graphics ; (Graphics #9, Graphics #10) sta wsync sta wsync sta gtiamode sta gtiamode lda #0 lda #14 ; ustawienie odpow. ; koloru tła sta $d01a sta $d01a lda #$80 lda #$40 ; przełączenie na ; kolejny tryb Graphics ; (zobacz DispList) sta wsync sta wsync sta gtiamode sta gtiamode lda #14 lda #0 ; i nie zapomnij o ; kolorze tła ! sta d01a sta $d01a pla pla rti rti
To jest technika, lecz jest "duży" problem z konwertowaniem obrazków. W trybie 9/10 każdy piksel jest wielki na 4 "bity" lub tzw. "nibble", a piksel w HIP ma 2 "bity" (nakładane na siebie bity).
Tutaj jest przykład:
gr.10: ..00002222... gr.9 : 000022224444... HIP : ..00112233..
Pamiętaj: GTIA przesuwa linie trybu 10 o pół piksla w trybie 9/10!
Tak więc będziemy zawsze sprawdzać jedną połówkę wartości piksela aż do kolejnego piksela w trybie HIP. I to jest trudność, bo kolorów w HIP nie można ustawiać oddzielnie. Istnieją ograniczenia takie, jak to główne:
- dwa następujące po sobie piksele w HIP nie powinny mieć różnicy między ich jasnością większej od 2, ponieważ wtedy nie moglibyśmy ustawić prawidłowych wartości i piksel w HIP zacznie migać.
Najlepszą metodą (używania trybu HIP) jest wykorzystywanie jako źródła digitalizowanych obrazków z 'wygładzoną' jasnością do konwersji na format HIP, albo przekonwertowanie jakiś raytrace'owanych obrazków.
Spróbuj zakodować odpowiedni algorytm optymalizacji dla konwersji na HIP.
Konwertery
Są one dostępne dla następujących systemów:
- Unix - kodowany przez Tamása Benego z HARD
- PC - kodowany przez Tamása Benego z HARD
- Amiga - kodowany i przerobiony przez Heavena/Taquart
- XL - moje algorytmy, napisane przez Heavena/Taquart
Do konwertowania potrzebujesz:
- jeden z powyższych konwerterów
- program graficzny, w którym można tworzyć obrazki w PRAWDZIWEJ skali szarości i 64 kolorach, w rozdzielczości 320×200 pikseli (myślę, że nowa wersja konwertera "bmp2hip" na PC będzie mogła 'obrabiać' większe rozdzielczości i więcej kolorów).
- obrazek 320×200×64 musi być zapisany w formacie Windows-BMP
- program przenoszący dane na XL/XE
- procedurę wyświetlającą tryb HIP na XL
CrEdItS: - tekst: Heaven - algorytmy: Sanyi i Tamás z HARD Soft - procedura wyświetlania trybu HIP: Tamás z HARD Soft - inspiracja: JAC! - tłumaczenie z angielskiego wraz z dostosowaniem tekstu do EED: Dracon of TQA