Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
atari.area forum » Posty przez tebe
http://mads.atari8.info/softsprt_OK.zip
z obsluga duchow 8x24, na ekranie znajduje sie 18 duchow (3 ksztalty), calosc wyrabia sie w 3 ramkach (mozna sprawdzic komorke $0200, wartosc 2 oznacza 3 ramki)
źródła razem z madsem załączone w archiwum, ogolnie nie jest to na 100% wersja finalna, ale juz dzialajaca
ja bym sprobowal, wolna strona zerowa, zajetej pamieci na duchy o polowe mniej, wada to "tylko" 13 duchow... moze warto?
Aktualnie jest wystarczajaco wolnej strony zerowej, tak naprawde zysk byłby z tego taki że zamiast 15 klatek animacji duch mógłby skladac sie z 30 klatek i tych duchow byloby mniej
Dodatkowo zostałoby wprowadzone poważne ograniczenie dotyczące masek dla operacji AND, aktualne maski wyliczane są na podstawie pixli grafiki i nie są idealne ale na potrzeby testów wystarczające, czyli jeśli jest jakiś pixel to twórz pixel maski, a co jeśli pixlem grafiki jest kolor %00 ktory domyslnie traktowany jest jako tło a nie kolor grafiki? a co jeśli chcesz aby duch miał czarną obwódkę jak jest to zrealizowane w przeszkadzajkach z Dynablaster. Ogólnie musze stworzyć bardziej skomplikowana procedure generującą maski aby uwzględniać czarne pixle wewnątrz ducha i wtedy tablica 256 bajtow dla maski ducha nic nie pomoże.
Trzeba pamietac że aktualnie nie ma wogóle detekcji kolizji, jest tylko jeden program obsługi duchów ktory losuje wartosci i dodaje do pozycji X,Y, brak muzyki dla ktorej player zająłby jakiś czas na przerwaniu VBL. Program obsługi ducha wywoływany jest zaraz po jego wygenerowaniu i ma za zadanie sterować duchem, podejmować decyzje odnośnie jego zachowania itp, itd. to właśnie te krótkie programiki obsługi ducha będą determinować o końcowej szybkości całego silnika.
W prawdziwej grze na pewno stracimy jeszcze kilka dodatkowych duchow, wiec ideą przewodnią jest stworzenie jak najszybszego silnika generującego duchy.
Mam jeszcze takie pytanie: te 17duchów/na 3 ramki to przy jakiej szerokośći ekranu? 32 znaki? Jeżeli tak to ile ich będzie przy szerokości 40 i 48 znaków?
ekran 32 bajty: 17 duchow / 3 ramki
ekran 40 bajtów: 15 duchow / 3 ramki
ekran 48 bajtów: brak wyniku, ekran rozpierniczony, śmieci, tryb GTIA, trzeba przyjrzec sie temu blizej
ogolnie caly silnik synchronizuje sie do zadanej liczby ramek (domyslnie 3) tak ze jesli na ekranie bedzie mniej duchow to nadal przelaczanie obrazow bedzie odbywalo sie raz na 3 ramki, czyli nie bedzie przyspieszenia akcji ze wzgledu na mala ilosc obliczen, podobnie jesli zostanie odpalony na dopalce Pasia F7 to tez zachowa zadane tempo 3 ramek
i jeszcze jedno bo to mi nie daje spokoju:
mowisz o 13 duchach na raz ruszonych (w 3 ramkach) a co jest jesli wyswietliles wczesniej np. 20 duchow ale 7 stoi w miejscu i sie nie animuje ?
zostana skasowane, wszystkie duchy sa nakładane na dany bufor za kazdym razem, bo wszystkie duchy wykorzystuja ta sama strone zerowa i za kazdym razem dla kazdego ducha z osobna musi ona zostac zaincjowana nowymi watrtosciami
sa dwa bufory (animacja przez przelaczanie obrazow), kazdy z tych buforow ma swoja pamiec obrazu i swoje 4 zestawy znakowe, dodatkowo istnieje bufor główny ktory przechowuje tylko pamiec obrazu z polem gry
cała pętla działa w dwóch właściwie krokach, krok1: wyświetl bufor 3, zacznij modyfikować bufor 2, krok2: wyświetl bufor 2, zacznij modyfikować bufor 3, skok do kroku 1.
modyfikacja bufora polega na przepisaniu pamieci obrazu z bufora glownego (bufor 1) do danego bufora i nalozenie duchow, bufor glowny sluzy tylko do odczytu, mozna go modyfikowac jesli chce sie uzyskac jakas dodatkowa akcje w polu gry, tyle ze trzeba zrobic to w odpowiednim miejscu
p.s.
można zrobić jeszcze inaczej, silnik będzie odpalany przez skok JSR pod odpowiedni adres (za kazdym wywołaniem zostanie przelaczony obraz na inny bufor), po powrocie z silnika robimy swoje niewiadomo jak długo
i znowu wywolujemy silnik, w ten sposób całość będzie nierównomiernie działała i będą skoki szybkości, ogólnie chaos chyba że będziemy mieli pare duchów tak aby wszystko mieściło się w granicy 1 ramki
8 kilo na tablice masek to troche sporo. tak sie zastanawiam, a moze:
ldx $ffff,y - ksztalt ducha
lda $ffff,y - tlo
and $ffff,x - tablica masek 256 b
ora $ffff,y - ksztalt ducha
sta $ffff,y - sprajt
predkosc spada do 14 duchow na 3 ramki, czyli do predkosci jaka dysponuje wersja bez procedury modyfikujacej na stronie zerowej
jest tylko małe ALE
akualna wersja zajmuje na stronie zerowej 12*16 = 192 bajty + 7 bajtow na ośmiokrotne petlenie sie
dey
smi
jmp $0009
rtsw sumie na stronie zerowej tym sposobem zajetych jest 199 ($C7) bajtow + 8 bajtow na zmienne, razem aktualny silnik zajmuje $CF bajtów strony zerowej
Twoja wersja XXL jest oszczedna dla pamieci masek, jednak nie dla strony zerowej bo 15*16+7 = 247 ($F7) bajtow, do dyspozycji uzytkownika zostaje 8 bajtow na stronie zerowej jesli tylko zabrać silnikowi aktualne zmienne na stronie zerowej, albo procedure umieścić poza strona zerowa co oznacza strate 1 ducha i wyjdzie rzeczywiscie 13 duchow w 3 ramkach
p.s.
nastepny kod zrodłowy, jak tylko dorzuce obsluge duchow 8x24
"and $ffff", ta operacja jest potrzebna aby zrobic miejsce pod duchem czyli usunac pixle grafiki, mozemy zrezygnowac z AND ale wtedy duch po nalozeniu na grafike w extremalnym przypadku wogole zniknie i nie bedzie go widac, ogolnie sama operacja OR bedzie tworzyć z tłem obrazu jakies nieprzewidywalne kolory
pamiec z danymi duchow wyglada tak:
; $4000-$47FF shp.shr0
; $4800-$4FFF shp.shr2
; $5000-$57FF shp.shr4
; $5800-$5FFF shp.shr6
;
; $6000-$67FF msk.shr0
; $6800-$6FFF msk.shr2
; $7000-$77FF msk.shr4
; $7800-$7FFF msk.shr6shr0 - przesuniecie o 0 bitow w prawo
shr2 - przesuniecie o 2 bity w prawo
shr4 - przesuniecie o 4 bity w prawo
shr6 - przesuniecie o 6 bitow w prawo
shp.shr zawiera N klatek animacji ducha z zadanym przesunieciem
msk.shr zawiera N klatek masek animacji ducha z zadanym przesunieciem
N = 0..15, czyli duch moze miec maksymalnie 15 klatek, dlaczego ? bo $800/136 = 15, a skad 136 sie wzielo ? 17*8 = 136, bo kazda klatka zapisana jest nie za pomoca 16 znakow tylko 17, 17 znak jest pusty i jest potrzebny aby nie było widać śmieci które pojawialy sie przy ruchu pionowym
mam pytanie, and $ffff,y - co zawiera ta tablica jaka jest jej wielkosc i gdzie lezy?
tablice dla AND to msk.shr0, msk.shr2, msk.shr4, msk.shr6 i leżą one pod stałymi adresami w/w
tablice dla ORA to shp.shr0, shp.shr2, shp.shr4, shp.shr6 i leżą one pod stałymi adresami w/w
http://mads.atari8.info/softsprt_OK.zip
wszystko idzie w dobrym kierunku, wczesniejszy pomysl ulegl malej modyfikacji, zalaczona wersja potrafi wyswietlic 17 duchow w 3 ramkach i zajmuje najmniej miejsca kosztem strony zerowej, ktora wykorzystuje prawie w calosci
na stronie zerowej umieszczona zostala rozpisana procedurka realizujaca to (struktury mads-a czynia cuda):
lda $ffff,y
and $ffff,y
ora $ffff,y
sta $ffff,yprocedurke ze strony zerowej mozna takze wykorzystac do tworzenia duchow 8x24, duchy 8x24 beda potrzebowac tylko dwoch dodatkowych bankow z rozpisana procedura inicjalizacji, pozatym obecnosc duchow 8x24 bedzie mozna wykorzystac do optymalizacji dzialania duchow 12x24 (dla pozycji "x and 3=0")
w zalaczonej wersji, ktora najbardziej mi sie podoba ze wzgledu na zrownowazone parametry szybkosci i pamieciozernosci ustalony jest staly podzial pamieci banku dla danych duchow, tak ze maksymalnie duch moze skladac sie z 15 klatek animacji i zajmuje tylko 1 bank pamieci
podkladania PMG jeszcze nie zrobilem, ogolnie napisalem ze jest to mozliwe z poziomu programow obslugi ducha, poniewaz kazdy duch ma swoj program obslugi, najprostszy program obslugi to RTS :)
w zalaczonym przykladzie wyswietlane sa 4 duchy i 4 pociski z piorytetem 8, piorytet 0 dziala tylko zadowalajaco dla dwoch pierwszych duchow i dwoch pierwszych pociskow
ogolnie mozna zajrzec do G2F, tam to wszystko jest podane w zakładce EDIT PMG
dla piorytetu GTICTL=8 duchy przykrywaja kolory z rejestrow COLOR2, COLOR3 (invers), a jako ze inversu duchy programowe nie uzywaja oznacza to ze duchy programowe bede miały zmieniany tylko jeden kolor konkretnie ten z rejestru COLOR2 (710)
4 duchy sprzetowe moga calkowicie podbarwiac ducha programowego 12x24
4 pociski sprzetowe moga calkowicie podbarwic ducha programowego 8x24 (tym samym kolorem co duchy lub kolorem z rejestru COLOR3=kolor inversu)
wlasnie wpadlem na pomysł trzeciego sposobu, który bylby połączeniem obu wcześniejszych, szybkości i małej zajetości banków pamieci, kosztem pamięci podstawowej
musimy z gory założyc jaka może być maksymalna liczba klatek animacji ducha, np. 8 i nie więcej
dla tych 8 klatek rozpisujemy procedure modyfikujaca zestaw znakow, zajmuje ona dokładnie $516 (1302) bajtów, wersja dla ducha na pozycji PIXEL=0 zajmuje $456 (1110) bajtów (modyfikujemy 12 a nie 16 znakow)
dane wszystkich klatek animacji lacznie z przesunieciem o pixel w prawo beda pod stalymi adresami w obszarze $4000..$7FFF czyli w banku pamieci
wystarczy przelaczyc bank, aby procedury modyfikujace z pamieci podstawowej zaczely czytac dane opisujace innego ducha :)
wersja najszybsza zajmie 8*1302+8*1110=19296 ($4B60) bajtow pamieci podstawowej, wersja wolniejsza 8*1302=10416 ($28B0) bajtow pamieci podstawowej
oczywiscie jesli przyjmiemy wieksza liczbe dopuszczalnych klatek animacji np. 10,12 bedzie potrzeba wiecej pamieci podstawowej, tak ze moze jej nie starczyc do innych celow (obszar $4000..$7FFF jest uzywany przez banki, wiec niewiele z niego skorzystamy)
ogolnie ta wersja wydaje sie najbardziej atrakcyjna, mimo tego że narzuca ograniczenie co do ilosci maksymalnej liczby klatek animacji i jest mało gospodarna w wykorzystaniu pamieci bankow, bo 8 klatek zajmie niecałe 9kB banku
wersja zajmujaca mniej pamieci, wszystkie klatki animacji ducha w 1 banku
http://mads.atari8.info/softsprt_slow.zip
nie jest to wersja finalna, jeszcze cos sie "kaszani", ogolnie po dodaniu potrzebnych obliczen itp engin zwolnil dla 3 ramek aż o 5 duchow (mozna jeszcze dokonac malej optymalizacji wtedy strata bedzie może rzędu 3 duchow)
na chwile obecna 14 duchow = 3 ramki (wersja pamieciozerna 3 ramki = 19 duchow)
BTC scena nie zna ograniczeń
Vega nie wiem skad Ci wyszlo to 820kb
4 banki zawieraja np. 10 klatek animacji dla ducha + te same klatki animacji z przesunieciem o pixel w prawo, i to wszystko jesli chodzi o animacje jednego ducha, potem mozemy wykorzystywac ta jedna animacje do tworzenia innych duchow, to nie zajmuje juz wiecej pamieci
w Bubble masz powiedzmy na dana chwile 4 rodzaje przeszkadzajek (duchow), czyli:
- 10 klatek animacji ducha #1 ruch w prawo = 4
- 10 klatek animacji ducha #2 ruch w prawo = 4
- 10 klatek animacji ducha #3 ruch w prawo = 4
- 10 klatek animacji ducha #4 ruch w prawo = 4
- 10 klatek animacji ducha #1 ruch w lewo = 4
- 10 klatek animacji ducha #2 ruch w lewo = 4
- 10 klatek animacji ducha #3 ruch w lewo = 4
- 10 klatek animacji ducha #4 ruch w lewo = 4
to wszystko zajmie 512kb, na tej podstawie mozesz stworzyc np. 16 (albo wiecej) roznych duchow o maksymalnie 4 rodzajach ksztaltow i 2-och kierunkach poruszania sie
p.s.
nowsza wersja uwzglednia programy obslugi dla kazdego ducha, w programie obslugi mozna zmieniac pozycje x,y, dodac podbarwienie duchem sprzetowym, wykrywac kolizje, reagowac na kolizje itp itd.
p.s.#2
mozna skrocic 4 banki do 1 banku jesli skorzystac z adresowania indeksowego, obecnie jest tak:
lda (src),y
and msk,x
ora shp,x
sta (dst),ywersja krotsza ale dluzsza w cyklach:
lda (src),y
and (msk),y
ora (shp),y
sta (dst),yz pobieznych testow wynika ze tym sposobem tracimy tylko jednego ducha, czyli zamiast 5 duchow w 1 ramce, bedziemy mieli 4 duchy w 1 ramce
2 banki na procedury inicjujace BUF2, BUF3 i kazde nastepne 4 banki na nowy kształt (animacje) ducha
zalaczony przyklad zajmuje 2+4+4 = 10 bankow pamieci - 1 = 9, bo jednym z bankow pamieci jest tak naprawde bank $FE a ten miesci sie przeciez w podstawowej pamieci RAM :)
pamiec podstawowa (plik GLOBAL.HEA) $A000..$CFFF:
B1scr = $a000 ; dane obrazu dla BUFOR #1 (ten obszar jest kopiowany do BUFOR #2, BUFOR #3)
B1inv = B1scr+$400 ; dane inversu dla BUFOR #1 (stale wartosci, jesli modyfikujemy B1SCR to tutaj musimy uaktualnic invers)
B2scr = B1inv+$400 ; dane obrazu dla BUFOR #2 (ulega modyfikacji podczas nakladania duchow)
B3scr = B2scr+$400 ; dane obrazu dla BUFOR #3 (ulega modyfikacji podczas nakladania duchow)
B2fnt0 = B3scr+$400 ; zestawy znakow dla BUFOR #2
B2fnt1 = B2fnt0+$400
B2fnt2 = B2fnt1+$400
B2fnt3 = B2fnt2+$400
B3fnt0 = B2fnt3+$400 ; zestawy znakow dla BUFOR #3
B3fnt1 = B3fnt0+$400
B3fnt2 = B3fnt1+$400
B3fnt3 = B3fnt2+$400program obslugi $2000..$2FFF
p.s.
Vega Ty chyba nie chcesz uzywac duchow sprzetowych do wykrywania kolizji ? bo to da sie zrealizowac programowo, obliczyc odległość srodka jednego ducha od drugiego, wartosc z odpowiedniego przedzialu bedzie oznaczac kolizje
p.s.#2
podbarwic na calej szerokosci mozna tylko duchami o podwojnej szerokosci, pociski nawet najszersze podbarwia tylko 8 pixli
mozna dodac taka opcje, oczywiscie max 8 duchow byloby w ten sposob podbarwione, bo multiplexera tutaj nie ma
pozatym mozna wykorzystac piorytet 0 duchow, przez co duch podbarwi (rozjasni) danym kolorem wszystkie pixle grafiki ducha programowego
p.s.
usprawiony mads http://mads.atari8.info/asembler.exe podczas pisania zauwazylem pare mozliwych udogodnien i uaktualnilem mads'a przez co tylko ta wersja poprawnie asembluje kod silnika duchow
http://mads.atari8.info/softsprt.zip - wersja silnika z kodem źródłowym
przyklad dzialania nowego silnika http://mads.atari8.info/softsprt.zip
duchy o rozmiarze 12x24 pixle
5 duchow = 1 ramka
11 duchow = 2 ramki
19 duchow = 3 ramki
w zalaczonym przykladzie wyswietlanych jest 16 duchow, znaki tła maja kody 0..63, wiecej duchow oznacza ze tlo będzie składać sie z mniejszej liczby znaków
na chwile obecna moj silnik dla spritow na znakach potrzebuje 12..17 linii obrazu (wartosc z $D40B) na przepisanie i modyfikacje 16 znakow z 4 zestawow, predkosc uzalezniona od linii w ktorej startuje procka
a ile zajmuje :), dwie procedury dla dwóch buforów inicjalizujace zmienne i bufory to 2 banki pamieci
8 klatek animacji ducha z przesunieciem o 1 pixel w prawo to 4 banki pamieci
ogolnie wszystko rozpisane i rozpetlone
w Nibbly zrealizowane zostało to podobnie, ekran o szerokosci 40 bajtow podbarwiany jest dwoma duchami o maksymalnej szerokosci, dwoma bo rozmnażane sa one w linii, dodatkowo co 8 linii zmieniany jest ich kolor, przez co Nibbly jest bardzo kolorowe jak na tryb znakowy, pozatym do dyspozycji zostaja jeszcze 2 duchy i 4 pociski
podobnie realizowany jest panel na dole ekranu, z tym ze sa tam uzyte duchy 4 kolorowe ktore sa rozmnazane w linii
p.s.
nie wykluczam ze ekran o szerokosci 32 bajtow udaloby sie podbarwic tylko 1 duchem
p.s.
zaleta trybow tekstowych jest mniejsze zuzycie pamieci
Sipowitz ten mały zasilacz ATX z Allegro w/w kosztuje 7 zł, to dużo ?
ten zasilacz ATX jest mniejszy http://www.allegro.pl/show_item.php?item=118296568
XXL po tym przykładzie widać że masz problem z płynnym scrolem :) W Phantom duchy stawiane są co znak a nie co pixel, jest to najbardziej prymitywna metoda, jeśli miałbyś robić gry w ten sposób to daruj sobie.
obejrzyjcie sobie gre POOYAN, jest na znakach
Vega możliwe, jednak musisz miec bufory, zeby nie zerwało synchronizacji
p.s.
napisze engine do znakowych taki ze pamieci Atari nie starczy
Vega, nie wspomnialem o tym wczesniej, ale wydawało mi sie to oczywiste że powinieneś rozpisać wszystkie klatki animacji ducha (12x24 pixli) na 4 fazy (przesuniete o 1 pixel w prawo)
Vega masz przecież UltraXE, udaje mi się na tym odpalić wszystko co napisałem dla 65816 łącznie z XLPMax 2.6
tak Scorpio, dla samego "sportu" mozna i samemu przepisywać przy wylaczonym DMA, ale jest to tak nieefektywne że wogole nie warto o tym wspominac
C64 posiada sprity o szerokosci 12 pixli trybu 15OS Atari i wysokosci 21 linii (4 kolory), ich kształt, kolory itp mozna zdefiniowac "jako gotowce" potem np. w rastrze podmienic adres do nich i rozmnozyc je w linii, na Atari ten numer nie przejdzie bo Atari tworzy duchy przepisujac je linia po linii z odpowiednich rejestrow, czyli ogólnie Atari - C64 to zupełnie inne podejścia do tematu duchów sprzętowych
duchy programowe na znakach, jedyne jakie zrobiłem to te w grze Dynablaster, ekran to tryb JGP Dariusza Żołny zwany też 4+ (tryb wymyślony przez Avalon), czyli dwa zestawy znaków zmieniane co wiersz
ogólnie udało się w 1 ramce bez buforowania zmieścić 4 ruchome obiekty 8x8 pixli rozdzielczości trybu 15 OS, maksymalnie w 1 ramce możnaby zmieścić 8 takich obiektów, schemat działania: obraz and maska_obiektu -> obraz or kształt_obiektu -> zapisz na obraz
dla trybu graficznego udało się zmieścić 8 obiektów o rozdzielczości 12x24 pixli w 1 ramce z 3-ma buforami i bez maski_obiektu czyli schemat prostszy: obraz or kształt_obiektu -> zapisz na obraz
(przykład załączony do mads-a)
podejście Vegi do tematu wygląda OK, nie ma tu żadnych wielkich tajemnic i tricków, dla 4 zestawów znaków będzie trzeba napisać odpowiednią procedure kopiująca odpowiednie znaki do bufora, potem bufor zmodyfikować odpowiednim kształtem ducha i w końcu przesłać zawartość bufora do odpowiednich znaków z zestawów znakowych. Tak to działa w Dynablaster, wszystkie operacje przepisania są rozpisane (rozpętlone). Ideałem byłoby gdyby nie było bufora przejściowego tylko całą operację udało się zmieścić w jednej rozpętlonej pętli.
Pozatym Jaskier swego czasu zdisasemblował silnik duchów programowych Avalonu (chyba z Lasermani) i jest to ogólnie dostępne, próbowałem to uruchomić ale zabrakło nerwów :) Oczywiście duchy Avalonu wykorzystują tryb 4+ (2 zestawy znakowe) więc tak czy siak dla 4 zestawów znakowych trzeba napisać swój silnik.
*--------------------------*
* SP by Marcin Lewandowski *
* based on SP by *
* Miroslaw Liminowicz *
*--------------------------*
opt 6
org $a800
* jsr init x=LSB(tab), y=MSB(tab)
* tab=
* 1.MSB(dane spriteow)
* 2.il.spriteow (max=21)
* 3.pierwszy wolny znak
* 4.lewa krawedz sceny
* 5.prawa krawedz sceny
* 6.wysokosc ekranu
* 7.szerokosc ekranu
* 8,9.pirwszy dlist
* 10,11.drugi dlist
* 12.MSB(pierwszy ekran)
* 13.MSB(drugi ekran)
* 14.MSB(pierwszy zestaw)
* 15.MSB(drugi zestaw)
* jsr proc wywolywac co jakis czas
* wedle uznania
* numzn= numer spritea w 4+
* xpos= polozenie X
* ypos= polozenie Y
* stat= statusy spriteow
* bit 0 zakrywanie przez ekran
* bit 6 zwierciadlo poziome
* bit 7 zwierciadlo pionowe
*--- strona 0
anascr equ $d6
aspr1 equ $d8
aspr2 equ $da
aznp1 equ $dc
aznp2 equ $de
aznp3 equ $e0
aznk1 equ $e2
aznk2 equ $e4
aznk3 equ $e6
posx equ $e8
posy equ $e9
invrs equ $ea
poczn equ $eb
przes equ $ec
numspr equ $ed
pr1 equ $ee
pr2 equ $ef
pr3 equ $f0
numl1 equ $f1
numl2 equ $f2
numl3 equ $f3
b1 equ $f4
b2 equ $f5
clock equ $f6
adrscr equ $f7
aktzes equ $f8
adrzes equ $f9
adrbuf equ $fa
*--- program
jmp proc
jmp init
numzn dta d' '
xpos dta d' '
ypos dta d' '
stat dta d' '
*--- init
init stx b1
sty b2
jsr chow
* parametry
ldy #1
lda (b1),y
tax
dex
stx zm21+1
iny
lda (b1),y
sta zm31+1
sta zm32+1
sta zm33+1
sta zm34+1
iny
iny
iny
lda (b1),y
sta zm51+1
sta zm52+1
iny
lda (b1),y
sta zm61+1
tax
inx
inx
stx zm62+1
inx
stx zm64+1
sec
sbc #3
sta zm63+1
ldx #0
ldy #0
i9 lda zmtab+1,x
beq i11
sta i10+2
lda zmtab,x
sta i10+1
lda (b1),y
i10 sta $ffff
iny
inx
inx
bne i9
i11 lda zmd+1
sta zmd1+1
lda zme+1
sta zme1+1
lda #0
sta bufor1+21
sta bufor2+21
sta clock
tax
* maski
i1 txa
sta b1
asl @
ora b1
and #$aa
sta b1
lsr @
ora b1
eor #255
sta msktab,x
inx
bne i1
* zwierciadla
i2 txa
ldy #3
i3 asl @
rol b1
asl @
ror odwr,x
lsr b1
ror odwr,x
dey
bpl i3
inx
bne i2
* adresy wzgl.fontow
i4 txa
ldy #0
sty b1
asl @
asl @
rol b1
asl @
rol b1
sta ladrzn,x
lda b1
sta hadrzn,x
inx
bpl i4
* adresy wzgl.ekranu
ldx #0
txa
sec
zm62 sbc #0
sta lscr
lda #$ff
sta hscr
clc
i5 lda lscr,x
zm6 adc #0
sta lscr+1,x
lda hscr,x
adc #0
sta hscr+1,x
inx
zm5 cpx #0
bcc i5
zmf lda #0
asl @
asl @
sta scena
adc #4
sta scena+1
adc #4
sta scena+2
zm4 lda #0
asl @
asl @
sta scena+3
adc #4
sta scena+4
adc #4
sta scena+5
jsr obraz
jmp odchow
*--- animator
proc jsr chow
stx numspr
lda #$2a
sta przes
lda #0
sta invrs
petla inc numspr
ldx numspr
zm2 cpx #0
bcc *+5
jmp exit
lda xpos,x
sta posx
lda ypos,x
sta posy
lda numzn,x
ldy #0
sty b1
asl @
rol b1
asl @
rol b1
asl @
rol b1
asl @
rol b1
sta aspr1
ora #8
sta aspr2
lda b1
zm1 adc #0
sta aspr1+1
sta aspr2+1
lda stat,x
asl @
tay
and #2
tax
lda atab2,x
sta zjmp2+1
lda atab2+1,x
sta zjmp2+2
tya
bcs *+5
jmp od5
bpl od3
* odwracanie
ldx #7
stx b1
ldy #0
od1 lda (aspr1),y
tax
lda odwr,x
ldx b1
sta buf2+8,x
lda (aspr2),y
tax
lda odwr,x
ldx b1
sta buf2,x
iny
dec b1
bpl od1
lda aspr1+1
adc #3
sta aspr1+1
lda aspr2+1
adc #4
sta aspr2+1
dey
od2 inc b1
lda (aspr1),y
tax
lda odwr,x
ldx b1
sta buf1+8,x
lda (aspr2),y
tax
lda odwr,x
ldx b1
sta buf1,x
dey
bpl od2
bmi od8
od3 ldy #0
lda (aspr1),y
tax
lda odwr,x
sta buf1+8,y
lda (aspr2),y
tax
lda odwr,x
sta buf1,y
iny
cpy #8
bcc od3+2
lda aspr1+1
adc #3
sta aspr1+1
lda aspr2+1
adc #4
sta aspr2+1
dey
od4 lda (aspr1),y
tax
lda odwr,x
sta buf2+8,y
lda (aspr2),y
tax
lda odwr,x
sta buf2,y
dey
bpl od4
bmi od8
od5 bpl od9
ldx #7
ldy #0
od6 lda (aspr1),y
sta buf2,x
lda (aspr2),y
sta buf2+8,x
iny
dex
bpl od6
lda aspr1+1
adc #4
sta aspr1+1
lda aspr2+1
adc #4
sta aspr2+1
dey
od7 inx
lda (aspr1),y
sta buf1,x
lda (aspr2),y
sta buf1+8,x
dey
bpl od7
od8 lda <buf1
sta aspr1
lda <buf1+8
sta aspr2
lda >buf1
sta aspr1+1
sta aspr2+1
* przetw.danych
od9 lda posx
and #3
tay
asl @
tax
lda atab1,x
sta zjmp1+1
lda atab1+1,x
sta zjmp1+2
lda maski,y
sta zmas1+1
eor #$ff
sta zmas2+1
lda #$ff
sta numl1
lda posy
lsr @
lsr @
lsr @
lsr @
tax
lda posx
lsr @
lsr @
clc
adc lscr,x
sta anascr
ldy numspr
sta (adrbuf),y
lda hscr,x
adc adrscr
sta anascr+1
tax
tya
clc
adc #21
tay
txa
sta (adrbuf),y
lda numspr
asl @
sta b1
asl @
adc b1
zm3 adc #0
sta poczn
jsr stznkk
jsr przep
lda posy
cmp #16
bcs zm51
ldy przes
zm31 lda #0
sta (adrbuf),y
iny
sta (adrbuf),y
iny
sta (adrbuf),y
iny
sty przes
jmp a1
zm51 lda #0
asl @
asl @
asl @
asl @
adc #16
ldx #6
cmp posy
beq a2
bcc a2
jsr wstaw
a1 clc
lda anascr
zm61 adc #0
sta anascr
bcc *+4
inc anascr+1
clc
lda poczn
adc #3
sta poczn
jsr stznkk
ldy #0
jsr przep2
zm52 lda #0
asl @
asl @
asl @
asl @
ldx #3
cmp posy
beq a2
bcc a2
jsr wstaw
jmp petla
a2 ldy przes
zm32 lda #0
sta (adrbuf),y
iny
dex
bne zm32+2
sty przes
jmp petla
exit jsr obraz
ldy #21
lda (adrbuf),y
beq i12
zm21 ldy #0
sty pr1
tya
asl @
sta pr2
asl @
adc pr2
adc #$2a
tax
lda adrbuf
sta i7+1
lda adrbuf+1
sta i7+2
i6 lda (adrbuf),y
sta b1
tya
clc
adc #21
tay
lda (adrbuf),y
sta b2
ldy #0
i7 lda $ffff,x
zm33 cmp #0
beq *+4
sta (b1),y
inx
iny
zm64 cpy #0
bcs i8
cpy #3
bne i7
tya
clc
zm63 adc #0
tay
bne i7
i8 txa
sbc #12
tax
dec pr1
ldy pr1
bpl i6
i12 jmp odchow
* przepisywanie danych
q1 jsr inc
bcc p2
przep3 ldy numl2
p2 lda (aznp1),y
sta (aznk1),y
lda (aznp2),y
sta (aznk2),y
lda (aznp3),y
sta (aznk3),y
iny
cpy #8
beq q1
cpy #16
bcc p2
rts
q3 lda aspr1
adc #$f7
sta aspr1
lda aspr1+1
adc #3
sta aspr1+1
lda aspr2
adc #$f8
sta aspr2
lda aspr2+1
adc #3
sta aspr2+1
bcc p4
q2 jsr inc
bcc q5
przep lda posy
and #15
sta numl3
ldy #0
cpy numl3
beq przep2
p1 lda (aznp1),y
sta (aznk1),y
lda (aznp2),y
sta (aznk2),y
lda (aznp3),y
sta (aznk3),y
iny
cpy #8
beq q2
q5 cpy numl3
bcc p1
przep2 sty numl2
inc numl1
ldy numl1
cpy #16
bcs przep3
cpy #8
beq q3
p4 lda (aspr2),y
sta pr2
lsr @
lda (aspr1),y
zjmp1 jmp $ffff
q4 jsr inc
bcc przep2
jmp5 ldx pr3
lda (aznp3),y
and msktab,x
ora pr3
sta (aznk3),y
ldx pr2
lda (aznp2),y
and msktab,x
ora pr2
sta (aznk2),y
ldx pr1
lda (aznp1),y
and msktab,x
ora pr1
sta (aznk1),y
iny
cpy #8
beq q4
cpy #16
bcc przep2
rts
jmp6 lda (aznp3),y
tax
lda pr3
and msktab,x
ora (aznp3),y
sta (aznk3),y
lda (aznp2),y
tax
lda pr2
and msktab,x
ora (aznp2),y
sta (aznk2),y
lda (aznp1),y
tax
lda pr1
and msktab,x
ora (aznp1),y
sta (aznk1),y
iny
cpy #8
beq q4
cpy #16
bcc przep2
rts
jmp1 ror @
ror pr2
ror @
ror pr2
jmp2 ror @
ror pr2
ror @
ror pr2
jmp3 ror @
ror pr2
ror @
ror pr2
jmp4 tax
zmas1 and #0
sta pr1
txa
ror @
zmas2 and #0
sta pr3
ldy numl2
zjmp2 jmp $ffff
inc lda aznp1
adc #$f7
sta aznp1
lda aznp1+1
adc #3
sta aznp1+1
clc
lda aznp2
adc #$f8
sta aznp2
lda aznp2+1
adc #3
sta aznp2+1
clc
lda aznp3
adc #$f8
sta aznp3
lda aznp3+1
adc #3
sta aznp3+1
clc
lda aznk1
adc #$f8
sta aznk1
lda aznk1+1
adc #3
sta aznk1+1
lda aznk2
adc #$f8
sta aznk2
lda aznk2+1
adc #3
sta aznk2+1
lda aznk3
adc #$f8
sta aznk3
lda aznk3+1
adc #3
sta aznk3+1
rts
* inne procedury
wstaw lda posx
ldx #$ff
a3 inx
cpx #6
beq a4
cmp scena,x
bcs a3
a4 lda msceny,x
ora invrs
asl @
asl @
asl @
asl @
sta invrs
ldy #0
ldx poczn
a5 lda (anascr),y
sty b1
ldy przes
asl invrs
php
bpl *+4
zm34 lda #0
sta (adrbuf),y
inc przes
ldy b1
txa
plp
bmi *+4
sta (anascr),y
inx
iny
cpy #3
bcc a5
rts
stznkk tax
lda hadrzn,x
ora adrzes
sta aznk1+1
lda hadrzn+1,x
ora adrzes
sta aznk2+1
lda hadrzn+2,x
ora adrzes
sta aznk3+1
lda ladrzn,x
sta aznk1
lda ladrzn+1,x
sta aznk2
lda ladrzn+2,x
sta aznk3
ldy #0
lda (anascr),y
tax
asl @
rol invrs
lda hadrzn,x
ora adrzes
sta aznp1+1
lda ladrzn,x
sta aznp1
iny
lda (anascr),y
tax
asl @
rol invrs
lda hadrzn,x
ora adrzes
sta aznp2+1
lda ladrzn,x
sta aznp2
iny
lda (anascr),y
tax
asl @
rol invrs
lda hadrzn,x
ora adrzes
sta aznp3+1
lda ladrzn,x
sta aznp3
rts
obraz lda $d40b
bpl obraz
zm7 ldx #0
zm8 ldy #0
lda clock
lsr @
bcc zma+2
zm9 ldx #0
zma ldy #0
stx $d402
stx $230
sty $d403
sty $231
zmc ldy #0
bcc zmb+2
zmb ldy #0
sty adrscr
zme ldy #0
zmd1 ldx #0
bcc zmd+4
zmd ldy #0
zme1 ldx #0
stx aktzes
sty adrzes
ldx <bufor1
ldy >bufor1
bcc *+6
ldx <bufor2
ldy >bufor2
stx adrbuf
sty adrbuf+1
inc clock
rts
chow ldx #$1e
lda anascr,x
sta przech,x
dex
bpl chow+2
rts
odchow ldx #$1e
lda przech,x
sta anascr,x
dex
bpl odchow+2
rts
*--- dane
scena dta d' '
msceny dta b(7),b(6),b(4),b(0)
dta b(1),b(3),b(7)
maski dta b($ff),b($3f),b(15),b(3)
zmtab dta a(zm1+1),a(zm2+1),a(zm3+1)
dta a(zmf+1),a(zm4+1),a(zm5+1)
dta a(zm6+1),a(zm7+1),a(zm8+1)
dta a(zm9+1),a(zma+1),a(zmb+1)
dta a(zmc+1),a(zmd+1),a(zme+1),a(0)
atab1 dta a(jmp4),a(jmp3)
dta a(jmp2),a(jmp1)
atab2 dta a(jmp5),a(jmp6)
buf1 org *+$10
msktab org *+$100
odwr org *+$100
ladrzn org *+$80
hadrzn org *+$80
bufor1 org *+$a8
lscr org *+$10
hscr org *+$10
przech org *+$28
buf2 org *+$10
bufor2 org *+$a8
*--- koniec
endp.s.
65816 i jego 16 bit rejestry są bardziej odpowiednie dla spritów programowych, może Vega stworzysz w końcu gre dla tego CPU
oftopicznie: koło naprawił mi monitor CTX-a w ten sposób że po zdjęciu obudowy powciskał wszystkie scalaki jakie były na płycie (dociskał aż skrzypiało) i ... monitor znowu działa :)
biedny chłopak chce narzucić swój punkt widzenia i nie może, ale zawsze może mieć ostatnie słowo, zawsze to coś
atari.area forum » Posty przez tebe
Wygenerowano w 0.094 sekund, wykonano 15 zapytań