No tebe - gratulacje. Rispekt.

"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

A ile zostaje z tej strony zerowej? No bo jakis player muzyki, sam MADS dla wywoływania procedur i sama gra potrzebują trochę miejsca na tej  stronie.

No i jeszcze PMG przykryje COLBAK (zwykle kolor czarny, żeby ramka była czarna). I tu pojawia się problem bo kolor czarny jest używany na planszy Bubble Bobble w dużej ilości jako tło:(

kiedy kolejny kod źródłowy? bo mnie w sumie to najbardziej interesuje:)

ja bym sprobowal, wolna strona zerowa, zajetej pamieci na duchy o polowe mniej, wada to "tylko" 13 duchow... moze warto?

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 ?

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

W sumie tylko to brakuje do doskonałości tego silnika, żeby sprite'y mogły mieć czarną obwódkę. To bardzo poprawia widoczność jeżeli mamy w tle jakiś rysunek.

Poza tym nieźle Co to wyszło Tebe:) Gratulacje.

http://mads.atari8.info/softsprt_OK.zip

wersja najnowsza, zoptymalizowana detekcja kolizji (rozpisane petle), inne poprawki

15 duchow 12x24 z detekcja / 3 ramki
18 duchow 8x24 z detekcja / 3 ramki

mamy x,y sprajta, w jaki sposob obliczane jest ktory znak i z ktorego zestawu ma byc brany za tlo dla sprajta ?

numer zestawu w zaleznosci od numeru wiersza czytany jest z tablicy pewnie, ale mi chodzilo o wpolrzedna x, czy jest ona dzielona, dodawany adres linii i na tej podstawie obliczany adres znaku tla? (ewentualnie tez czytana z tablic i dopiero pozniej korygowana o adres lini).
wlasciwie interesuje mnie to co nastepuje teraz, pobierany znak jest zapisywany w procedurze aby mogla ona dodac tlo do sprita?