Poniewaz znow jest wiele hipotez i niedomówien, to moze opiszę pokrótce jak chcę zorganizować pierwszy prosty frimeware graficzny i poproszę o komentarze.
Założenia:
1. TOMEK w kazdej ramce od nowa rysuje cały ekran, czyli najpierw tło a na nim wszystkie obiekty. Nie widzę sensu w zabawie w obliczenie które elementy się przesuneły względem ostatniego obrazu i które fragmenty trzeba odswiezac czy zamalowywac. Pojechanie po całosci bedzie szybsze.
2. Z małej ilosci pamięci (8KB a od tego odchodzą jeszcze 2 strony) wynika brak mozliwosci buforowania w większości przypadków. Czyli na początek zakładamy że cały obrac będzie rysowany w czasie miedzy zakonczeniem rysowania przez Antic ostatniej linii obrazu, a rozpoczęciem rysowania pierwszej linii kolejnego obrazu.
Jednak w przyszlosci będę chciał dodać tryb, w ktorym PIC ma dwie pamięci obrazu i w czasie kiedy rysuje na jednej to Anticowi podaje dane z drugiej, a w kolejnej ramce na odwrót. Moze sie to przydać do trybu $0D Antica (160x96 w 4 kolorach).
3. To czy dane dla Antica bedą podawane w trybie graficznym czy tekstowym, to kwestia niezależna od wewnętrznej reprezentacji obrazu, która bedzie zawsze graficzna. Jesli programista Atari zazyczy sobie trybu tekstowego to zmieni jedynie sposob podawania danych dla Antica.
Jest rozkaz: "definiuj tryb graficzny" gdzie podaje sie szerokosc ekranu, ilosc linii i tryb Antica. Obecnie cały ekran obslugiwany przez PIC musi byc w jednym trybie graficznym.
Ale pamietajmy ze dzieki Anticowi i display list, PIC nie musi obslugiwac calego ekranu! Mozna mu zlecic np generowanie tylko 140 linii na ktorych dzieje sie akcja, a np. panel umiescic gdzies w pamieci Atari w dowolnym trybie graficznym.
4. To jak bedzie rysowane tło jest niezalezne od dalszych operacji. Moze to byc statyczny obrazek (najszybsza opcja). Moze byc skladany z kafli o roznej wielkosci. Kwestie scrolla na razie zostawmy do dalszego zastanowienia.
5. Obiekty: tła, bitmapy i fonty będą skladowane w pamieci flash PIC'a. Zakladam ze będą mogly byc tam ladowane przez Atari. Na obiekty bedzie mozna wykorzystac od 66KB do 100KB.
6. Obiekt typu bitmapa moze miec szerokosc bedącą wiekokrotnoscia slowa (2 bajty) i dowolna ilosc linii.
7. Zamierzam zrobic obsluge duszków w formie podobnej do sprzętowych PMG. Liczba duszków będzie ograniczona do max 32 (oceniam ze to wystarczająca liczba, ale się do niej nie przywiązuję na razie). Będą rozkazy, służące do przypisania do duszka bitmapy, ustawienia go na pozycji X,Y itp. Te dane (nr bitmapy, x, y) bedą zapamiętywane w tablicy.
8. NAJWAZNIEJSZE: Schemat generowania obrazu przez Atari będzie wygladal tak:
Tuz po zakonczeniu rysowania ostatniej linii obrazu przez Antic, Atari zarzadza tlem: np wydaje rozkaz narysowania tla o numerze N z pamieci obiektow, albo rozkaz scrolla itp. Czeka na narysowanie tła. Pamiętajmy, że "czeka" to pojęcie umowne. Przeciez programista bedzie wiedzial co robi i ile mniej wiecej czasu PIC bedzie wykonywal te komendę. Atari moze w tym czasie wykonac cos pozytecznego, np wywolac player muzyki.
Po narysowaniu tła, Atari moze wydać rozkazy rysowania punktów, linii, innych figur geometrycznych, pisania tekstów itp itd. Wszystkie te polecenia będą wykonywane natychmiast.
Wydaje tez rozkazy przypisania obiektow do duszkow (np w celu animacji), zmiany ich pozycji itp.
Atari będzie mialo do dyspozycji również rozkaz "Rysuj obiekt N na pozycji X,Y". Ten rozkaz jest niezalezny od duszkow. Po prostu Tomek wezmie bitmape o wskazanym numerze i natychmiast naniesie ją na obraz w wybranym trybie (OR, AND, XOR, +maska). Po co to? Ano moim zdaniem nie ma sensu marnowac duszkow na jakies drobne obiekty typu pociski, linie lasera,
itp. Tym moze zarzadzac Atari kazac je rysowac w kazdej ramce.
Kolejny bardzo wazny rozkaz to "Rysuj duszki". Jesli duszkow bedzie 32, to ten rozkaz bedzie mial 4 bajty argumentow: po jednym bicie na duszka. 1 - duszek bedzie rysowany, 0 = duszek nie bedzie rysowany.
Ten rozkaz bedzie mozna wydawac wiele razy w ciągu rysowania jedbego obrazu.
Po co tak? Bo mozemy chciec najpierw narysowac jakies duszki będące na trzecim planie, uzupelniajace tlo o elementy ruchomer, pozniej naniesiemy "ręcznie rysowane" elementy, pociski, rysowane linie itp. A potem kolejnym rozkazem "rysuj duszki" naniesiemy obiekty pierwszoplanowe.
Innymi slowy, mozemy w ten sposob decydowac co na czym rysujemy.
9. Po przygotowaniu calego obrazu. Atari wydaje polecenie: "Generuj dane dla Antica". Od tego momentu PIC wie, ze jesli przyjdzie odczyt z "cwiartki $D5xx nalezacej do Antica" to ma podawac kolejno dane z pamieci ekranu w wybranym trybie.
10. Dzieki temu ze strone $D5 podzielilismy na obszary, w czasie kiedy Antic generuje obraz, program Atari moze jednoczesnie bez konfliktow korzystac z uslug PIC'a, np wydajac rozkazy operacji matematycznych czy inne. Moze nawet wydawac rozkazy wplywajace na pamiec obrazu, ale trzeba pamietac, ze moze to byc "brzydko widac".
I to tyle w duzym skrocie.
tebe napisał/a:a jak wygląda kwestia detekcji kolizji? jakoś wspomagana czy bez wspomagania?
Nie wygląda. Nie mam na razie pojecia jak to zrobic, a wszystkie metody jakie jestem w stanie wymyslic wydaja mi sie koszmarnie niewydajne szczegolnie przy 32 duszkach.
Choc mysle ze prawdziwie przydatne byloby wychwytywanie nie kolizji "kazdy z kazdym" ale kolizji miedzy 2 obiektami (np. statki 2 graczy) a calą resztą obiektow i tlem.
Ale i tak na razie jest to dla mnie piesn przyszlosci. Outsoursing zakodowania tego bedzie mile widziany :)
Ostatnio edytowany przez nosty (2012-09-08 01:05:06)
