http://mads.atari8.info/softsprt_OK_18.08.06.zip

wersja z detekcja kolizji, z mruganiem i bez (mruganie tła sygnalizuje wykryta kolizje)

13 duchow 12x24 / 3 ramki
16 duchow 8x24 / 3 ramki

ogolnie detekcja kolizji wykonana dla kazdego ducha zmniejsza maksymalna liczbe generowanych w 3 ramkach duchow do 13 (bez detekcji 17)

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.

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

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

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

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

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

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

BTC scena nie zna ograniczeń

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+$400

program 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

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

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

ten zasilacz ATX jest mniejszy http://www.allegro.pl/show_item.php?item=118296568

obejrzyjcie sobie gre POOYAN, jest na znakach

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)