HIP: Różnice pomiędzy wersjami

Z Atariki
Przejdź do nawigacji Przejdź do wyszukiwania
← poprzednia edycjanastępna edycja →

Miker (dyskusja | edycje)

1 grupa użytkowników
4175 edycji
mNie podano opisu zmian
jednak zostawiłem text jak był - atakować! :
Linia 1: Linia 1:
{{SDP}}
==1. Co to jest HIP ?==


<pre>
1. What is HIP?


HIP is a new method to displaing pictures on small atari...
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 nową metodą wyświetlania obrazków na małym Atari...
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
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.
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


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


GR10 :eee eee eee
GR09 :ddd eee fff
HIP  :d.5 e.0 e.5




and viola... here are 30 possibilites of shades...
 
Our eyes are averaging the two luminance-values by
==2. Historia HIPa według [[Heaven]]a/[[Taquart]]==
interlacing the two lines each vbi.
 
---
 
but attention... in gr10 it is possible to select each
 
of the xl color registers (704-712), so in the display-
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...
routine and the display-list-interrupt the color-registers
 
have to be set in a correct way!!!!
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 Graphics 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 Graphics 15!!!
 
so if you look in the above table the values mean the xl-luminance!!!
 
example:
 
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 FX i zapomniał o wykrytym błędzie... aż do naszej rozmowy o błędach układu GTIA...
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)
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ół(!) pixela trybu Graphics 9, gdy zaczynał się scroller i oni (HARD) nie poprawili tego błędu w fx plazmy... Jednak po odtworzeniu tego błędu Tamas przekonał się, iż powodem błędu nie był scroller... błąd tkwił w specjalnej procedurze Display-Listy...
for the gr10-line there is the value 6 but... it would be
 
wrong to set the pixel by color 6... coz. we have just 8 color-registers
 
in gr10... so what about setting the color-registers
 
in the following way???
 
   
==3. Techniczne informacje o HIP==
704 = 0
 
705 = 0
 
706 = 2
 
707 = 4
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 Graphics 9 z Graphics 10... Wszyscy łączyli Graphics 9 (16 odcieni) z Graphics 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 piksli...
708 = 6
 
709 = 8
 
710 = 10
 
711 = 12
Tutaj znajduje się wytłumaczenie podstawowego pomysłu...
712 = 14
 
 
so... if we want luminance 6 then we have to set the pixel by
 
color 4:plot x,y !!!!!!! in gr.10 the pixel-value selects the
Oto kombinacje, które są potrzebne do łączenia linii Graphics 9 z 10, w celu wyświetlena pożądanego koloru HIP:
color-register!!! an empty/black pixel is not set by color 0 !!!
 
color 0 says to the gtia "put the pixel with the color which
 
is defined by color-register 704" !!! so if you have put 0 in 704
<pre>
there will be a black-pixel visible...
GR10: 000 000 000 222 222 222 222 444 444
GR09: 000 111 222 111 222 333 444 333 444
But in gr.9 we can`t set 14 in 712 coz. in gr.9 register 712 defines
HIP : 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0
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
GR10: 444 444 666 666 666 666 888 888 888
is a special DLI and Display-Lists...
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
1. vbi   2. vbi
 
   
GR10: 888 aaa aaa aaa aaa ccc ccc ccc ccc
DList1   DList2
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
gr9 (0)   gr10(0) dli-bit set
 
gr10(1)   gr9 (1)
GR10: eee eee eee
gr9 (2)   gr10(2) dli-bit set
GR09: ddd eee fff
gr10(3)   gr9 (3)
HIP : d.5 e.0 e.5
gr9 (4)   gr10(4) dli-bit set
</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 Graphics 9 i 10) podczas każdego przerwania VBI. Dlatego troszkę to miga...
(x) is the number of the scanline in each screen-ram...
 
 
so... if we loop this... we interlace between this two gr9 and gr10
 
screen-rams and we will have a hip-picture...but we have to set
Ale uważajcie... w Graphics 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!!!!!
the correct values in colbk $d01a (712, see above!!!)
 
 
 
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 Graphics 9 wartość 7 (w Basicu przez komendy: color 7, plot x,y).... Natomiast dla linii trybu Graphics 10 jest wartość 6, ale... byłoby niewłaściwie ustawiać piksel kolorem 6, ponieważ mamy właśnie 8 rejestrów koloru w Graphics #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
 
 
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...
 
 
 
W Graphics 9 nie możemy wstawić 14 do rejestru 712, ponieważ w Graphics 9 rejestr 712 definiuje podstawowy kolor... Dlatego jeśli chcemy 30 odcieni szarości, musimy wstawić tam wartość 0... Lecz wtedy w Graphics 10 musi być 14 w tym rejestrze...
 
Hmmm... Rozwiązaniem jest specjalne przerwanie DLI i Display Lista...
 
 
<pre>
  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
...     ...
</pre>
 
 
(x) jest numerem linii ekranowej w każdej /z dwóch/ pamięci obrazu...
 
 
 
Gdy zapętlimy to... stworzymy interlace pomiędzy tymi dwoma pamięciami ekranowymi (w Graphics 9 i Graphics 10) i zrobimy tym sposobem tryb HIP... lecz musimy ustawić prawidłowe wartości w rejestrze Colbk $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 Graphics 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 Graphics 10 o pół piksela w trybie Graphics 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...
==4. Konwertery:==
Są one dostępne dla następujących systemów:
*Unix - kodowany przez Tamasa Bene z HARD
*PC - kodowany przez Tamasa Bene z HARD
*Amiga - kodowany i przerobiony przez HEAVEN'a of Taquart
*XL - moje algorytmy, napisane przez HEAVEN'a of 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 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 320x200x64 musi być zapisany w formacie Windows-BMP
*program przenoszący dane na XL
*procedurę wyświetlającą tryb HIP na XL
<pre>
CrEdItS:
- tekst: Heaven
- algorytmy: Sanyi i Tamas z HARD Soft
- procedura wyświetlania trybu HIP: Tamas z HARD Soft
- inspiracja: JAC!
- tłumaczenie z angielskiego wraz z dostosowaniem tekstu do EED: Dracon of TQA
</pre>




[[Kategoria:Atari 8-bit]]
[[Kategoria:Atari 8-bit]]
[[Kategoria:Formaty plików]]
[[Kategoria:Formaty plików]]

Wersja z 9 kwi 2006, 19:24

1. Co to jest HIP ?

HIP jest nową 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 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...



2. Historia HIPa według Heavena/Taquart

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 Graphics 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 Graphics 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 FX 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ół(!) pixela trybu Graphics 9, gdy zaczynał się scroller i oni (HARD) nie poprawili tego błędu w fx plazmy... Jednak po odtworzeniu tego błędu Tamas przekonał się, iż powodem błędu nie był scroller... błąd tkwił w specjalnej procedurze 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 Graphics 9 z Graphics 10... Wszyscy łączyli Graphics 9 (16 odcieni) z Graphics 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 piksli...


Tutaj znajduje się wytłumaczenie podstawowego pomysłu...


Oto kombinacje, które są potrzebne do łączenia linii Graphics 9 z 10, w celu wyświetlena 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 Graphics 9 i 10) podczas każdego przerwania VBI. Dlatego troszkę to miga...


Ale uważajcie... w Graphics 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 Graphics 9 wartość 7 (w Basicu przez komendy: color 7, plot x,y).... Natomiast dla linii trybu Graphics 10 jest wartość 6, ale... byłoby niewłaściwie ustawiać piksel kolorem 6, ponieważ mamy właśnie 8 rejestrów koloru w Graphics #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


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


W Graphics 9 nie możemy wstawić 14 do rejestru 712, ponieważ w Graphics 9 rejestr 712 definiuje podstawowy kolor... Dlatego jeśli chcemy 30 odcieni szarości, musimy wstawić tam wartość 0... Lecz wtedy w Graphics 10 musi być 14 w tym rejestrze...

Hmmm... 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... stworzymy interlace pomiędzy tymi dwoma pamięciami ekranowymi (w Graphics 9 i Graphics 10) i zrobimy tym sposobem tryb HIP... lecz musimy ustawić prawidłowe wartości w rejestrze Colbk $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 Graphics 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 Graphics 10 o pół piksela w trybie Graphics 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...


4. Konwertery:

Są one dostępne dla następujących systemów:


  • Unix - kodowany przez Tamasa Bene z HARD
  • PC - kodowany przez Tamasa Bene z HARD
  • Amiga - kodowany i przerobiony przez HEAVEN'a of Taquart
  • XL - moje algorytmy, napisane przez HEAVEN'a of 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 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 320x200x64 musi być zapisany w formacie Windows-BMP
  • program przenoszący dane na XL
  • procedurę wyświetlającą tryb HIP na XL


CrEdItS:

- tekst: Heaven

- algorytmy: Sanyi i Tamas z HARD Soft

- procedura wyświetlania trybu HIP: Tamas 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=11675”