Dziś króciutka część druga - zróbmy sobie szkielet programu.
Skoro powiedziało się A, trzeba powiedzieć B. Póki co tylko cztery osoby sprawdziły dyskietki, ale dla tych czterech już warto. Zastanowimy się dzisiaj, jak powinien wyglądać sam szkielet programu, aby spełniał wymogi gry.Przewrotnie dziś nie dołącze działającej dyskietki, ale napiszę co i jak robimy (sprytni przekleją kod w emulatorze, ale polecam samodzielne pisanie, aby coś zostało).
Dobre zasady programowania na Atari mówią, że należy obniżyć tak zwany RAMTOP pamięci, czyli maksymalne miejsce, gdzie może znaleźć się program (komórka pamięci 106). Muszę się Wam przyznać, że... Ja tego nie robię ;) Póki co nie zawiodłem się na mojej metodzie, więc będę ją promował - ale jakby ktoś chciał skorzystać z niej, nic nie stoi na przeszkodzie. Trzeba tylko pamiętać - że po obniżeniu RAMTOPu zmienia nam się diametralnie adres ekranu, lądując odpowiednio niżej. A dobre umiejscowienie danych w programie to połowa sukcesu. Ja po prostu umieszczam dane w odpowiednich adresach - przy tym posługuję się pewną specyfiką TBXL, a mianowicie - podaję adresy danych w kodzie szesnastkowym (po prostu liczbę w kodzie szesnastkowym traktujemy prefixem, czyli przedrostkiem, w formie znaku "$"). Dzięki temu łatwiej jest mi korzystać z dobrodziejstw większości programów użytkowych na Atari. Dlaczego - przekonacie się sami w dalszych częściach tutoriala.
Z autopsji i wielu prób wiem (nie zdarzyło mi się wywalić programu), że bezpiecznym maksymalnym adresem, do jakiego należy wrzucać dane - to $A035. Od lat właściwie wrzucam fonty pod adres $9C00, po dodaniu wartości 1024 bajtów łatwo się zorientować, że są to tak zwane cztery strony pamięci - font kończy się pod adresem $9fff. Tu jedna uwaga - fonty zawsze należy wrzucać na granicy strony (256 bajtów), aby łatwiej go potem wyświetlić bez kombinowania - czyli zawsze zachowujmy schemat $xx00, gdzie xx jest numerem strony. Łatwo to potem wykorzystamy, co zaraz pokażę. Proszę o wczytanie TBXL.
Uważny czytelnik powie: "zaraz, zaraz, a te kilka pozostałych bajtów między $9fff a $A035?". Czasem tam wciskam drobne dane, czasem pozostaje nieruszane...
Dobrze, przejdźmy do konkretów. Ustalamy, że nasze fonty będą siedziały pod adresem $9c00 - moje przyzwyczajenie. Jak je wczytać pod TBXL? Pokażę trzy metody, wraz z krótkim komentarzem do nich. Za każdym razem korzystamy z krótkiego kodu. Załóżmy, że nasze fonty nazywają się "POLSKIE.FNT" i są w stacji identyfikującej się jako "D:". Możemy je wczytać następująco:
1. Metoda podstawowa, według mnie najgorsza, za każdym razem przed wczytaniem programu lub po nim wpisujemy kod:
O.#1,4,0,"D:POLSKIE.FNT":BGET#1,$9C00,1024:CL.
Pokrótce opiszę, co się dzieje:
- otwieram kanał nr 1 do odczytu i ustawiam na plik z fontem
- używam instrukcji TBXL BGET, która pobiera odpowiednią ilość bajtów pod wskazany adres. Za broszurą Blukiego "Turbo Basic XL 1.5 Nowe Polecenia z przykładami" podaje składnię (Uwaga! Jeśli będę podawał skłądnię jakiegoś polecenia - będę się podpierał tą pozycją, nie dlatego, że nie znam zastosowania, tylko dlatego, że jestem leniwy i mogę coś przekleić, a tu jest po polsku):
Turbo Basic XL 1.5 Nowe Polecenia z przykładami napisał/a:
BGET #n,adres,ilość – pobiera z kanału (o numerze n) ciąg bajtów i zapisuje go w pamięci od wskazanego adresu. Ilość określa liczbę bajtów jaka ma być pobrana i zapisana. Przed użyciem BGET należy pamiętać o otwarciu do odczytu jednego z bloków IOCB.
- na koniec zamykam otwarty kanał (dobra praktyka)
Według mnie jest to najgorsza metoda, wymaga każdorazowego wpisywania po każdym uruchomieniu TBXL.
2. Nieco "poprawiona" poprzednia metoda. Zamykamy wszystko w procedurze - ponieważ tam możemy jednorazowo wczytywać różne dane, nazwijmy ją po prostu WCZYTYWANIE. Procedury zaczynają się od słowa PROC i kończą słowem ENDPROC, dodatkowo każda ma swoją unikalną nazwę (nie mogącą być słowem kluczowym TBXL) i można ją wywołać bezpośrednio z programu lub edytora. Proszę o przepisanie kodu:
1000 PROC WCZYTYWANIE
1001 O.#1,4,0,"D:POLSKIE.FNT":BGET#1,$
9C00,1024:CL.
1002 ENDPROC
Tak zapisaną procedurę należy jednokrotnie wywołać poprzez polecenie EXEC nazwa_procedury, bądź bezpośrednio z edytora, bądź z programu. Proponuję tą drugą metodę, dopiszmy linijkę (na początku programu):
Teraz uruchamiamy program (RUN) i co? Otrzymujemy błąd! (takie było moje zamierzenie). Przypominam, że każdy program BASICowy (w tym program w TBXL) działa sekwencyjnie, linia po linii - o ile nie sterujemy przebiegiem programu - i kończy się kluczowym słowem end. Dopiszmy sobie linię kodu:
Uruchamiamy i nie mamy błędu. Ale nic się nie dzieje. Tak ma być - proponuję zapisać program jako TESTFNT.TB. Teraz wpisujemy POKE 756,$9C - zmieniając tym samym zestaw znaków. Musimy go wskazać zawsze po zmianie trybu graficznego - sprawdźmy, czy działa (polskie litery z control, przecinek zamieniony z średnikiem). Jest ok? To teraz gr.0 i ponownie polskie znaki. Nie ma? Nie ma... Poke 756,$9c.
Mały test - napiszmy w edytorze:
Co uzyskaliśmy? Liczbę 156 - czyli nasze znaki znajdują się na 156 stronie pamięci. Gr.0 i poke 756,156 - są polskie znaki? Są. Zapis poprzedni jest tożsamy, tylko dana podana dziesiętnie. A teraz zwróćcie uwagę na jedno - jak wczytywaliśmy nasz font? Przypomnę:
Łatwe do zapamiętania? Łatwe. A teraz: jeśli zamiast $9C00 zapiszemy 39936 - co łatwiej zapamiętać? Dlatego ja używam adresów zapisanych szesnastkowo.
3. Ostatnia metoda, preferowana przeze mnie - to wykonanie osobnego pliku binarnego z danymi (różnymi). Na początek musimy taki plik wykonać - póki co z samymi fontami. Ja wykorzystuję do tego Super Packera, teraz po kolei:
- wychodzimy do DOS
- z dyskietki z narzędziami wczytujemy Super Packera (SP**)
- wczytujemy nasz font (opja F - load data file)=>POLSKIE.FNT
- podświetla nam się adres - wpisujemy 9C00
- zapisujemy jako DANE.DAT: S=>DANE.DAT
- wychodzimy do DOS
- wczytujemy TBXL i wpisujemy w edytorze:
POKE 756,$9c i cieszymy się wgranymi danymi (póki co fonty, ale będzie tam tego więcej z czasem). Co zrobiliśmy? Przygotowalićmy sobie plik binarny z danymi, do dalszego wykorzystania - który potem będzie idealny także do zrobienia wersji file naszego programu. W tym wypadku zacznijmy sobie tworzyć plik/notatki z danymi naszego programu, aby wiedzieć - co gdzie będzie. Dołączę do tutorialu plik tekstowy z notatnika - DANE.TXT. Będziemy go sukcesywnie uzupełniać.
Na zakończenie tej części tutoriala zastanówmy się, co nasza gra powinna mieć? Póki co zaproponuję bardzo uproszczony szkielet, który będziemy potem modyfikować/uzupełniać. Ponieważ tutorial jest pisany na bieżąco - pewne elementy mogą się zmieniać, byc modyfikowane w trakcie. Proszę o ewentualne uwagi na bieżąco.
Osobiście lubię, jak gra ma jakiś początek i koniec. Musi też być obsługa gry, najprostszy szkielet gry, który możemy stworzyć, mógłby wyglądać tak (proszę go wpisać):
50 EXEC INTRO:.WYWOLANIE INTRA
51 EXEC START:.WYWOLANIE GRY
90 END
99 --
100 PROC INTRO
101 GR.24:POKE710,0:POKE709,15:poke756
,$9c
102 COLOR %1:TEXT 10,10,"Tu będzie intro"
150 IF PEEK(53279)<>6 THEN 150
190 ENDPROC
199 --
200 PROC START
201 .TU ZEROWANIE DANYCH
202 EXEC PARAGRAFY
290 ENDPROC
299 --
300 PROC PARAGRAFY
340 ENDPROC
Zapiszmy całość jako GRA0.TB - osobiście przy większych poprawkach zmieniam numer, mogąc w razie czego wrócić do dalzego działania w przypadku namotania w kodzie. Spróbujcie sami przeanalizować ten szablon, w razie problemów - postaram się odpowiedzieć na pytania w postach.
======================================
Jak zwykle proszę o komentarze i pytania. Jednocześnie mam pytanie - znajdzie się litościwy grafik (może być na PC) i muzyk (CMC pilnie poszuiwany)?