Jak w temacie. Język programowania w sumie nie ma znaczenia. Chodzi mi bardziej o sam sposób jak działa smooth scrolling w platformówkach. Może pytanie dla laika, ale nie pytam o tworzenie bitmapy 2000x1000 pix i scrollowanie jej, a o posiadanie naprawdę większej tablicy kafli w pamięci i dorysowywanie ich do bitmapy podczas scrolla.

Pytam o scroll we wszystkich kierunkach. Powiedzmy, że narazie mamy pojedyncze buforowanie, czyli jedna bitmapa w pamięci. Utworzyłem sobie bitmapę jak na rysunku:
. Niebieska część to rozmiar bitmapy, a czerwona część to tyle, co widzimy na ekranie. Idąc ludzikiem w prawo bitmapa przesuwa się w lewo (a ludzik stoi na ekranie w miejscu). Gdy bitmapa przesunie się o 16 pikseli, to wraca na swoją pozycję 'zero', czyli (16,16), kopiowana jest część bitmapy o rozmiarze (320+16)*(256+2*16) z pozycji 16,0 do pozycji 0,0, a w prawym górnym rogu zaczyna się dogrywanie kolejnych kafli, czyli Block nr_kafla#,336,0.

Wszystko działa prawidłowo, ale jest zbyt wolne. Nie ma szans, że taka metoda jest zastosowana w grach typu Zool, Superfrog itp. Z drugiej strony na pewno te gry nie mają w chip ramie załadowanej pełnej bitmapy levelu ze względu na jego rozmiar.

Czy ktoś wie, jak to tam działa? Nie daje mi to spokoju już od dawna.

• Odpowiedz

@tukinem, post #1

Pora zapoznać się ze ScrollingTrick i stopić sobie mózg. ;)

Scroll po Y jest łatwiejszy ale wymaga coppera i samodzielnego zarządzania wyświetlanym obrazem. Hardware amigowy skonstruowany jest tak, że custom chipy mają komórki bpl0pt..bpl7pt gdzie znajdują się adresy aktualnie wyświetlanego kawałka bitplanów. W tym podejściu jak dobijasz do krawędzi bitmapy, to i tak scrollujesz dalej. W momencie jak na ekranie miałbyś wyświetlić śmieci spoza bitmapy, każesz copperowi przestawić bplXpt na początek bitplanu.



Na niewyświetlanym kawałku bitmapy masz dwa marginesy - jeden rząd kafli który zaraz może być wyświetlony przez scroll i powinien już być gotowy, i następny rząd który dopiero przygotowujesz - najlepiej blitując tam jeden kafel na klatkę, czy coś. W przypadku możliwości scrolla w dwóch kierunkach, trzeba zadbać o to żeby margines gotowych kafli był gotowy w obie strony - "brudny" margines może być wspólny.

Wytłumaczenie scrollowania po X już jest trudniejsze, nazywa się "corkscrew scrolling" i jak nie w archiwum ScrollingTrick to znajdziesz informacje po tym haśle w necie.

Powodzenia! Zacznij powoli, od jednego kierunku, w kolejnej grze dorzuć sobie kolejny. ;)

Ostatnia aktualizacja: 10.07.2023 08:24:41 przez teh_KaiN

• Odpowiedz

@teh_KaiN, post #2

Scroll w poziomie możesz też zrealizować sprzętowo - jest rejestr BPLCON1 który pozwala przesuwać obraz w poziomie o 16 pixeli. W tym czasie musisz przygotować kolejne tło przesunięte o jeden kafelek. Żeby brzegi nie "skakały" trzeba zawęzić pokazywany obraz o ten "roboczy pasek" (rejestry DIW**** i DDF****). Obejrzyj sobie Amiga Hardware Reference Manual

To oczywiście odpowiedź na post #1

Ostatnia aktualizacja: 10.07.2023 08:38:07 przez jarek72

• Odpowiedz

@jarek72, post #3

• Odpowiedz

@teh_KaiN, post #2

Czyli wszystko działa na zasadzie sprzętowej... Ech ogarnięcie coppera to jest tragedia. Już nauczyłem się kopiowania blitterem pełnej bitmapy w kilku bitplanach, a copper to dalej masakra :P

No a co do poziomego scrolla, to w Blitzu mam przykład na EAB, ale to jest przykład scrolla działającego w jedną stronę na bitmapie 352x240 w 4 bitplanach na pojedynczym buforowaniu. Przykłady są trudne do rozeznania się. Łatwiej byłoby wytłumaczyć teoretycznie, a ja bym to sobie nadłubał jakoś w kodzie.

Przykładowo oto moja procedura do kopiowania bitmap:

Laik nie zrozumie, ale łatwiej jest krok po kroku wytłumaczyć, kolejno pod jaki adres pamięci jakie liczby powstawiać i jak je wyliczyć sobie. Nie oczekuję gotowca, tylko w miarę możliwości gdyby ktoś wytłumaczył krok po kroku jaką dużą bitmapę stworzyć, jak przesuwać copperem bitmapę, jak działa corkscrew scroll itp.

Ma ktoś tyle cierpliwości? :)

• Odpowiedz

@tukinem, post #5

• Odpowiedz

@teh_KaiN, post #2

void scrollVPort(struct ViewPort *vp, WORD dx, WORD dy)
{
	struct RasInfo *ri = vp->RasInfo;
		
	DrawInvisibleColumn(ri->RxOffset + vp->DWidth);
	DrawInvisibleRow((ri->RyOffset - 16) % 512);
        DrawInvisibleRow((ri->RyOffset + vp->DHeight) % 512);
	
	ri->RxOffset += dx;
	ri->RyOffset += dy;
	
	if (ri->RxOffset < 0)
	{
		ri->RyOffset--;
		ri->RxOffset += vp->DWidth;
	}
	else if (ri->RxOffset >= vp->DWidth)
	{
		ri->RyOffset++;
		ri->RxOffset -= vp->DWidth;
	}
	
	if (ri->RyOffset < 0)
	{
		ri->RyOffset += vp->DHeight;
	}
	else if (ri->RyOffset >= vp->DHeight)
	{
		ri->RyOffset -= vp->DHeight;
	}

	ScrollVPort(vp);
}

• Odpowiedz

@Hexmage960, post #7

• Odpowiedz

@teh_KaiN, post #4

• Odpowiedz

@tukinem, post #8

• Odpowiedz

@jarek72, post #9

• Odpowiedz

@teh_KaiN, post #11

Skoro Tobie zajęło 30 dni, to mnie zajmie 30 lat

Przesuwanie copperem chyba nie ma nic wspólnego z blitzowym DisplayBitmap #CopList,#BitMap,X,Y.

• Odpowiedz

@tukinem, post #1

• Odpowiedz

@selur, post #13

• Odpowiedz

@teh_KaiN, post #14

no dobra... ale w Aminerze uzyles skrola pionowego, ktory jest o niebo szybszy/latwiejszy niz poziomy.
Jak zrobisz strzelanke/platformowke czy cus ze szybkim skrolem poziomym, to wtedy pogadamy
W kazdym jesyku jest skrol sprzetowy ale na profesjonalne gry sie niestety nie nadaje.

• Odpowiedz

@selur, post #13

No nie do końca, bo grafiki masz zapisane w chip ramie, często tablicę z mapą masz w slow ramie, a asembler najczęściej usprawnia używając rejestrów procesora.

Tu chodzi o rozplanowanie do scrolla. Rozumiem ten sposób scrolla jak tu na rysunku. Czerwona część bitmapy jest widoczna. Idziemy w prawo, lewa strona zapełnia się kolejnymi kaflami. Dojedziemy do granicy, wracamy wyświetlaniem na początek, a po prawej stronie wstawiamy kolejne kafle i tak w kółko. Co jeśli chcemy się wtedy przesunąć w lewo? Jak tych marginesów użyć?

• Odpowiedz

@teh_KaiN, post #11

No, tylko generowanie całej drugiej bitmapy w 16 klatkach często nie jest możliwe z tego względu, że oprócz tego w klatce musisz zrobić masę innych rzeczy - animować przeciwników, przeliczyć logikę gry itd. Najlepsze rozwiązania są takie, które wymagają tylko odrysowania jednego rzędu/kolumny w tym czasie, wprowadzając minimalny narzut do gry.

Jeśli podzielisz sobie liczbę wszystkich kafli przez 16 ramek to wyjdzie ci tylko trochę więcej niż jedna kolumna. Poza tym łatwo można to rozłożyć na 32 ramki. Scroll sprzętowy 16 pikseli, dodanie 2 bajtów do pointera bitplane'u, znowu scroll 16 pikseli i dopiero podmiana. Tylko wtedy trzeba mieć screen szerszy o 32 piksele (2 kolumny kafelków). Co nie wyklucza innych, efektywniejszych rozwiązań

• Odpowiedz

@tukinem, post #16

• Odpowiedz

@selur, post #18

• Odpowiedz

@tukinem, post #16

Corkscrew działa mniej-więcej tak - załóżmy że idziesz w prawo.



Ustawiasz scroll X bitmapy dalej niż jej wymiary zakładają - to powoduje że reszta obrazu tak naprawdę wyświetlana jest z niższej części bitmapy. Każde przejście o jedną szerokość bitmapy w prawo powoduje że zjeżdżasz o jedną linię - obrazek jest wyolbrzymiony. Szerokość bitmapy powinna być ciut większa niż ekranu, żeby mieć margines na rysowanie, a można dwa jak chcesz ruch lewo-prawo, ale tak naprawdę wystarcza jeden - wykrywając ruch w lewo po zaczętym ruchu w prawo anulujesz rysowanie po marginesie i zaczynasz od nowa lewymi kaflami.

Przez to że wyświetlany obraz "zjeżdża" w dół to nie jest to nieskończony scroll, bo w końcu wyjdziesz za bitmapę. W przypadku trybu interleaved i nierysowania po wychodzącej z boku części będziesz też miał spektakularną kaszanę, bo dane bitplanów będą wyświetlane nie na tych co trzeba. Ten efekt działa dlatego, że tak naprawdę bitmapa to nie jest jakiś twór 2d w pamięci, tylko jednym ciurem bajty, gdzie dane trzymane są linia za linią. Nikt Ci nie zabroni przesuwać się po nich jak Ci się tylko żywnie podoba, o ile dalej jesteś w jej pamięci.

No, to teraz jak Ci stopiłem mózg to zrób sobie przerwę, przeczytaj to z 5 razy, a potem zajrzyj do ScrollingTricka bo tam jest to znacznie lepiej wytłumaczone. ;)

@Selur: Jakaś tam gra akcji w kolejce do zrobienia jest, może za 5 lat będzie. ;)

• Odpowiedz

@tukinem, post #16

• Odpowiedz

@teh_KaiN, post #20

ciekawe czy chociaz wnuki sie doczekaja tych gier...

• Odpowiedz

@teh_KaiN, post #20

Rozumiem 2 marginesy po bokach. Wszystko byłoby super, gdyby nie to, że właśnie jadąc w prawo poza granicę bitmapy, wyświetlana jest jej lewa strona, lecz z tym przesunięciem:


Analogicznie idąc w lewo obraz bitmapy opada za każdym razem o 1 piksel, a na górze wychodzą śmieci:


Jeśli da się to w jakiś sposób wyeliminować, to już będę mieć sposób na poziomy scroll.

@Selur:
Gra wyjdzie, a Ty będziesz opowiadał wnukom, jak to dziadek w 2023 roku kibicował koderom w walce z hardware Amigi :P

Ostatnia aktualizacja: 10.07.2023 15:19:08 przez tukinem

Ostatnia aktualizacja: 10.07.2023 15:19:26 przez tukinem

• Odpowiedz

@tukinem, post #23

• Odpowiedz

@tukinem, post #19

• Odpowiedz

@teh_KaiN, post #24

• Odpowiedz

@tukinem, post #26

• Odpowiedz

@teh_KaiN, post #27

• Odpowiedz

@tukinem, post #28

• Odpowiedz

@teh_KaiN, post #29

• Odpowiedz