1

Próbuję coś robić w kwestii przypomnienia sobie, jak się pisało w basic-u... No i padło na GR.12.

Z tym, że problem jest taki, że potrzebuję nie 5, a 10 kolorów - jak to w najprostszy sposób zrobić ?

Po tym co, przeczytałem w atariki i biorąc pod uwagę próby logicznego wyobrażenia sobie tego, wpadłem na to, że najlepiej by użyć duszków, ponieważ w tej rozdzielczości szerokość 1 px jest równa 1 cyklowi koloru, a więc wypisz-wymaluj 1:1 dla wykorzystania duszków!

Z tym, że jest problem... szerokość planszy, jaką potrzebuję to 128px, a duszki dają max 40px, w podwójnej szerokości 80... "milimetrów" braknie... (poczwórna odpada)

Czytałem o tym, jak idzie wykorzystywać DLI do skoku pod własną procedurę, czytełem też o tym, jak podkolorowywany jest obraz w G2F... czyli dało by się to zrobić - z tym, że o ile zmienianie rozdzielczości linii to dla mnie nie problem, to wywołanie procedury, która będzie wykonywać przerzucanie pozycji (i obszaru pamięci) duszków jest już makabrą :(

Ale naprowadźcie mnie, czy idę w dobrym kierunku: gdyby utworzyć kopię obrazu w postaci słupków (jak ta procedurka będzie już działać, to nie będzie z przerzucaniem tego najmniejszego problemu) zgodnie z przesunięciem początku każdej kolumny co 1 stronę pamięci, wówczas dodatkowy pięciokilowy blok pamięci powinien wystarczyć, by za pomocą duszków uzyskać dodatkowe 5 kolorów ?

Czy też jest jakiś "prostszy" sposób ? Nie wiem - w postaci dwóch kopii displaylist, czy zmianie wartości rejestru koloru w danym pikselu podczas tworzenia ekranu - coś w tym rodzaju ?

___
Press play on tape...

2 Ostatnio edytowany przez mono (2008-06-25 12:59:58)

Czy tych duszków potrzebujesz do obiektów ruchomych czy do statycznego tła?
Zauważ, że nawet przy poczwórnej rozdzielczości w poziomie pozycję sprite'a możesz ciągle ustalać z dokładnością do jednego piksela (tryb 12OS). Jeśli ustalisz priorytet ducha tak, że będzie on rysowany pod kolorami pola gry (czyli pod obrazem wyłączywszy tło czyli parę bitów 00), to stawiając piksele na obrazie możesz zasłonić część szerokiego piksela sprajta. Dzięki temu możesz sobie przykryć cały ekran (statycznie) lub mieć dodatkowe kolory dla programowego sprajta (bo pozycję szerokiego sprajta zmieniasz z precyzją cyklu koloru czyli piksela w OS12). Wyglądałoby to np tak:

5555  - jeden bit sprajta x4
0123 - zawartość znaczka

w efekcie dostajesz coś co wygląda na ekranie

5123

a więc piksel dodatkowego koloru 5 :) Sprajt jest w poziomie ustawiony tak, że jego piksele pokrywają się dokładnie ze znakami.
Oczywiście jeśli grafika wygląda tak:

5555  - jeden bit sprajta x4
0103 - zawartość znaczka

to dostaniesz

5153

a więc nie użyjesz tu koloru tła (00), bo przesłania go ciągle sprajt. Jeśli natomiast sprajta przesuniesz o piksel

     5555         - jeden bit sprajta x4
01030120 - zawartość dwóch znaczków

to wtedy w wyniku dostaniesz

01535120

ale część sprajta przesłoni wtedy następny tło następnego znaczka (pierwsza para bitów 00 z drugiego znaku została przesłonięta przez sprajta).
Dokładając kolejnego sprajta dostaniesz

   6666         - jeden bit sprajta x4
  5555         - jeden bit sprajta x4
01030020 - zawartość dwóch znaczków

dostaniesz

01535620

i tak aż do wyczerpania ilości dostępnych sprajtów. Missiles podlegają tym samym regułom a mają tylko mniejszą szerokość, ponadto możesz włączyć 5 playera co daje dodatkowy kolor na wszystkich missiles. Kolor ten brany jest z rejestru, jaki używany jest dla pary bitów 11 w znaku w inverse. Dzięki temu możesz mieć naraz widoczne kolory 3 i 4 np.

4444 - zawartość jednego bitu missile z włączonym 5 playerem
0123 - znak BEZ inverse

a na ekranie zobaczysz

4123

Nie używając missile w tym trybie lecz samego znaku w inverse miałbyś:

0124 - znak Z inverse

Można więc tutaj czarować do woli.
Na dli możesz też zmieniać priorytety sprities pozwalając na przesłanianie dodatkowo niektórych kolorów ekranu (nie tylko koloru tła - para bitów 00).
Jest to dość skomplikowane - to fakt, ale pozwala na uzyskanie pojedynczych pikseli dodatkowych kolorów na całkiem sporych obszarach ekranu. Stosując sprite'a w rozdzielczości x1 ten obszar gwałtownie się zredukuje, a co więcej żeby uzyskać dodatkowe kolory trzeba będzie multiplikować sprajty w każdej linii ekranu co oznacza zarżnięcie procesora. Trzeba też wziąć pd uwagę, że w trybie tekstowym cała pierwsza linia skaningowa praktycznie jest zablokowana na działania ANTIC'a i tam kolorów/pozycji nie przełączysz. W trybie graficznym zaś tracisz kolor dla znaków w inverse i możesz go uzyskać już tylko 5 playerem.

Można też prócz 5 playera włączyć nakładanie kolorów, wtedy jeśli sprajty nałożą się na siebie uzyskujesz kolor będący wynikiem wykonania funkcji bitowego OR na zawartości rejestrów kolorów dla odpowiednich sprajtów - dostajesz wtedy dodatkowy kolor, którego nie ma w żadnym rejestrze :)

Na koniec słownik:
duch/sprite - player lub missile
0..3 kolory znaku bez inverse
4 - kolor dla pary 11 znaku w inverse lub tzw. 5 playera
5..8 - kolory sprajtów

Wszystko to napisałem, żeby Cię przekonać jednak do użycia szerokich sprajtów :)
Technika prostsza, o której wspomniałeś, czyli migotanie dwoma displaylistami i bankami sprajtów ze zmianą kolorów na vblk/dli (jeśli masz wyłączone przepisywanie rejestrów cienii na vlbk, to przełączanie ekranów naprzemienne można zrealizować samą dlist rozkazem jvb - wtedy na dlist przepisujesz tylko kolory i pozycje sprities), ma tę wadę, że masz dwa razy więcej grafiki do kopiowania podczas animacji.

Na koniec drobna uwaga. ANTIC ma tylko 9 rejestrów kolorów co pozwala w trybach ANTIC'a uzyskać max 9 kolorów. Uzyskanie 10 kolorów jest możliwe albo:
- multipleksowaniem sprities w linii
- przełączaniem kolorów w linii
- włączeniem trybu nakładania kolorów GTIA.
Dwie pierwsze techniki zabierają masę czasu procesora - ostatnia przerzuca całą pracę na GTIA.

edit: ponieważ chcesz zastosować BASIC proponowałbym jednak coś co nie obciąży procesora, a więc faktycznie sprities (w takiej rozdzielczości, jaka Ci wystarczy z ewentualnym włączonym trybem 5 playera) i nakładaniem kolorów i priorytetami, tudzież zmianę kolorów/priorytetów/położenia na dli/vblk.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

3

Dzięki za rozbudowaną odpowiedź - no to wypisz-wymaluj pozostaje mi ostatnie rozwiązanie, jak "pikawka" z GTIA. Potrzebuję 10 kolorów statycznych (5 głównych i ich półcienie), a dzięki machaniu z DLI jak widzę będę mógł użyć swobodnie sprite'ów do obiektów ruchomych (potrzebuję aże dwa, czyli 4 sprite'y będą w sam raz)

___
Press play on tape...

4 Ostatnio edytowany przez maw (2008-06-28 23:55:16)

Hmm... czy jest ktoś, kto chce się podjąć wezwania i uzyskać (spróbować uzyskać) na szerokości 64 pix ((14+2)x4) 12 kolorów w linii+tło ? Na całej wysokości ekranu, czyli w bloku 16x120 komórek ? Może być na zawężonym ekranie...

//EDIT: podwaliny powyżej plus wykorzystanie duszków do podbicia kolorów przez Gorgha

___
Press play on tape...

5

moim zdaniem mozna cos podobnego zrobic na kilka sposobow, w zaleznosci od tego do czego jest to potrzebne, GTIA+duchy mogloby wygl. tak:
Ze sprajtow masz 5x8pix= 40pix+extra 8 z powielenia ducha=48pix w 6 kol.
W tle jest GTIA z 16 odcieniami lub 9 kolorami. Odpowienio nakladajac duchy na GTIA mozna na 64 pixach uzyskac 'prawie' gr.12 w duzej liczbie kolorkow.Caly myk to zrobic tak,zeby to sie wszystko wyrysowalo jak trzeba,a do tego trza by pokombinowac, ale w sumie to nie byloby jakos strasznie trudne.
Jak cos ruszysz z tym tematem to moge ze swojej strony dorzucic swoje marne (ale zawsze) trzy grosze.

6

Pomysł jest ciekawy. Ale co z rozdzielczością? Trzeba by uzyskać pełną rozdzielczość na tych 64px. Gdyby zdążyć z przesuwaniem sprajtów w linii i przesłanianiem kawałków pikseli trybu graficznego i zmianą kolorów sprajtów to by się mogło udać (a przynajmniej pozycje i kształt). Paradoksalnie to missiles byłyby tutaj chyba użyteczniejsze :) Ech - czemu to kolory i pozycje sprajtów w gtia nie są brane z banków...?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

7

Potrzebuję na szerokości dosłownie 64 pixeli mieć 12kolorów plus tło. Stosując multiplexing duszków w rozmiarze 1:1 trzeba by mieć dodatkowy blok pamięci 4KB, żeby móc powtórzyć wszystkie pięć naraz (przełączanie jest chyba najszybsze).

Zakładając, że do grafiki chcemy użyć dwa, to oznacza, że w realnym czasie trzeba by P0 i P1 przemieścić czterokrotnie - adres 0 PMG([PMB+0KB]),8+8 px, przesunięcie, zmiana adresu PMG (+1KB[PMB+1KB]), 8+8, przesunięcie, zmiana adresu PMG(+1KB[PMB+2KB]), 8+8,  przesunięcie, zmiana adresu PMG (+1KB[PMB+3KB]) - ale to nam daje dodatkowy kolor, tak ?

Gdyby użyć bloku 8KB i nie wyłączać P2 i P3 na czas rysowania, tylko użyć ich także do  grafiki, to mamy 3 dodatkowe kolory ?

Zostają jeszcze missile, które gdyby miały w tym bloku 8KB poczwórnie zduplikowane dane, to spokojnie by posłużyły do obsługi czteropikselowego, dwukolorowego "gracza" i to by było wystarczające do bieżących potrzeb.

___
Press play on tape...