1

Temat: Scroll poziomy?

Lamerskie pytanko mam, wiec nie oczekuje dlugich odpowiedzi i dokladnych algorytmow a jedynie prosze o wyjasnienie w paru slowach "zagadki" ;)

Zastanawiam sie jak robi sie szybki plynny scroll w grach Atari takich jak Zybex?  Chodzi mi o operowanie na ogromnych ilosciach pamieci.

Tzn wiem, ze w wiekszosci gier uzywa sie trybow znakowych co bardzo ulatwia sprawe, ale znaki maja sens chyba tylko wtedy kiedy grafika jest powtarzalna (sklada sie z "klockow") oraz obiekty ruchome sa zrobione na PMG. W innym przypadku uzycie znakow byloby chyba bardzo trudne?

Wiec policzylem sobie, ze przesuniecie obrazu w trybie pixelowym, ktory przyjmijmy zajmuje 8kB, np o 8 punktow w lewo czy w prawo ocznacza koniecznosc przepisania tych 8kB (w kazdej linii do sąsiednich bajtow i uzupelnienie o nowowidoczny bajt grafiki), a to nawet w najprostszej postaci zajmuje mnostwo cykli procesora. A trzeba by to robic pare razy na sekunde.
A gdzie czas na animacje, mechanike gry, muzyke...?

Wiec czy rzeczywiscie tak to jest robione czy stosuje sie jakies "sztuczki"?

2

Odp: Scroll poziomy?

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

przechodze na tumiwisizm

3

Odp: Scroll poziomy?

Candle napisał/a:

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

No tez tak myslalem - ze co linia jest wskaznik pamieci ekranu i mozna przesuwac ten pointer... ale jednak w pewnym momencie trzeba "przeskoczyc" znow do poczatku obszaru pamieci jaki sobie zarezerujemy - jak piszesz "przepisujesz nowy ekran do tego co go nie widac". Moznaby to robic po kawalku... ale to znaczy, ze trzebaby wypelniac grafiką jednoczesnie dwa obszary pamieci (zeby przeskok na poczatek, po skonczeniu sie drugiego ekranu byl natychmiastowy, bez przepisywania 8kB). A jesli gracz moze ruszac sie  w lewo lub prawo,a scroll jest szybki to sprawa sie komplikuje...
Zobacz takie DropZone np. Choc tam pewnie scrollowany jest tylko dol ekranu z grafika.

4

Odp: Scroll poziomy?

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?

przechodze na tumiwisizm

5

Odp: Scroll poziomy?

Akurat Zybex jest chyba w trybie Antica D, więc jest 2x mniej do przepisania.

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

6

Odp: Scroll poziomy?

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

http://www.5oft.pl/

7

Odp: Scroll poziomy?

pirx napisał/a:

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

Rozumiem. No dobrze ale co z animacja obiektow na tle grafiki??? Rozumialbym na czarnym tle, bo moznaby wtedy przygotowac osobne znaki z obiektem przesunietym o 1 piksel. Ale w Operation Blood porusza sie mnostwo obiektow na tle innych! Jak to jest niby zrobione na znakach? Sa tworzone dynamicznie? To juz zupelnie nie widze sensu... Owszem "srodek" takiego obiektu animuje sie szybciej, bo przez przesuniecie paru znakow, ale wszystkie "brzegi" trzeba nakladac na tlo i tworzyc z tego dynamicznie znaki.
A jeszcze zabawa z przelaczaniem zestawow, a wykrywanie kolizji (w OB - celnych strzalow)? Masakra.

8

Odp: Scroll poziomy?

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.

http://www.5oft.pl/

9

Odp: Scroll poziomy?

pirx napisał/a:

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.

O i teraz pojąłem :) Ciezko mi bylo wyjsc myslowo poza "paradygmat" klasycznie ulozonej pamieci ekranu.

Czyli mam odpowiedz na moje pytanie: praktycznie wszstkie gry z dynamicznym scrollem tworzone sa w trybach znakowych (np 12) bo wizualnie dopowiada to trybowi 15, ale operujac na znakach ciezar budowania obrazu przez przesuwanie duzej ilosci pamieci przerzuca sie z procesora na Antic (troszke upraszczajac).

Dzieki!

10

Odp: Scroll poziomy?

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.

http://www.5oft.pl/

11

Odp: Scroll poziomy?

na atari najprosciej zrobic tak, zeby caly obraz byl dostepny - bo po LMS mozna 4kb przyporzadkowac. ale ma to cala mase wad - pamieciozernosc jest chyba najwieksza z nich...

np. dla scrolla w jedna strone spotkalem sie z takimi sposobami:
1. ekran jest standardowej szerokosci, bufor jest szerszy o wielkosc 'klocka' i co ustalony czas bufor jest kopiowany na ekran (ekran jest zbudowany z grafiki 'na znakach') po przewinieciu, licznik linii wraca, bufor jest przepisywany nowa wartoscia i od poczatku procedura sie powtarza
2. nie ma bufora, ekran jest szerszy od widocznej czesci o wielkosc elementu graficznego (najczesciej widzialem 2 lub 3 bajty) po przewinieciu  licznik zerowany, ekran jest kopiowany a w wolne miejsce (teraz zasloniete) kopiowany jest pionowy pas z elementami graficznymi
3. podobnie jak na atari, tylko tak jakby po LMS mozna bylo zdefiniowac po ilu bajtach linia ekranu sie 'zawinie' i zawsze kopiowany jest tylko pionowy pas grafiki na znakach, licznik scrolla nigdy nie jest zerowany.

czyli w najlepszym wypadku trzeba kopiowac (w warunkach atari) ok 12-72 bajty co 4-12 ramek oraz < 1kb po przeladowaniu scrolla ?

Ostatnio edytowany przez xxl (2011-01-11 13:25:50)

http://atari.pl/hsc/ad.php?i=1.

12

Odp: Scroll poziomy?

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.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

13

Odp: Scroll poziomy?

Niezłe.

Offtopic: na tej samej stronie jest procka Jaskiera do myszek. Co w niej niezwykłego, że można ją wołać na VBLK? Jak robiłem eksperymenty z myszą od Amigi, to do bardzo szybkich machnięć trzeba było prockę ok. 1 kHz.

https://www.youtube.com/watch?v=jofNR_WkoCE

14

Odp: Scroll poziomy?

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?

http://atari.pl/hsc/ad.php?i=1.

15

Odp: Scroll poziomy?

MWP opiera się na podobnej idei, co "zwykłe" scrollowanie. Normalnie mamy obszar 4KB pamięci "zawijający się" (znana właściwość ANTIC-a). Załóżmy że mamy displaylistę z 1 rozkazem LMS na początku i HSCROL+VSCROL włączonym we wszystkich liniach. Dzięki własności zawijania się, przy przesuwie w dowolny z 4 kierunków wystarczy że zmienimy adres w LMS o +1/-1/+48/-48 (zakładając zwykłą szerokość ekranu) i wkopiujemy w pamięć ekranu 1 kolumnę albo 1 wiersz danych. Nigdy nie trzeba wkopiowywać za jednym razem danych całego ekranu. Problemem jest tylko to, że marnujemy 4KB RAM podczas gdy na ekranie wyświetlany jest tylko ~1KB (25*48B).

Idea MWP jest taka, żeby dodać jeszcze 1 rozkaz LMS do displaylisty, aby zasymulować w ten sposób zawijanie się pamięci ekranu nie co 4KB, tylko np. co 1KB (można wybrać dowolną wartość), aby nie marnować RAM-u. Położenie tego rozkazu LMS w displayliście będzie się zmieniać w miarę scrollowania. Ot i cała filozofia.

xxl napisał/a:

z tego co zrozumialem to element graficzny 'klocek' moze byc maksymalnie 2 bajty szeroki?

Nie ma żadnych ograniczeń tego typu. Gdzie to wyczytałeś?

Ostatnio edytowany przez Krótki (2011-01-21 15:10:49)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

16

Odp: Scroll poziomy?

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

Ostatnio edytowany przez xxl (2011-01-21 18:52:41)

http://atari.pl/hsc/ad.php?i=1.

17

Odp: Scroll poziomy?

Trzeba zrozumieć, do czego stosuje się tę metodę. Nie do tego, że mamy w pamięci całą wielką grafikę i chcemy ją skrolować. Grafikę generujemy na bieżąco. Np. mamy mapę, której każdy element to 4x4 znaki - nie trzymamy całej mapy rozpakowanej, bo to dużo zajmuje.

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

Podobnie ze skrolem w innych kierunkach, chociaż przy skrolowaniu na boki trzeba dłużej pomyśleć, jak to działa.

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

Ostatnio edytowany przez Fox (2011-01-21 19:21:41)

https://www.youtube.com/watch?v=jofNR_WkoCE

18

Odp: Scroll poziomy?

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

Ostatnio edytowany przez xxl (2011-01-21 20:06:07)

http://atari.pl/hsc/ad.php?i=1.

19

Odp: Scroll poziomy?

Przedstawiłeś bardzo specyficzny tryb, który nie wiem czemu ma służyć, chyba emulacji C64 tudzież innego Spectrum? ;)
Skoro numery znaków masz "na stałe", to po co włączasz tryb znakowy i ciągle przełączasz fonty? Oszczędzisz cykli i pamięci używając zwykłego trybu bitmapowego.

Opis MWP zakłada, że skrolowana jest pamięć grafiki, a nie zawartość fontów. Jednak w Twoim przypadku też korzystasz z zasad MWP:
1. Masz ograniczoną liczbę fontów i w którejś linii ekranu musisz zacząć używać pierwszego fontu, co odpowiada temu LMS w środku DL.
2. Wpisujesz dane do fontów tak jak to opisano w MWP.

Ostatnio edytowany przez Fox (2011-01-21 20:33:50)

https://www.youtube.com/watch?v=jofNR_WkoCE

20

Odp: Scroll poziomy?

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.

http://atari.pl/hsc/ad.php?i=1.

21

Odp: Scroll poziomy?

Znalazł się! Przykład skrolowania MWP wrzucił kiedyś na AtariAge Analmux, ale później go skasował. Ale wczoraj wrzucił go tam ponownie. W załączonym ZIP-ie MWP jest użyte w demku "Super Mario Clone & Hardsynth Tune". Źródeł nie ma, więc pozostaje Ci analiza pod monitorem w emu.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

22

Odp: Scroll poziomy?

Krótki napisał/a:

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.

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)

Ostatnio edytowany przez xeen (2011-06-16 22:51:13)

PunBB bbcode test

23

Odp: Scroll poziomy?

Tak na pierwszy rzut oka ten MWP wydaje mi się znajomy.
Mogę jeszcze bredzić w chorobie, ale z tego co widzę to jest to samo co robiłem na Copper List lata temu. (np. Foresty)
I nawet całkiem nie dawno zastanawiałem się jak by to działało na DList.
Zwiń sobie kartkę papieru w rulon, tak żeby końce się stykały.
Ten złączony obszar to będzie ten ruchomy LMS - z tym że ruchomy to on jest tylko z nazwy. Zmienia swoje położenie w DList ale nie zmienia adresu LMS.
No a stały (który jest ruchomym tak na prawdę) jest zawsze na początku DList ale musisz adres LMS przeliczać dla niego.
Dokładasz do tego potem scroll poziomy i masz obszar o szerokości około 100 ekranów i bez ograniczeń przewijania pionowego ;)
Cały problem polega na rysowaniu "pasków" danych w odpowiedni sposób dostosowując się do DList.
Może skrobnę coś takiego w przyszłym tygodniu żeby to zobrazować lepiej ;)

Ostatnio edytowany przez Eagle (2011-06-17 04:07:21)

24

Odp: Scroll poziomy?

Eagle napisał/a:

Ten złączony obszar to będzie ten ruchomy LMS - z tym że ruchomy to on jest tylko z nazwy. Zmienia swoje położenie w DList ale nie zmienia adresu LMS.

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.

PunBB bbcode test

25

Odp: Scroll poziomy?

Tak na szybko napisałem żeby zobrazować. Jest nie doskonała, ale na potrzeby poglądowe wystarczy.
Akurat wybrałem metodę tworzenia za każdym razem nowego DList.
Ta metoda jest chyba najlepsze gdybyśmy chcieli jeszcze scroll poziomy.
Bo przy tylko pionowym można to dużo prościej załatwić. ;)
Xeen pozostaje tylko wrzucić grafę potem i czekam na Ikari Wariors A8 ;)
Pozdrawiam

Post's attachments

VscrollLoop.xex 888 b, liczba pobrań: 24 (od 2011-06-17) 

Tylko zalogowani mogą pobierać załączniki.