PISZEMY GRĘ
Zgodnie z zapowiedzią z poprzedniego odcinka dzisiaj omówię niektóre, zawarte w nim procedury naszej gry.
Bardzo ważnymi, ze względu na użyty tryb wyświetlania grafiki, są procedurki DLINT i SHW_BLCK. Pierwsza z nich, to procedura przerwania DL, która zmienia zestaw znaków w każdej linii ekranu. Do rozpoznania, który zestaw ma być w danej linii włączony, użyłem rejestru VCOUNT, który zawiera numer aktualnie wyświetlanej linii ekranu w punktach, podzielony przez dwa. Tak więc podczas każdego przerwania DL (w trybie 4+) zmienia się tylko trzeci bit. Jako, że oba jednokilobajtowe generatory znaków umieszczone są w pamięci jeden za drugim, a kilobajt to cztery strony, wystarczy pominąć wszystkie pozostałe bity za pomocą instrukcji AND #4 i dodać do starszego bajtu adres zestawu znaków, aby znać adres aktualnego. Instrukcja EOR #4 potrzebna jest w naszym przykładzie ze względu na konstrukcję Display List'y.
Procedura SHW_BLCK podobnie, jak i SHW_INFO, czy SHW_ADR ma za zadanie wyświetlić na ekranie znak w trybie 4+, a komentarz do nich jest chyba zbędny.
Ciekawostką jest procedura INI_VAR, której zadaniem jest wymiana zawartości niektórych rejestrów systemowych z zapamiętanymi wartościami. Do tego celu została stworzona tablica LOA_VAR, której pojedynczy wpis zawiera adres rejestru i wartość, którą należy do niego wpisać. Procedura w pętli pobiera kolejne adresy i podstawia je do zmiennej ADR1, następnie z rejestru wskazanego przez tę zmienną pobiera aktualną zawartość i przechowuje ją na stosie, pobiera nową wartość z tablicy, zapisuje do rejestru, a pobraną ze stosu starą zawartość przepisuje do tablicy.
Teraz przejdźmy do dzisiejszego odcinka.
W wielu różnych publikacjach wiele pisano o poziomym przesuwie ekranu. Zawsze jednak pisano o bardzo nieekonomicznej i pamięciożernej metodzie polegającej na zapamiętaniu calej długości przesuwanego ekranu i zmianie adresu wyświetlania linii. Oczywiście i taka metoda jest czasami niezastąpiona, lecz w praktyce rzadko z niej się korzysta. W wielu przypadkach lepiej użyć metody zastosowanej w naszej grze. Polega ona na zastąpieniu zmiany adresu wyświetlania przepisaniem zawartości ekranu w prawo lub lewo i wyświetleniem nowych elementów na jego krawędzi. U nas zawartość ekranu przepisywana jest w lewo, a na prawej krawędzi pojawiają się helikoptery lub premie. Dokładny opis procedury SCROLL, realizującej to zadanie jest chyba zbędny, a jej analizę pozostawiam Czytelnikom.
Na temat SPRITE'ów również bębniono, gdzie tylko możliwe, jednak bębniarze albo nie znali instrumentu albo partytury, gdyż nigdzie nie spotkałem się z solidnym opisem wykorzystania sprite'ów w praktyce. Dziś opowiem o animacji.
W większości gier sprite'y wykorzystywane są do przedstawienia postaci kierowanej przez gracza. W niektórych grach zachwyca nas ładna animacja tychże postaci. Niestety, do tego potrzebny jest dobry grafik, a o takich jest dość trudno. Jednak dla tych, którzy posiadają jakiś talent plastyczny mam kilka porad:
Animację kroczącej postaci najlepiej jest wykonać na ośmiu fazach (rysunkach).
Noga na każdej fazie powinna przesuwać się o dwa punkty.
Cała postać powinna uginać się w miarę stawiania kroków według zasady: im szerzej rozstawione nogi, tym większe ugięcie (proszę zaobserwować własne kroki).
Dla zmniejszenia efektu "kanciastości", w miejscach zagięcia należy wstawić punkt o mniejszej jasności.
Postać powinna się przesuwać o jeden punkt na każdą fazę.
Wprawdzie w naszym przykładzie można sprawdzić tylko punkt przedostatni, lecz każdy może się przyjrzeć animacji, np. w grze "Hans Kloss".
Celowo nie napiszę o tym, jak uzyskać graczy wielokolorowych, gdyż na ten temat jednak napisano dość dużo. Jednak, aby sprawdzić to w praktyce, proszę spojrzeć do naszego przykładu.
Na dzisiaj tyle ględzenia. Dla niektórych mogą to być bzdury, dla innych ciekawostki, a jeszcze inni może skorzystają i nie będą nas więcej straszyć dziwne, kanciaste, trudne do rozpoznania potworki - bohaterowie (?) gier.
P.S. Może niedługo zamieszczę na łamach TA program, służący do definiowania znaków i sprite'ów w omawiany przeze mnie sposób. Jeżeli program będzie zbyt długi, aby go wydrukować, a Czytelnicy okażą zainteresowanie, to może wyda go L.K. AVALON.
plpos equ $20
fuel equ $02
heli equ $08
adr2 equ $b2
jstick0 equ $0278
random equ $d20a
hscroll equ $d404
* procedura przesuwu
* ekranu
scroll equ *
dec przesuw
lda przesuw
sta hscroll
bmi *+5
jmp ok_scrol
lda #3
sta przesuw
sta hscroll
lda screen
sta adrl+1
sta adr2+l
inc adr2
bne *+4
inc adr2+l
ldx #6
scro_1 equ *
ldy #0
scro_2 equ *
lda (adr2),y
sta (adrl),y
iny
cpy #35
bcc scro_2
lda #space
sta (adr1),y
ldy #adr1
lda #36
jsr inad
Idy #adr2
lda #36
jsr inad
dex
bpl scro_1
* losowe wyswietlenie
* helikoptera lub premii
lda random
cmp #50
bcs ok_scroll
lda #heli
sta help_1
lda random
cmp #50
bcs no_fpa
and #3
asl @
clc
adc #fuel
sta help_1
no_fpa equ *
lda screen+33
sta adrl+1
lda random
and #7
tax
scro_3 equ *
dex
bmi scro_4
ldy #adr1
lda #36
jsr inad
jmp scro_3
scro_4 equ *
ldy #0
lda (adr1),y
iny
iny
ora (adrl),y
bne ok_scrol
dey
lda help_1
jmp shw_adr
ok_scrol equ *
rts
* procedura sluzaca
* do zwiekszania
* wartosci zmiennych
* umieszczonych na
* stronie zerowej
inad equ *
clc
adc 0,y
sta 0,y
lda #0
adc 1,y
sta 1,y
rts
* wyswietlenie
* wg zmiennej ADR1
shw_adr equ *
sta (adrl),y
iny
sta (adrl),y
rts
* obsluga gracza
* (sprite'a)
player equ *
* skasowanie gracza
ldy y_plr
ldx #15
lda #0
play_1 equ *
sta sprites+$400+plpos,y
sta sprites+$500+plpos,y
iny
dex
bpl play_1
* zmiana pozycji
* wg wychylenia joysticka
ldy y_plr
lda jstick0
and #%0001
bne no_up
cpy #0
beq no_up
dey
no_up equ *
lda jstick0
and #%0010
bne no_dw
cpy #96
bcs no_dw
iny
no_dw equ *
* wyswietlenie sprite'a
* na nowej pozycji
sty y_plr
lda count
and #3
asl @
asl @
asl @
asl @
tax
lda #l5
sta help_1
play_2 equ *
lda shapel,x
sta sprites+$400+plpos,y
lda shape2,x
sta sprites+$500+plpos,y
iny
inx
dec help_1
bpl play_2
rts
clr_spr equ *
* wyczyszczenie
* pamieci sprite'ow
ldy #0
tya
star_4 equ *
sta sprites+$300,y
sta sprites+$400,y
sta sprites+$500,y
iny
bne star_4
rts
Dariusz Żołna
|