dwa ekrany obok siebie
zamiast przepisac, mozesz po prostu zmienic pointer poczatku wyswietlania, ten pointer musisz miec ustawiony co linie dlki
po przeskrolowaniu sie na drugi ekran, przepisujesz nowy ekran do tego co go nie widac i uaktualniasz pointer jeszcze raz
operacje mozna rozbic na pionowe paski, ktore spokojnie mozesz namalowac w ciagu ramki

tylko w prawo - majac 200 linii ekranu masz do przepisania 400 bajtow na ramke - to chyba sie da
w prawo i w lewo - bedzie 800 - nie znam sie na 6502, ale chyba jeszcze nie kuca?

Dla dużych map ze słabo powtarzalną grafiką też opłaca się używać trybów tekstowych, tak jest np. w Operation Blood i Special Forces.

Ekran składa się z wielu zestawów znaków, scroll na rejestrach sprzętowych + trochę przepisywania bajtów. W preview Turricana taki scroll jest zrobiony we wszystkie strony.

Trzyb tekstowy nie jest użyty po to, żeby zaoszczędzić miejsca na powtarzalnych elementach (trochę też), ale przede wszystkim po to, żeby się szybko animowało.

O ile dobrze pamiętam to w Operation Blood zestaw znaków zmienia się co 3 wiersze, co daje 8 znaków zapasu na jakiś mini-buforek do scrolla i coś tam jeszcze. Zerknąłem właśnie w kod i widzę, że te trzy wiersze to po prostu znaki od $00 do $7f (pewnie na zapas). Czyli ekran gry to coś w rodzaju ekranu graficznego, tyle że zbudowanego na znakach.

Jakby zmieniać zestawy znaków co 2 wiersze, dałoby się zmontować jakąś niebanalną paralaksę...

Zysk jest taki, że przy skrolu trzeba przerzucić w bok 3*40 bajtów + uzupełnić tło w zestawach znaków, które się wsuwają (20*8 bajtów).

W trybie graficznym trzeba by mieć b. dużo pamięci albo kopiować prawie 8kb co parę ramek.

Obiekty to sofware'owe sprite'y i tak, wszystko tworzone jest dynamicznie. Kosztuje to praktycznie tyle samo, co w zwykłej grafice. Pamiętaj - to co widzisz to tak jakby tryb graficzny, tylko z inaczej porozkładanymi danymi w pamięci. 

Powyżej napisałem nieprawdę - tryb znakowy w Special Forces czy OB nie ma nic wspólnego z oszczędzaniem na powtarzalnych elementach, dokładnie każdy znak może być inny.

Dodam jeszcze, że ze skrolowaniem grafiki są dodatkowe małe problemy (problemiki):
1. trzeba jakoś w grafice omijać granice 4 kb, co może być nietrywialne, jeśli mapka nie ma być bardzo mała
2. ładowanie adresu do antika trwa te parę cykli (i zostaje mniej na np. software'owe sprajty)
3. adresy to 2*200 bajtów, sam update DL trochę czasu zajmie. w dodatku te adresy są rozłożone  z bajtową przerwą, więc kilka cykli się marnuje na omijanie trzeciego bajtu.
4. kawałek DL z grafiką ma 3*200 bajtów, więc już się nie da go upchnąć "byle gdzie" i trzeba to zaplanować, bo inaczej będzie wystawać za 1KB. Nie da się też update'ować DL'ki w prostej pętli na rejestrze.

Ciekawym sposobem skrolowania jest "MWP". Omija problem granicy 4KB, display list zawiera tylko 2 LMS-y (z czego 1 "ruchomy"), nigdy nie trzeba kopiować całego ekranu a tylko 1 wiersz/kolumnę, a pamięć ekranu zajmuje 25*48 bajtów.

ktos moglby wyjasnic metode "MWP"? z tego co zrozumialem to element graficzny 'klocek' moze byc maksymalnie 2 bajty szeroki? co to znaczy ruchomy LMS - ruchomy w sensie rozkaz z LMS jest przesuwany w Display liscie czy wartosc po rozkazie z LMS jest zmieniana?

dzieki za wyjasnienia, jednak ciagle jest dla mnie cos niejasnego:

linia ma szerokosc 48 bajtow = $30, 4kb to $1000 czyli:
linia 0 = $0000-$002f
linia 1 = $0030-$005f
....,....
ostatnia = $0FC0-$0FEF
i zostaje kawalek wielkosci $10 ktory przeszkadza w tym, zeby ekran sie zawinal jak trzeba
to dlatego potrzebny jest ten drugi LMS? powiedzmy, zeby ostatnia linia byla $0FD0=$0FFF? czyli zawartosc pamieci ekranu wyglada tak:
0,1,2,3,4,....47
48,49,....95 ; i zmiana zestawu znakow co 2 linie lub:
0,1,2....,47
0,1,2....,47 ; i zmiana zestawu znakow co jedna linie
i tak przez np 24 razy + jedna taka linia pod koniec tych 4 kb zeby obraz sie zawijal

czyli po scroll 3 znakow poziomo pamiec ekranu wyglada tak:

3,4.......47,0,1,2 (w definiecje znakow 0,1 i 2 danego zestawu znakow kopiujemy dane klocka)

a scroll pionowy to zmiana zestawu znakow, i kopiowanie definicje klockow do 'uwolnionego' z gory lub dolu zestawu znakow? po co dodawac do wartosci po LMS $30 dla scroll pionowego?

wiekszosc tego 4kb jest wolna (gora jest zajeta i 48 bajtow z dolu)

tego nie rozumiem po co ruchomy LMS?

tak to wyglada?

---
no ale po co by bylo kopiowac cokolwiek do pamieci ekranu? tam definicja zawsze jest taka sama 0,1,...47,0,1,2....,47,0,1....???

>Teraz wyobraź sobie długie skrolowanie w dół. Aby ograniczyć przepisywanie pamięci, dorysowujemy tylko dolną linię i zwiększamy LMS. Jednak musimy mieć jakąś granicę, bo inaczej zamazalibyśmy całą pamięć. Dlatego zaczynamy rysować w pamięci "od góry" (której już nie widać) i w DL musimy wstawić drugi LMS, gdzie na ekranie zaczyna się ta "góra".

> Nie do tego, że mamy w pamięci całą wielką grafikę i chcemy ją skrolować. Grafikę generujemy na bieżąco.

wlasnie o tym mowie.
1 linia znaki: 0,1,2,3,.....47, pierwszy zestaw znakow
2 linia znaki: 48,49,......95, pierwszy zestaw znakow - reszta znakow dla spritow
3 linia znaki: 0,1,2,3,.....47, drugi zestaw znakow
4 linia znaki: 48,49,......95, drugi zestaw znakow - reszta znakow dla spritow
....
jesli chcemy scrollowac w bok to wstarczy zwiekszyc LMS o 2 otrzymujemy

1 linia znaki: 2,3,.....47,0,1, pierwszy zestaw znakow
2 linia znaki: 50,51,......95,48,49 pierwszy zestaw znakow - reszta znakow dla spritow
3 linia znaki: 2,3,.....47,0,1, drugi zestaw znakow
4 linia znaki: 50,51,......95,48,49 drugi zestaw znakow - reszta znakow dla spritow

w pamieci obrazu nie kopiujemy niczego
w pamieci zestawu znakow na pozycji 0,1,48,49 lub 0,1,2,3 zalezy jak zbudowana jest linia kopiujemy klocka - nie ma ograniczen co do rozmaitosci grafiki - nie ogranicza nas 128 elementow w zestaw znakow

zeby zrobic scroll pionowy o jeden klocek wystarczy w dli zmienic zestaw na ten nizszy czyli
1,2 linia zestaw 1
3,4 linia zesatw 2
5,6 linia zestaw 3
po scrollu:
1,2 linia zestaw 2
3,4 linia zesatw 3
5,6 linia zestaw 0
i w zestaw zero kopiujemy definicje klockow

i tu nie trzeba zwiekszac nic po LMS

> Zestawy znaków nie mają tu nic do rzeczy.

to by oznaczalo ze mamy ograniczona ilosc elementow graficznych - bo zestaw ma 128 znakow a jeszcze potrzeba cos na sprity programowe.

obawiam sie ze to chyba nie jest MWP.

czy zestaw znakow w MWP jest jeden?

nie, zadna emulacja. tryb znakowy jest wlaczony ze wzgledu na 5 kolor oraz scroll pionowy - nie potrzeba dodawac $30 do LMS.

wlasnie dlatego pytam, bo nie zrozumialem MWP, wiem, ze byl kiedys przyklad dzialania -chyba mario bross- nie moge go znalezc a na pewno wiele by mi wyjasnil.

nie rozumiem tego, że jeden jest ruchomy. moim zdaniem oba nie są (albo nie rozumiem tej metody), specyficzna jest tylko rotacja adresów.
po co n+1 linia jako kopia lini 1 w scrollu pionowym? (pytanie z cyklu newbie)

no właśnie, a dlaczego nie ustawia sie obu LMS na pierwszą i ostatnią linijkę w DL i nie manipuluje tylko adrsami LMS. to więcej kosztuje, nie będzie dobrze działało?
na kartce wychodzi mi, że jedyne o co trzeba zaddbać to specyficzna rotacja adresów na które wskazują LMS'y.