HIP: Różnice pomiędzy wersjami

Z Atariki
Przejdź do nawigacji Przejdź do wyszukiwania
← poprzednia edycja

Mono (dyskusja | edycje)

2792 edycje
Nie podano opisu zmian
Mono (dyskusja | edycje)
2792 edycje
m linki i formatowanie
 
(Nie pokazano 20 wersji utworzonych przez 6 użytkowników)
Linia 1: Linia 1:
<pre>  
[[grafika:Hip_16k-tro.png|przykładowy obrazek w trybie HIP]]
<br>


1. What is HIP?


HIP is a new method to displaing pictures on small atari...
==Co to jest HIP ?==
HIP stands for HARD-Interlacing-Picture and was found by
Members of HARD Software, Hungary in June, July 1996...
It enables to display 160 x 240 Pixels with 30 shades without
nearly all flickering (depends on the source-picture you use)...
HARD stands not for HARD or HEAVY Interlacing, just for the
inventors...
2. The History of HIP
Tamas Bene and I had a "EMail"-conversation the last few month and
we were talking about older demos and effects and suddenly we
have talked about the Visdowm II-Demo of JAC! where JAC had
managed to display 16 colors/shades in a resolution of Gr.15, which
means 160x200... We talked about the "unity"-demo where Our-5oft
switched 3 graficmodes in 1 scanline,
gr.8,gr.9 and somehthing similar to gr.15 by altering the prior-
register per DLI... what do you think happens when
writing #0 in that register at the beginning of a scanline, waiting
some time... switching to gr.9 by writing #$40 there and after
a little while in the last 1/3 of the scanline back to gr.0 by
writing again #0 into it... what does the GTIA produce?
not gr.0 (or gr.8...)as normaly... he displays something similar to gr.15!!!
He then told me some stories of the coding-sessions of "Joyride" last summer
and in the DIL-Plasma-Screen they discovered another "BUG"...but
Tamas had written down the FX and had forgot it... till we were
taking about GTIA-BUGs...
so we talked now about known GTIA-Bugs and the next day Tamas was
upset and told me he had discovered a new bug and he had reproduced the
DIL-"BUG"... he discovered that some scanlines were shifted by
a half (!) gr.9-pixel when the scroller starts and they didnt fixed
that BUG in the DIL-Screen...
But after reproducing this BUG he discovered that the reason wasnt the
scroller... it was the special display-list-routine...
3. Technical Infos conc. HIP
The basic idea is that all gr.10-lines were shifted by a half
color-clock (or pixel) by the GTIA and that always!!!! but noone
has ever tried to combine gr.9 and gr.10...
all have combined gr.9 (16 shades) and gr.11 (16 colors) to display
256 different colors (like in APACview)... but the resolution
was still 80x200...
So here is a ASCII-Description of the basic idea:
This is the combinations which are needed for the gr10-line and the
gr9-line to display the wanted HIP-color:


GR10 :000 000 000 222 222 222 222 444 444
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&times;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.
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


==Historia HIPa według [[Heaven]]a/[[Taquart]]==


GR10 :444 444 666 666 666 666 888 888 888
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&times;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.
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


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!!!


GR10 :888 aaa aaa aaa aaa ccc ccc ccc ccc
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.
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


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]].


GR10 :eee eee eee
==Techniczne informacje o HIP==
GR09 :ddd eee fff
HIP :d.5 e.0 e.5


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&times;200 pikseli.


and viola... here are 30 possibilites of shades...
Tutaj znajduje się wytłumaczenie podstawowego pomysłu.
Our eyes are averaging the two luminance-values by
 
interlacing the two lines each vbi.
Oto kombinacje, które są potrzebne do łączenia linii trybu grafiki 9 z 10, w celu wyświetlenia pożądanego koloru HIP:
---
 
but attention... in gr10 it is possible to select each
<pre>
of the xl color registers (704-712), so in the display-
GR10: 000 000 000 222 222 222 222 444 444
routine and the display-list-interrupt the color-registers
GR09: 000 111 222 111 222 333 444 333 444
have to be set in a correct way!!!!
HIP : 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0
 
so if you look in the above table the values mean the xl-luminance!!!
GR10: 444 444 666 666 666 666 888 888 888
example:
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
if we want to display HIP-color 6.5 then we have to set in the
 
gr.9-line the value 7 (in basic by color 7 plot x,y)
GR10: 888 aaa aaa aaa aaa ccc ccc ccc ccc
for the gr10-line there is the value 6 but... it would be
GR09: aaa 999 aaa bbb ccc bbb ccc ddd eee
wrong to set the pixel by color 6... coz. we have just 8 color-registers
HIP : 9.0 9.5 a.0 a.5 b.0 b.5 c.0 c.5 d.0
in gr10... so what about setting the color-registers
 
in the following way???
GR10: eee eee eee
   
GR09: ddd eee fff
704 = 0
HIP : d.5 e.0 e.5
705 = 0
</pre>
706 = 2
 
707 = 4
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.
708 = 6
 
709 = 8
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!
710 = 10
 
711 = 12
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:
712 = 14
 
  704 = 0
so... if we want luminance 6 then we have to set the pixel by
705 = 0
color 4:plot x,y !!!!!!! in gr.10 the pixel-value selects the
706 = 2
color-register!!! an empty/black pixel is not set by color 0 !!!
707 = 4
color 0 says to the gtia "put the pixel with the color which
708 = 6
is defined by color-register 704" !!! so if you have put 0 in 704
709 = 8
there will be a black-pixel visible...
710 = 10
711 = 12
But in gr.9 we can`t set 14 in 712 coz. in gr.9 register 712 defines
712 = 14
the basic-color... so if we want 30 grey-shades... we have to put
 
0 there... but in gr.10 there must be 14 there... hmmm... the solution
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!
is a special DLI and Display-Lists...
 
   
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.
1. vbi   2. vbi
 
   
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.
DList1   DList2
 
   
Rozwiązaniem jest specjalne przerwanie [[DLI]] i Display Lista.
gr9 (0)   gr10(0) dli-bit set
 
gr10(1)   gr9 (1)
<pre>
gr9 (2)   gr10(2) dli-bit set
  1. vbi 2. vbi
gr10(3)   gr9 (3)
 
gr9 (4)   gr10(4) dli-bit set
  DList1 DList2
...       ...
 
  gr9 (0) gr10(0) dli-bit ustawiony
(x) is the number of the scanline in each screen-ram...
gr10(1) gr9 (1)
gr9 (2) gr10(2) dli-bit ustawiony
so... if we loop this... we interlace between this two gr9 and gr10
gr10(3) gr9 (3)
screen-rams and we will have a hip-picture...but we have to set
gr9 (4) gr10(4) dli-bit ustawiony
the correct values in colbk $d01a (712, see above!!!)
...     ...
</pre>
 
(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).
 
<pre>
1. vbi      2. vbi
1. vbi      2. vbi
DLI1        DLI2
pha          pha
lda #$40    lda #$80  ; switching to correct gr-mode (gr9, gr10)
sta wsync    sta wsync
sta gtiamode sta gtiamode
lda #0      lda #14    ;setting correct background-color
sta $d01a    sta $d01a
lda #$80    lda #$40  ;switching to next gr.mode (see displaylist)
sta wsync    sta wsync
sta gtiamode sta gtiamode
lda #14      lda #0    ;and dont forget the background color!
sta $d01a    sta $d01a
pla          pla
rti          rti
so... this is the technique but there is a "big" problem by
converting pictures...in gr9/10 each pixel is 4 "bits" large or
a nibble and in a hip-pixel 2 of them (the overlaping ones...)
here an example:
gr.10: ..00002222...
gr.9 : 000022224444...
HIP  : ..00112233..
remember: GTIA shifts the gr10-lines by a half gr.10 pixel!!!
so... we will always track one half of the pixel-value to the next
hip-pixel... and this is the difficulty... the hip-colors are
NOT able to be set free!!! there are restrictions like the main one:
two following hip-pixels should not have a difference of their luminace
greater than 2 !!!! coz. then we could not set the right values and
the hip-pixel will begin to flicker!!!
Best way is to use digitised source-pictures with smooth luminance
for converting to hip-format... or raytraced stuff...
so try do code such a linear optimasation-algorithmus...
4. Converters:
they are avaible for the following systems:
unix  coded by Tamas Bene from HARD
PC    coded by Tamas Bene from HARD
Amiga coded and adapted by HEAVEN of Taquart
XL    my algorithmus, written by HEAVEN of Taquart
For Converting you need:
-one of the above converters
-a paint-program which can produce pictures in REAL greyscale and 64
colors in a size 320x200
I think the new version of the bmp2hip-pc-converter can handle
bigger sizes and more colors...
-the 320x200x64 picture must be saved in Windows-BMP format
-a transfer program to XL
-a HIP-display-routine on XL


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
</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).
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 [[Heaven]]a/[[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&times;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&times;200&times;64 musi być zapisany w formacie Windows-BMP
*program przenoszący dane na [[XL]]/[[XE]]
*procedurę wyświetlającą tryb HIP na XL
<pre>
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
</pre>


{{stub}}
[[Kategoria:Atari 8-bit]]
[[Kategoria:Atari 8-bit]]
[[Kategoria:Formaty plików]]
[[Kategoria:Formaty plików]]
[[Kategoria: Tryby graficzne]]

Aktualna wersja z 16 sie 2024, 09:00

przykładowy obrazek w trybie HIP


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
Źródło: „https://atariki.krap.pl/index.php?title=HIP&oldid=41675”