"Space Travel" po latach by TDC 2010-05-11 17:08:01
Tomasz "TDC" Cieślewicz napisał:
1. Kulisy powstania
Gra powstała na potrzeby pisma "Atari Magazyn" w 1994 roku. Jako osoba zajmująca się w redakcji językiem "Action!", przygotowałem szereg artykułów o tym języku, niestety większość z nich ostatecznie nie została opublikowana. Ale co się odwlecze to nie uciecze...
"Atari Magazyn" był pismem Wydawnictwa Bajtek, więc zgodnie z kanonem starych, dobrych czasów - przygotowałem także źródło programu do wklepania. Efektem listingu miała być dość dynamiczna gra, odwołująca się do takich tytułów jak "Zybex", "Uridium", "R-type" czy "Warhawk". Oczywiście gra była znacznie prostsza i z powodów objętościowych pisma oparta o grafikę symboliczną.
Celem artykułu było popularyzowanie "Action!" jako języka świetnie nadającego się do programowania gier. Kod został napisany dość czytelnie, z wieloma uproszczeniami, aby czytelnik mógł łatwo poznać sposób tworzenia gier. Redaktor naczelny pisma nie był jednak zadowolony z tego, że dużą część pisma miałby zająć listing programu, którym mają się "katować" czytelnicy. Zaproponowałem, aby program był dostępny na redakcyjnym BBS-ie (powszechnego internetu wtedy jeszcze nie było) albo na dyskietce do pisma, którą już wcześniej sugerowali na przykład redaktorzy odpowiedzialni za duże Atari. Jednak wszystko wskazywało na to, że kierownictwo Wydawnictwa Bajtka nie zgodzi się na taki drogi dodatek. I rzeczywiście, pismu "AM" nigdy nie towarzyszyły dyskietki.
.png)
.png)
2. Opis źródła gry
W starym źródle, jakie znalazłem (wersja 0,8), widać wyraźnie, że zależało mi na przejrzystości i czytelności kodu, wiele rzeczy było realizowanych w prosty sposób, bez optymalizacji wydajności, aby nie zaciemniać kodu dla czytelników. Przykładem uproszczeń jest brak obsługi 8 kierunków ruchów joystickiem czy niezmazywanie przeciwników z ekranu. Ze względu na dość dużą liczbę skomentowanych instrukcji w źródle (czyli chwilowo wyłączonych) zakładam, że wersja 0,8 nie jest ostatnią, jaka powstała. Jest to jednak jedyna wersja, jaką znalazłem. Postanowiłem uzupełnić brakujące elementy, takie jak kolizje z przeciwnikami, straty życia, strzelających przeciwników i niniejszym zaprezentować jako przykład gry w "Action!", dla osób które śledzą na AtariOnline.pl artykuły dotyczące nauki tego języka. Poniżej wersja 1.4.
Uważni obserwatorzy zorientują się, że gra jest podobna do niedawno publikowanego "Tomcata". I będą mieli rację, to właśnie na bazie niniejszego kodu powstała gra na Grzybsoniadę. Można więc elementy kodu skonfrontować ze źródłami nowej gry i przekonać się, że po niewielkiej optymalizacji wszystko faktycznie działa szybciej. "Space Travel" wykorzystuje prawie całą wydajność małego Atari, a przecież "Tomcat" jest znacznie bardziej zaawansowany.
Opis zmiennych i tablic globalnych:
Podstawowe zmienne dla gracza oraz dla przeciwników:
BYTE A,B,C,C1,D,E,E1,F,EE,OPE
A i B to współrzędne gracza x i y.
C1, C i D to zmienne wykorzystywane w strzałach gracza (procedura LUDZSTR() )
E, E1, F i EE – zmienne związane z kolejnymi przeciwnikami
E i F to współrzędne przeciwników x i y
E1 to stan aktualnego przeciwnika (istnieje, nie istnieje, wybucha itp.)
EE to zmienna wskazująca indeks w tablicy, czyli aktualnego przeciwnika (np. procedura PRZECMEN() )
OPE – to licznik ramki, w której animowany jest konkretny przeciwnik
,BX,BY,B1,B2,BC,BD,BC1,BB,WYB,WY2
BX, BY... to zmienne związane z bossem na końcu etapu (np. x i y itp.)
BC, BD, BC1 – to zmienne sterujące dużym promieniem jakim strzelają bossowie
BB zmienna sterująca wyświetlaniem promienia
WYB – zmienna sterująca dźwiękami wybuchów po trafieniu w przeciwnika
WY2 – zmienna pomocnicza do dźwięków wybuchów
,Q1,Q2,Q3,Q4,Q5
Zmienne pomocnicze wykorzystywane w różnych częściach programu (np. sterowanie pętlami, danymi itp.)
,ZYC,LEVEL
Aktualna ilość żyć oraz poziom gry.
,P1,P2,P3,P4
Punkty gracza, każda zmienna odpowiada za kolejną potęgę 10. Takie rozwiązanie jest bardzo wydajne bo nie wykorzystuje arytmetyki 16 bitowej oraz bibliotecznej procedury PRINT
,ILP,ILZP,BAZA,POW,ILP1
ILP, ILZP, ILP1 - maksymalna ilość przeciwników w grze, ilość przeciwników zliczonych w danej planszy, ilość zestrzelonych przeciwników. Porównanie ostatnich wartości pozwala stwierdzić sprawność gracza, co oczywiście wiąże się z dodatkowym bonusem.
BAZA – czy rozgrywka jest w trybie walki z bossem czy nie
POW – ilość energii bossa (wzrasta wraz z każdym zakończonym poziomem gry)
,K=764,KON=53279,JO=$278,FIRE
Zmienne przypisane rejestrom:
K – obsługa klawiatury. Przechowuje ostatni naciśnięty klawisz oraz ew. wymusza rodzaj klawisza.
KON – klawisze funkcyjne
JO – obsługa joysticka w pierwszym porcie. Oczywiście zamiast tego rozwiązania można użyć zwykłej bibliotecznej funkcji STICK(n) - zrezygnowałem z niej po sygnałach od Sikora, że funkcja ta potrafi nieprawidłowo działać (z runtimem) na real Atari.
FIRE – zmienna sterująca strzelaniem gracza
,RND=$D20A
RND – sprzętowy generator liczb losowych
CARD CZAS,CZMAX
Odliczają czas rozgrywki, gdy czas się skończy (CZMAX), kończy się etap gry i rozpoczyna się walka z bossem.
Tablice:
1. parametry kolejnych przeciwników (współrzędne x, y i stan):
BYTE ARRAY PRZECE
BYTE ARRAY PRZECF
BYTE ARRAY PRZECE1
2. parametry kolejnych strzałów gracza:
BYTE ARRAY STRX
BYTE ARRAY STRY
BYTE ARRAY STR1
3. parametry kolejnych strzałów przeciwników:
BYTE ARRAY PSX
BYTE ARRAY PSY
BYTE ARRAY PS1
Nowe zmienne dodane do kodu w wersji 0,9:
BYTE PSM,PSI
PSM – maksymalna ilość pocisków przeciwników jakie może obsłużyć gra
PSI – zmienna pomocnicza wskazująca pierwszy wolny (teoretycznie) indeks w tablicy pocisków przeciwników.
BYTE TRU
Zmienna, która wskazuje aktualny poziom trudności w grze. Wzrasta stopniowo wraz ze zmienną LEVEL. Jednak ta ostatnia zmienna odpowiada za wyświetlanie odpowiedniej wartości na ekranie, natomiast TRU jest wykorzystywane bezpośrednio w algorytmach dotyczących poziomu trudności rozgrywki. Od tej zmiennej zależy przykładowo ilość wystrzeliwanych (i czy w ogóle) pocisków przez przeciwników.
Procedury w grze:
PROC TX(BYTE X,Y BYTE ARRAY T)
Dość szybka procedura wyświetlająca na ekranie ciąg znaków. W grze wykorzystywana jest intensywnie do odrysowywania na ekranie postaci gracza oraz przeciwników. Napisana jest w sposób czytelny, ale nie maksymalnie wydajny (jednak jak na kluczową procedurę graficzną - jest wystarczająco wydajna). Wadą tej procedury jest zmienianie znaków pomiędzy kodami ekranowymi oraz znakami ATASCI, pokrywają się np. małe litery i dla czytelności kodu, najczęściej napisy w grze są pisane małymi literami.
PROC PO(BYTE X,Y BYTE ARRAY T)
Procedura pomocnicza łącząca dwie procedury biblioteczne Action! Nie są potrzebne bo wszystko można zrobić za pomocą TX, jednak tu zostały użyte dla większej czytelności kodu źródłowego.
PROC RYSPRZ(BYTE X,Y)
Rysowanie przeciwnika w podanych współrzędnych x i y.
PROC RYSWYB(BYTE X,Y)
Rysowanie wybuchu w podanych współrzędnych x i y.
PROC LUDZ(BYTE X,Y)
Rysowanie pojazdu gracza w podanych współrzędnych x i y.
PROC RYSBAZ(BYTE X,Y)
Rysowanie trzech różnych faz bossa (Bazy) w podanych współrzędnych x i y.
PROC SOUWY()
Generowanie różnych rodzajów odgłosów trafienia przeciwników
PROC REKLAMOWKA()
Czołówka gry SPACE TRAVEL, wyświetlenie napisów oraz obsługa klawiatury.
PROC RYNCHR()
Wykorzystywana w różnych miejscach kodu procedura w asemblerze synchronizująca wykonywanie kodu gry z początkiem generowania obrazu przez procesor graficzny.
PROC RUCHYJO()
Obsługa ruchów joystickiem oraz rysowanie pojazdu gracza.
PROC LUDZSTR()
Animowanie kolejnych pocisków gracza.
Procedura ponownie definiuje zmienną pomocniczą Q1, jednak tym razem jest to zmienna lokalna. Jest to niezbędny zabieg, gdyż zmienna globalna Q1 jest wykorzystywana w innych miejscach kodu, który wywołuje procedurę LUDZSTR(). Dzięki temu ta sama zmienna nie jest modyfikowana w różnych miejscach kodu i program działa prawidłowo.
PROC RYSZYC()
Odrysowanie na ekranie aktualnej ilości żyć.
PROC RYSPUN()
Zoptymalizowana procedura zliczająca punkty (specyficzna arytmetyka na 4 bajtach) i wyświetlająca je na ekranie. Odpowiada także za bonusowe życia.
PROC OPGR()
Odrysowanie elementów ekranu gry.
PROC PRZECSTR()
Poruszanie i animowanie pocisków przeciwników
Procedura definiuje lokalną zmienną pomocniczą Q1, podobnie jak ma to miejsce w procedurze LUDZSTR().
PROC PRZECWYB()
Wyświetlenie wszystkich wybuchających przeciwników (w kolejnych fazach animacji).
PROC PRZECMEN()
Generowanie, animowanie przeciwników oraz losowanie czy dany przeciwnik ma strzelić. Wyjaśnienia wymaga zapis „IF RND > 200 & RND < TRU THEN (...)”, dzięki temu, że generator losowy jest na Atari zrealizowany sprzętowo (i to na dobrym poziomie w stosunku do innych komputerów od ZX Spectrum zaczynając a na pecetach kończąc), jest to bardzo prosty zapis dwóch losowań w oparciu o 8 bitową wartość. Jedno losowanie nie jest wystarczające, dlatego po spełnieniu pierwszego warunku, losowanie odbywa się drugi raz (z uwzględnieniem aktualnego poziomu trudności – zmienna TRU) i dopiero po spełnieniu obu warunków może zostać wygenerowany strzał.
Jest to prosty zapis realizujący tą istotną dla rozgrywki funkcję. Jest też bardzo szybki, bo wykorzystuje możliwości sprzętowe Atari oraz nie wykonuje skoku do bibliotecznej procedury RAND(), która do najszybszych nie należy (jest ona użyta w innym miejscu programu dla zobrazowania funkcjonalności obu rozwiązań).
PROC CZARY(BYTE X,Y)
Generuje animację opartą o wartości losowe, ma to obrazować efekt przejścia pomiędzy wymiarami dokonywanego przez bossa.
Dodatkowo kod wykorzystuje w innym celu zmienną POW, a mianowicie jako zmienną pomocniczą. Związane jest to z tym, że ta procedura wykorzystuje wszystkie dostępne zmienne pomocnicze od Q1 do Q5. Zgodnie z chętnie stosowaną w programowaniu zasadą brzytwy Ockhama, została tu zminimalizowana ilość zmiennych wykorzystywanych w programie.
PROC ZERTAB()
Zerowanie kluczowych tablic gry.
PROC NEXTLEV()
Przejście do kolejnego etapu gry. Wyświetlenie stosownych napisów, ustawienie parametrów rozgrywki (np. zwiększenie poziomu trudności itp.).
PROC STRATAZYC(BYTE X)
Procedura realizująca wszystkie niezbędne operacje związane ze stratą życia. Parametr x, umożliwia przekazanie przez algorytmy miejsca, w którym został trafiony gracz. Następnie w tym miejscu rysowany jest wybuch i zatrzymywana jest akacja gry. Początkujący programiści gier powinni prześledzić w jaki sposób jest zrealizowane to, że procedura odpowiedzialna za rysowanie tylko wybuchających przeciwników zostaje tutaj zaadoptowana do wyświetlenia dodatkowego wybuchu, który tutaj nie jest (wyjątkowo) związany z przeciwnikami.
PROC DANEPOCZ()
Ustawia wartości początkowe wszystkich istotnych zmiennych dla rozgrywki – jest to swoiste zresetowanie gry.
PROC GRA()
Główna pętla gry: poruszanie się gracza, generowanie efektów dźwiękowych, strzelanie gracza, algorytmy obu typów przeciwników, kolizje, odliczanie czasu gry, obsługa klawiatury, zakończenie gry gdy ilość żyć równa jest zero oraz odrysowanie związanego z tym ekranu końcowego gry.
Zawiera również początkowe odrysowanie ekranu w momencie rozpoczęcia gry.
PROC MAIN()
Pierwsza uruchamiana procedura w programie, która rozpoczyna się od ustalenia stałych parametrów dla pocisków przeciwników (są to parametry programu a nie gry, więc nie zmieniają się one w dalszej części programu – ich zmiana może doprowadzić do zawieszenia się programu). Następnie w pętli uruchamiane są naprzemiennie procedury REKLAMOWKA() oraz GRA(), zapewniając ciągłość tych dwóch niezbędnych w każdej grze elementów.
3. Listing programu
Plik ACT wspomnianej wersji dostępny tutaj. Właściwie każdy algorytm funkcjonujący w tej grze da się znacznie przyspieszyć, nawet w samym "Action!", czyli bez najmniejszych wstawek asemblera. Zachęcam do prób osoby, które chcą nabrać biegłości w optymalizacji :).
Każdego kto zechce samodzielnie przygotować wersję samouruchamialną (plik XEX), przestrzegam, że to konkretne źródło jest niestabilne po wykorzystaniu "Action! Library". Wcześniej nigdy nie miałem z tym podobnych problemów, nie wnikam dlaczego tak się dzieje, ale jestem mocno zdziwiony, bo kod jest niezwykle prosty i nie wykorzystuje nic szczególnego.
4. Gotowa gra
Nie ma jednak rzeczy niemożliwych, udało się przygotować skompilowaną wersję :). Z katalogu gier AOL można ściągnąć plik XEX z gotową wersją "Space Travel". Gra nie wymaga opisu poza informacją, że klawiszem Esc można zakończyć grę, a w "Action!" klawiszem SELECT. Miłego giercowania i zmagań z "Action!".
.png)
1. Kulisy powstania
Gra powstała na potrzeby pisma "Atari Magazyn" w 1994 roku. Jako osoba zajmująca się w redakcji językiem "Action!", przygotowałem szereg artykułów o tym języku, niestety większość z nich ostatecznie nie została opublikowana. Ale co się odwlecze to nie uciecze...
"Atari Magazyn" był pismem Wydawnictwa Bajtek, więc zgodnie z kanonem starych, dobrych czasów - przygotowałem także źródło programu do wklepania. Efektem listingu miała być dość dynamiczna gra, odwołująca się do takich tytułów jak "Zybex", "Uridium", "R-type" czy "Warhawk". Oczywiście gra była znacznie prostsza i z powodów objętościowych pisma oparta o grafikę symboliczną.
Celem artykułu było popularyzowanie "Action!" jako języka świetnie nadającego się do programowania gier. Kod został napisany dość czytelnie, z wieloma uproszczeniami, aby czytelnik mógł łatwo poznać sposób tworzenia gier. Redaktor naczelny pisma nie był jednak zadowolony z tego, że dużą część pisma miałby zająć listing programu, którym mają się "katować" czytelnicy. Zaproponowałem, aby program był dostępny na redakcyjnym BBS-ie (powszechnego internetu wtedy jeszcze nie było) albo na dyskietce do pisma, którą już wcześniej sugerowali na przykład redaktorzy odpowiedzialni za duże Atari. Jednak wszystko wskazywało na to, że kierownictwo Wydawnictwa Bajtka nie zgodzi się na taki drogi dodatek. I rzeczywiście, pismu "AM" nigdy nie towarzyszyły dyskietki.
2. Opis źródła gry
W starym źródle, jakie znalazłem (wersja 0,8), widać wyraźnie, że zależało mi na przejrzystości i czytelności kodu, wiele rzeczy było realizowanych w prosty sposób, bez optymalizacji wydajności, aby nie zaciemniać kodu dla czytelników. Przykładem uproszczeń jest brak obsługi 8 kierunków ruchów joystickiem czy niezmazywanie przeciwników z ekranu. Ze względu na dość dużą liczbę skomentowanych instrukcji w źródle (czyli chwilowo wyłączonych) zakładam, że wersja 0,8 nie jest ostatnią, jaka powstała. Jest to jednak jedyna wersja, jaką znalazłem. Postanowiłem uzupełnić brakujące elementy, takie jak kolizje z przeciwnikami, straty życia, strzelających przeciwników i niniejszym zaprezentować jako przykład gry w "Action!", dla osób które śledzą na AtariOnline.pl artykuły dotyczące nauki tego języka. Poniżej wersja 1.4.
Uważni obserwatorzy zorientują się, że gra jest podobna do niedawno publikowanego "Tomcata". I będą mieli rację, to właśnie na bazie niniejszego kodu powstała gra na Grzybsoniadę. Można więc elementy kodu skonfrontować ze źródłami nowej gry i przekonać się, że po niewielkiej optymalizacji wszystko faktycznie działa szybciej. "Space Travel" wykorzystuje prawie całą wydajność małego Atari, a przecież "Tomcat" jest znacznie bardziej zaawansowany.
Opis zmiennych i tablic globalnych:
Podstawowe zmienne dla gracza oraz dla przeciwników:
BYTE A,B,C,C1,D,E,E1,F,EE,OPE
A i B to współrzędne gracza x i y.
C1, C i D to zmienne wykorzystywane w strzałach gracza (procedura LUDZSTR() )
E, E1, F i EE – zmienne związane z kolejnymi przeciwnikami
E i F to współrzędne przeciwników x i y
E1 to stan aktualnego przeciwnika (istnieje, nie istnieje, wybucha itp.)
EE to zmienna wskazująca indeks w tablicy, czyli aktualnego przeciwnika (np. procedura PRZECMEN() )
OPE – to licznik ramki, w której animowany jest konkretny przeciwnik
,BX,BY,B1,B2,BC,BD,BC1,BB,WYB,WY2
BX, BY... to zmienne związane z bossem na końcu etapu (np. x i y itp.)
BC, BD, BC1 – to zmienne sterujące dużym promieniem jakim strzelają bossowie
BB zmienna sterująca wyświetlaniem promienia
WYB – zmienna sterująca dźwiękami wybuchów po trafieniu w przeciwnika
WY2 – zmienna pomocnicza do dźwięków wybuchów
,Q1,Q2,Q3,Q4,Q5
Zmienne pomocnicze wykorzystywane w różnych częściach programu (np. sterowanie pętlami, danymi itp.)
,ZYC,LEVEL
Aktualna ilość żyć oraz poziom gry.
,P1,P2,P3,P4
Punkty gracza, każda zmienna odpowiada za kolejną potęgę 10. Takie rozwiązanie jest bardzo wydajne bo nie wykorzystuje arytmetyki 16 bitowej oraz bibliotecznej procedury PRINT
,ILP,ILZP,BAZA,POW,ILP1
ILP, ILZP, ILP1 - maksymalna ilość przeciwników w grze, ilość przeciwników zliczonych w danej planszy, ilość zestrzelonych przeciwników. Porównanie ostatnich wartości pozwala stwierdzić sprawność gracza, co oczywiście wiąże się z dodatkowym bonusem.
BAZA – czy rozgrywka jest w trybie walki z bossem czy nie
POW – ilość energii bossa (wzrasta wraz z każdym zakończonym poziomem gry)
,K=764,KON=53279,JO=$278,FIRE
Zmienne przypisane rejestrom:
K – obsługa klawiatury. Przechowuje ostatni naciśnięty klawisz oraz ew. wymusza rodzaj klawisza.
KON – klawisze funkcyjne
JO – obsługa joysticka w pierwszym porcie. Oczywiście zamiast tego rozwiązania można użyć zwykłej bibliotecznej funkcji STICK(n) - zrezygnowałem z niej po sygnałach od Sikora, że funkcja ta potrafi nieprawidłowo działać (z runtimem) na real Atari.
FIRE – zmienna sterująca strzelaniem gracza
,RND=$D20A
RND – sprzętowy generator liczb losowych
CARD CZAS,CZMAX
Odliczają czas rozgrywki, gdy czas się skończy (CZMAX), kończy się etap gry i rozpoczyna się walka z bossem.
Tablice:
1. parametry kolejnych przeciwników (współrzędne x, y i stan):
BYTE ARRAY PRZECE
BYTE ARRAY PRZECF
BYTE ARRAY PRZECE1
2. parametry kolejnych strzałów gracza:
BYTE ARRAY STRX
BYTE ARRAY STRY
BYTE ARRAY STR1
3. parametry kolejnych strzałów przeciwników:
BYTE ARRAY PSX
BYTE ARRAY PSY
BYTE ARRAY PS1
Nowe zmienne dodane do kodu w wersji 0,9:
BYTE PSM,PSI
PSM – maksymalna ilość pocisków przeciwników jakie może obsłużyć gra
PSI – zmienna pomocnicza wskazująca pierwszy wolny (teoretycznie) indeks w tablicy pocisków przeciwników.
BYTE TRU
Zmienna, która wskazuje aktualny poziom trudności w grze. Wzrasta stopniowo wraz ze zmienną LEVEL. Jednak ta ostatnia zmienna odpowiada za wyświetlanie odpowiedniej wartości na ekranie, natomiast TRU jest wykorzystywane bezpośrednio w algorytmach dotyczących poziomu trudności rozgrywki. Od tej zmiennej zależy przykładowo ilość wystrzeliwanych (i czy w ogóle) pocisków przez przeciwników.
Procedury w grze:
PROC TX(BYTE X,Y BYTE ARRAY T)
Dość szybka procedura wyświetlająca na ekranie ciąg znaków. W grze wykorzystywana jest intensywnie do odrysowywania na ekranie postaci gracza oraz przeciwników. Napisana jest w sposób czytelny, ale nie maksymalnie wydajny (jednak jak na kluczową procedurę graficzną - jest wystarczająco wydajna). Wadą tej procedury jest zmienianie znaków pomiędzy kodami ekranowymi oraz znakami ATASCI, pokrywają się np. małe litery i dla czytelności kodu, najczęściej napisy w grze są pisane małymi literami.
PROC PO(BYTE X,Y BYTE ARRAY T)
Procedura pomocnicza łącząca dwie procedury biblioteczne Action! Nie są potrzebne bo wszystko można zrobić za pomocą TX, jednak tu zostały użyte dla większej czytelności kodu źródłowego.
PROC RYSPRZ(BYTE X,Y)
Rysowanie przeciwnika w podanych współrzędnych x i y.
PROC RYSWYB(BYTE X,Y)
Rysowanie wybuchu w podanych współrzędnych x i y.
PROC LUDZ(BYTE X,Y)
Rysowanie pojazdu gracza w podanych współrzędnych x i y.
PROC RYSBAZ(BYTE X,Y)
Rysowanie trzech różnych faz bossa (Bazy) w podanych współrzędnych x i y.
PROC SOUWY()
Generowanie różnych rodzajów odgłosów trafienia przeciwników
PROC REKLAMOWKA()
Czołówka gry SPACE TRAVEL, wyświetlenie napisów oraz obsługa klawiatury.
PROC RYNCHR()
Wykorzystywana w różnych miejscach kodu procedura w asemblerze synchronizująca wykonywanie kodu gry z początkiem generowania obrazu przez procesor graficzny.
PROC RUCHYJO()
Obsługa ruchów joystickiem oraz rysowanie pojazdu gracza.
PROC LUDZSTR()
Animowanie kolejnych pocisków gracza.
Procedura ponownie definiuje zmienną pomocniczą Q1, jednak tym razem jest to zmienna lokalna. Jest to niezbędny zabieg, gdyż zmienna globalna Q1 jest wykorzystywana w innych miejscach kodu, który wywołuje procedurę LUDZSTR(). Dzięki temu ta sama zmienna nie jest modyfikowana w różnych miejscach kodu i program działa prawidłowo.
PROC RYSZYC()
Odrysowanie na ekranie aktualnej ilości żyć.
PROC RYSPUN()
Zoptymalizowana procedura zliczająca punkty (specyficzna arytmetyka na 4 bajtach) i wyświetlająca je na ekranie. Odpowiada także za bonusowe życia.
PROC OPGR()
Odrysowanie elementów ekranu gry.
PROC PRZECSTR()
Poruszanie i animowanie pocisków przeciwników
Procedura definiuje lokalną zmienną pomocniczą Q1, podobnie jak ma to miejsce w procedurze LUDZSTR().
PROC PRZECWYB()
Wyświetlenie wszystkich wybuchających przeciwników (w kolejnych fazach animacji).
PROC PRZECMEN()
Generowanie, animowanie przeciwników oraz losowanie czy dany przeciwnik ma strzelić. Wyjaśnienia wymaga zapis „IF RND > 200 & RND < TRU THEN (...)”, dzięki temu, że generator losowy jest na Atari zrealizowany sprzętowo (i to na dobrym poziomie w stosunku do innych komputerów od ZX Spectrum zaczynając a na pecetach kończąc), jest to bardzo prosty zapis dwóch losowań w oparciu o 8 bitową wartość. Jedno losowanie nie jest wystarczające, dlatego po spełnieniu pierwszego warunku, losowanie odbywa się drugi raz (z uwzględnieniem aktualnego poziomu trudności – zmienna TRU) i dopiero po spełnieniu obu warunków może zostać wygenerowany strzał.
Jest to prosty zapis realizujący tą istotną dla rozgrywki funkcję. Jest też bardzo szybki, bo wykorzystuje możliwości sprzętowe Atari oraz nie wykonuje skoku do bibliotecznej procedury RAND(), która do najszybszych nie należy (jest ona użyta w innym miejscu programu dla zobrazowania funkcjonalności obu rozwiązań).
PROC CZARY(BYTE X,Y)
Generuje animację opartą o wartości losowe, ma to obrazować efekt przejścia pomiędzy wymiarami dokonywanego przez bossa.
Dodatkowo kod wykorzystuje w innym celu zmienną POW, a mianowicie jako zmienną pomocniczą. Związane jest to z tym, że ta procedura wykorzystuje wszystkie dostępne zmienne pomocnicze od Q1 do Q5. Zgodnie z chętnie stosowaną w programowaniu zasadą brzytwy Ockhama, została tu zminimalizowana ilość zmiennych wykorzystywanych w programie.
PROC ZERTAB()
Zerowanie kluczowych tablic gry.
PROC NEXTLEV()
Przejście do kolejnego etapu gry. Wyświetlenie stosownych napisów, ustawienie parametrów rozgrywki (np. zwiększenie poziomu trudności itp.).
PROC STRATAZYC(BYTE X)
Procedura realizująca wszystkie niezbędne operacje związane ze stratą życia. Parametr x, umożliwia przekazanie przez algorytmy miejsca, w którym został trafiony gracz. Następnie w tym miejscu rysowany jest wybuch i zatrzymywana jest akacja gry. Początkujący programiści gier powinni prześledzić w jaki sposób jest zrealizowane to, że procedura odpowiedzialna za rysowanie tylko wybuchających przeciwników zostaje tutaj zaadoptowana do wyświetlenia dodatkowego wybuchu, który tutaj nie jest (wyjątkowo) związany z przeciwnikami.
PROC DANEPOCZ()
Ustawia wartości początkowe wszystkich istotnych zmiennych dla rozgrywki – jest to swoiste zresetowanie gry.
PROC GRA()
Główna pętla gry: poruszanie się gracza, generowanie efektów dźwiękowych, strzelanie gracza, algorytmy obu typów przeciwników, kolizje, odliczanie czasu gry, obsługa klawiatury, zakończenie gry gdy ilość żyć równa jest zero oraz odrysowanie związanego z tym ekranu końcowego gry.
Zawiera również początkowe odrysowanie ekranu w momencie rozpoczęcia gry.
PROC MAIN()
Pierwsza uruchamiana procedura w programie, która rozpoczyna się od ustalenia stałych parametrów dla pocisków przeciwników (są to parametry programu a nie gry, więc nie zmieniają się one w dalszej części programu – ich zmiana może doprowadzić do zawieszenia się programu). Następnie w pętli uruchamiane są naprzemiennie procedury REKLAMOWKA() oraz GRA(), zapewniając ciągłość tych dwóch niezbędnych w każdej grze elementów.
3. Listing programu
Plik ACT wspomnianej wersji dostępny tutaj. Właściwie każdy algorytm funkcjonujący w tej grze da się znacznie przyspieszyć, nawet w samym "Action!", czyli bez najmniejszych wstawek asemblera. Zachęcam do prób osoby, które chcą nabrać biegłości w optymalizacji :).
Każdego kto zechce samodzielnie przygotować wersję samouruchamialną (plik XEX), przestrzegam, że to konkretne źródło jest niestabilne po wykorzystaniu "Action! Library". Wcześniej nigdy nie miałem z tym podobnych problemów, nie wnikam dlaczego tak się dzieje, ale jestem mocno zdziwiony, bo kod jest niezwykle prosty i nie wykorzystuje nic szczególnego.
4. Gotowa gra
Nie ma jednak rzeczy niemożliwych, udało się przygotować skompilowaną wersję :). Z katalogu gier AOL można ściągnąć plik XEX z gotową wersją "Space Travel". Gra nie wymaga opisu poza informacją, że klawiszem Esc można zakończyć grę, a w "Action!" klawiszem SELECT. Miłego giercowania i zmagań z "Action!".
Tdc 2010-05-11 21:31:46
Mały konkurs (bez nagród ;) ): w kodzie programu jest coś oprogramowane, ale nie działa (działa w Tomcat) - co to takiego ?
Co do obu gier to można je na wiele sposobów optymalizować, to co widzimy jest napisane aby było czytelne dla osób uczących się Action! (obecnie łatwe jest np. porównanie kodu obu gier).
Zachęcam też do modyfikacji obu gier, szczególnie łatwe jest to w przypadku ST. Można np. dodać kilka rodzajów broni itp.
Kaz 2010-05-12 02:21:10
TDC - skutecznie odstraszasz wszystkich od zajmowania sie "Action!" piszac o tych bledach w kompilatorze :D
Tdc 2010-05-12 03:02:06
Nie moja wina ;) piszę jak jest.
W każdym razie tym razem problem opisywany w artku to nie błąd Action!, ale zapewne programu o nazwie "Action! Library".
Co do mojego "konkursu" to nie jest to problem z Action! tylko zamierzone działanie, każdy kto nawet nie zna Action! ma szanse odnaleźć co zostało tak spreparowane, że nie działa.
Krótki 2010-05-12 04:08:26
Link do pliku XEX z artykułu jest zepsuty :)
A z tą brzytwą Ockhama to już przesada. Panu TDC się wydawało, że nadużywając pojęcia w zupełnie złym kontekście popisze się erudycją? Na mnie nie podziałało, ale może inni znajdą w nim godnego naśladowcę Jana Chryzostoma Paska i jego makaronizmów.
Tdc 2010-05-12 04:46:59
Ja piszę dla swojej i Waszej przyjemności, więc nie czepiajmy się. Przyznaję że czasami używam różnych udziwnień, ale chyba jestem już z tego wystarczająco znany.
Co do zmiennych to wielbiciele programowania teoretycznego bardzo lubią minimalizować ilość zmiennych, a jeśli ktoś studiował inf na jakimś uniwerku to tam być może spotkał się z jakimś purystą, który kazał mu np. robić operacje arytmetyczne na 1 zmiennej itp.
Ja takich rzeczy nie pochwalam bo jest to sztuka dla sztuki, ale ogólnie warto myśleć o minimalizacji zmiennych w końcu 64 kilo to dość mało ;)
laoo 2010-05-12 08:41:21
W przypadku programowania na Atari rozumiem korzyści płynące z reusingu zmiennych (sam jak piszę w ASM używam puli rejestrów na stronie zerowej do ogólnego przeznaczenia), ale skąd pomysł na nazwy "A, B, C, C1, D, E, E1, F, EE, OPE, BX, BY, B1, B2, BC, BD, BC1, BB, WYB, WY2" itd. I to w programie, w którym "zależało [autorowi] na przejrzystości i czytelności kodu, [...] aby nie zaciemniać kodu dla czytelników." No coś mi tu zgrzyta :)
Druga sprawa: wspomniany przez Ciebie puryzm i "sztuka dla sztuki" ma poważne uzasadnienie. Sam zostałem wyszkolony na uniwerku, ale w pracy jestem jedyny wśród absolwentów politechnik i nawet oni rozumieją jak bardzo warto nadłożyć pracy dla przejrzystości kodu, bo źródła są przede wszystkim dla programisty do czytania (kompilator i tak sobie poradzi), a reusing zmiennych jest doskonałym zaciemniaczem kodu :) Nie piszę tego stricte w stosunku do ACTION!, bo domyślam się, że nie jest on zbyt mocny, ale współczesne kompilatory są już na tyle sprytne, że same zoptymalizują sobie przepływ programu i używanie jednej zmiennej do wielu rzeczy, albo budowanie monstrualnych wyrażeń, żeby tylko cząstkowego wyniki nie przechowywać przypadkiem w tymczasowej stałej, jest co najwyżej strzelaniem sobie w stopę.
larek 2010-05-12 09:02:55
A to dobre! Pytałem TDC na Grzybsoniadzie ile zajęło mu pisanie Tom Cat-a? W odpowiedzi usłyszałem: tydzień. Jaki tydzień? Okazuje się, że gra powstawała 16 lat! :D
A jeśli chodzi o Space Travel, to przed chwilką uruchomiłem sobie grę (przyznaję: na emulatorze) i wyłożyła się po kilkunastu sekundach - obiekty przeciwników nie znikały z lewej strony, ale pozostawały przy lewej krawędzi robiąc tam śmietnik.
larek 2010-05-12 09:10:32
eee... to chyba nie gra się wyłożyła, tylko jest to zamierzony przez programistę efekt ;-)
Krótki 2010-05-12 10:32:33
TDC, ależ ja się nie czepiam, ja w ten sposób, zauważ, robię PR na rzecz Ciebie, abyś z tego, z czego jesteś znany, był znany jeszcze bardziej. "Dodam, iż będę to piętnował przy każdej okazji", jak to ujął jeden z tutejszych klasyków.
Samo 're-użycie' zmiennych (bo między re-użyciem a minimalizacją liczby zmiennych jest subtelna różnica, nie wiem czy trzeba studiować inf na jakimś uniwerku, żeby to zauważać), to oczywiście szczytna idea. Jeśli ktoś studiował inf na jakimś uniwerku, to wie, że nie ma ono nic wspólnego z teoretycznym programowaniem a z jego praktyczną stroną, bo niesie konkretną korzyść w systemach wbudowanych oraz w prymitywnych językach programowania.
Kaz 2010-05-12 10:51:01
Krotki - co masz do Jana Chryzostoma Paska? Akurat swietnie pisal, ciekawie i z jajem. A makaronizmy byly wtedy czescia stylistyki (he, he - starej stylistyki, ktorej tak bronisz w innym watku w przypadku amerykanow).
Pytanie: czy programista jest ten, ktory skonczyl informatyke na uniwerku oraz zauwaza roznice miedzy reuzyciem zmiennym i minimalizacja liczby zmiennych czy ten, kto pisze programy? Takie pytanie ode mnie, osoby zupelnie niezorientowanej jak to jest w srodowisku prawdziwych programistow :)
laoo 2010-05-12 11:54:01
Obaj są programistami. Z tym, że jeden gardzi drugim ;)
Kaz 2010-05-12 12:02:24
LOL
Krótki 2010-05-12 14:13:35
Masz racje Kaz - Pasek używał makaronizmów całkiem poprawnie, więc porównanie było zupełnie nie trafione.
Co do studiowania - spytaj TDCa, on pierwszy pochwalił się osobliwą znajomością arkanów życia studenckiego.
Ja tam nikim nie gardzę, ja się nabijam.
Długi 2010-05-12 14:49:32
Krótki, się nabijasz, a zarazem się podstawiasz. :P
"Nietrafione" powinno być pisane łącznie. :P
Krótki 2010-05-12 15:09:29
Masz rację, przyznaję to bez powoływania się na znajomości wśród studentów i makaronizowania.
tdc 2010-05-12 15:49:20
laoo :
> ale skąd pomysł na nazwy "A, B, C, C1, D,
Tak jak sam zauważyłeś programowanie na Atari (i innych 8bitowcach) się nieco różni od tego co mamy dziś.
Chodzi o dwie sprawy, pierwsza to taka, że sam sprawdzałem, że po wprowadzeniu w na tyle dużym programie pełnych nazw zmiennych to źródło robi się na tyle duże, że nie można go skompilować w Action! (trzeba kompilować z pliku), a nie chciałem tego utrudniać czytelnikom.
Druga sprawa to fakt, że źródło miało być opublikowane na łamach pisma i do dziś pamiętam minę naczelnego, że ma to wyglądać na wzór Bajtków z lat 80, dlatego i tu musiałem postąpić tak aby źródło było najmniejsze (np. nie ma w nim komentarzy, a na pewno by się przydały).
>No coś mi tu zgrzyta :)
Robiłem co mogłem... przykładowo najtrudniejsze do zrozumienia dla początkujących programistów są operacje na tablicach dlatego nazwy tablic robiłem nieco dłuższe, właśnie mając na względzie czytelników. Coś za coś, taki (prawie) złoty środek ;)
> a reusing zmiennych jest doskonałym zaciemniaczem kodu :)
Tak ale zostało to użyte w jednym miejscu a nie notorycznie. Po prostu chciałem przy okazji czytelników czegoś nauczyć.
> współczesne kompilatory są już na tyle sprytne, że same zoptymalizują sobie
Tak dziś raczej się o tym nie myśli, choć na pewno wiele rzeczy i tak można zoptymalizować zmieniając źródło, a nie ustawienia kompilatora. Co do Action! to przypomina on asm i należy samemu sobie kombinować tak aby było szybciej.
Larek:
> W odpowiedzi usłyszałem: tydzień.
Musiałem być już tak zmęczony że coś pomieszałem. Faktycznie było tak: około tygodnia trwało przygotowanie Space Travel z wersji 0,8 do 1,4 (oraz tego artykułu). Potem 3 tygodnie zmieniałem Space Travel w Tomcat ;)
> gra powstawała 16 lat! :D
:):)
> A jeśli chodzi o Space Travel, to przed chwilką uruchomiłem sobie grę (przyznaję: na emulatorze) i wyłożyła się po kilkunastu sekundach
Użyję klasycznego „Dziwne, u mnie działa” :D
Nie wiem, może uruchomiłeś z Basicem lub z inną opcją. Jak ktoś będzie miał jakieś problemy to może uruchomić grę z poziomu kompilacji źródła – wtedy będzie działać.
> obiekty przeciwników nie znikały z lewej strony, ale pozostawały przy lewej krawędzi robiąc tam śmietnik.
W artku jest napisane, że „przykładem uproszczeń jest (...) niezmazywanie przeciwników z ekranu.”
Taką ciekawostką jest fakt, że w Tomcat też nie ma usuwania tej grafiki, a nawet są usunięte te zamazywania, które są w Space Travel. Dla początkujących proponuję aby sobie prześledzili dlaczego w Tomcat to nie jest potrzebne.
Krótki :
> ja w ten sposób, zauważ, robię PR na rzecz Ciebie
Dziękuję :->
> bo między re-użyciem a minimalizacją liczby zmiennych jest subtelna różnica,
Jeśli sugerujesz że jej nie znam to zwróć uwagę że w tym źródle użyte są obie.
> Jeśli ktoś studiował inf na jakimś uniwerku, to wie, że nie ma ono nic wspólnego z teoretycznym programowaniem a z jego praktyczną stroną
No właśnie podałem przykład operacji arytmetycznych na jednej zmiennej – to właśnie tylko teoretyczne programowanie, jak pisałem sztuka dla sztuki. Na małym Atari i systemach wbudowanych nie ma na to miejsca np. w grach itp.
> bo niesie konkretną korzyść w systemach wbudowanych
Byłbym zdziwiony gdyby na jakimś uniwerku poświęcano swój „cenny” czas na systemy wbudowane (czyli np. semestr po semestrze), ja studiowałem na politechnicznej uczelni i miałem z tych systemów chyba jeden przedmiot.
Kaz:
> informatyke na uniwerku oraz zauwaza roznice miedzy reuzyciem zmiennym i minimalizacja liczby zmiennych
Tę różnicę powinni zauważać obaj;) Tylko że ci z uniwerka poświęcili na to kilka wykładów oraz zadań na egzaminach, a ci drudzy pewnie nie mieli o tym mowy na: wykładach, ćwicz/lab i egz. ale zakładano, że wiedzą o co chodzi.
laoo
> Obaj są programistami. Z tym, że jeden gardzi drugim ;)
:D :D
Krótki
> on pierwszy pochwalił się osobliwą znajomością arkanów życia studenckiego.
Ja jeszcze nic nie pisałem o arkanach życia studenckiego ;):):)
...szczególnie o tej bardziej „osobliwej” stronie :D :D
> Ja tam nikim nie gardzę
Ja też nikim nie gardzę, choć martwi mnie podejście do programowania na uniwerku (akurat operacje na 1 zmiennej są dla mnie fajne – choć to tylko teoretyzowanie), szczególnie studenci, którzy dostają białej gorączki jak mają napisać jakiś program.
Co do teoretycznego podejścia to nie ma po porostu na nie miejsca w programowaniu np. gier na Atari. Tu musimy się zajmować tylko tym co jest przydatne dla kogoś kto chce poznać Action! lub uczyć się programować na Atari.
Krótki 2010-05-12 22:09:04
TDC>Jeśli sugerujesz że jej nie znam to zwróć uwagę że w tym źródle użyte są obie.
W tekście mianem minimalizacji liczby zmiennych określasz podzbiór tego zagadnienia (re-użycie). Uznałem że warto to doprecyzować, a przy okazji też sobie poszpanuję, a co.
TDC>No właśnie podałem przykład operacji arytmetycznych na jednej zmiennej – to właśnie tylko teoretyczne programowanie, jak pisałem sztuka dla sztuki.
Jak masz do dyspozycji system w którym jedyną pamięcią zmienną jest rejestr w procesorze, to nagle się okazuje że tylko w ten sposób można te operacje wykonać. Możesz więc dalej nazywać to sztuką dla sztuki - ale z jakiej innej przyczyny zachodzi potrzeba ograniczania ilości zmiennych niż właśnie ze względów praktycznych?
TDC>Na małym Atari i systemach wbudowanych nie ma na to miejsca np. w grach itp.
Oczywiście, bo Atari i systemy wbudowane jak żadne inne mają praktycznie nieograniczoną ilość RAM-u.
TDC>Byłbym zdziwiony gdyby na jakimś uniwerku poświęcano swój „cenny” czas na systemy wbudowane (czyli np. semestr po semestrze),
A co ma ilość zajęć na uczelniach do zagadnienia, które przed ww. wypowiedzią zacytowałeś?
TDC>Tę różnicę powinni zauważać obaj;) Tylko że ci z uniwerka poświęcili na to kilka wykładów oraz zadań na egzaminach,
TDC>szczególnie studenci, którzy dostają białej gorączki jak mają napisać jakiś program.
To właśnie określam mianem osobliwej znajomości arkanów itd. Wyrazy współczucia, że z takimi historiami i takimi studentami miałeś do czynienia. Ja na tym polu mam doświadczenia wprost przeciwne, i jak czytam takie wynurzenia - to oczy jak spodki, normalnie.
TDC>Co do teoretycznego podejścia to nie ma po porostu na nie miejsca w programowaniu np. gier na Atari.
Jak dotąd epitetu "programowanie teoretyczne" użyłeś tutaj Ty jeden. Jakkolwiek zatem Twoja opinia jest prawdziwa, to nie wiem do kogo była skierowana.
nosty 2010-05-12 22:12:11
uzywacie zmiennych i nazywacie sie programistami??
prawdziwy programista pisze od razu w kodzie szesnastkowym :P
Krótki 2010-05-12 22:26:41
Żeby nie było nieporozumień - artek wporzo, miło poczytać. Ale jeden przejaw erudycji autora mnie - no jak to ująć - doświadczył zbyt mocno.
jhusak 2010-05-13 10:34:22
A co wy Koledzy macie do Uniwerku?
tdc 2010-05-17 00:14:53
Jeszcze osobom, które będą chciały dopisać coś do gry Tomcat, podkreślę, że kod po skompilowaniu kończy się na adresie $8?00, a już od adresu $8F27 zaczynają się dane gry, które kończą się w $BF2A. Oczywiście adres końca kodu zależy od tego ile miejsca pozostawi nam dos, najlepsza jest tu Sparta X lub dos II+/D.
Dlatego trzeba bardzo dobrze sobie przemyśleć jeśli chcemy coś dopisać, bo np. dopisując kilka rodzajów broni może się okazać, że program się nie skompiluje bo zabraknie pamięci lub kod przekroczy granicę $8F27, co oczywiście zakończy się nadpisaniem kodu programu i pewnie go zawiesi.
----
Odpowiedź na wasze komentarze napiszę niebawem.
Mały konkurs (bez nagród ;) ): w kodzie programu jest coś oprogramowane, ale nie działa (działa w Tomcat) - co to takiego ?
Co do obu gier to można je na wiele sposobów optymalizować, to co widzimy jest napisane aby było czytelne dla osób uczących się Action! (obecnie łatwe jest np. porównanie kodu obu gier).
Zachęcam też do modyfikacji obu gier, szczególnie łatwe jest to w przypadku ST. Można np. dodać kilka rodzajów broni itp.
Kaz 2010-05-12 02:21:10
TDC - skutecznie odstraszasz wszystkich od zajmowania sie "Action!" piszac o tych bledach w kompilatorze :D
Tdc 2010-05-12 03:02:06
Nie moja wina ;) piszę jak jest.
W każdym razie tym razem problem opisywany w artku to nie błąd Action!, ale zapewne programu o nazwie "Action! Library".
Co do mojego "konkursu" to nie jest to problem z Action! tylko zamierzone działanie, każdy kto nawet nie zna Action! ma szanse odnaleźć co zostało tak spreparowane, że nie działa.
Krótki 2010-05-12 04:08:26
Link do pliku XEX z artykułu jest zepsuty :)
A z tą brzytwą Ockhama to już przesada. Panu TDC się wydawało, że nadużywając pojęcia w zupełnie złym kontekście popisze się erudycją? Na mnie nie podziałało, ale może inni znajdą w nim godnego naśladowcę Jana Chryzostoma Paska i jego makaronizmów.
Tdc 2010-05-12 04:46:59
Ja piszę dla swojej i Waszej przyjemności, więc nie czepiajmy się. Przyznaję że czasami używam różnych udziwnień, ale chyba jestem już z tego wystarczająco znany.
Co do zmiennych to wielbiciele programowania teoretycznego bardzo lubią minimalizować ilość zmiennych, a jeśli ktoś studiował inf na jakimś uniwerku to tam być może spotkał się z jakimś purystą, który kazał mu np. robić operacje arytmetyczne na 1 zmiennej itp.
Ja takich rzeczy nie pochwalam bo jest to sztuka dla sztuki, ale ogólnie warto myśleć o minimalizacji zmiennych w końcu 64 kilo to dość mało ;)
laoo 2010-05-12 08:41:21
W przypadku programowania na Atari rozumiem korzyści płynące z reusingu zmiennych (sam jak piszę w ASM używam puli rejestrów na stronie zerowej do ogólnego przeznaczenia), ale skąd pomysł na nazwy "A, B, C, C1, D, E, E1, F, EE, OPE, BX, BY, B1, B2, BC, BD, BC1, BB, WYB, WY2" itd. I to w programie, w którym "zależało [autorowi] na przejrzystości i czytelności kodu, [...] aby nie zaciemniać kodu dla czytelników." No coś mi tu zgrzyta :)
Druga sprawa: wspomniany przez Ciebie puryzm i "sztuka dla sztuki" ma poważne uzasadnienie. Sam zostałem wyszkolony na uniwerku, ale w pracy jestem jedyny wśród absolwentów politechnik i nawet oni rozumieją jak bardzo warto nadłożyć pracy dla przejrzystości kodu, bo źródła są przede wszystkim dla programisty do czytania (kompilator i tak sobie poradzi), a reusing zmiennych jest doskonałym zaciemniaczem kodu :) Nie piszę tego stricte w stosunku do ACTION!, bo domyślam się, że nie jest on zbyt mocny, ale współczesne kompilatory są już na tyle sprytne, że same zoptymalizują sobie przepływ programu i używanie jednej zmiennej do wielu rzeczy, albo budowanie monstrualnych wyrażeń, żeby tylko cząstkowego wyniki nie przechowywać przypadkiem w tymczasowej stałej, jest co najwyżej strzelaniem sobie w stopę.
larek 2010-05-12 09:02:55
A to dobre! Pytałem TDC na Grzybsoniadzie ile zajęło mu pisanie Tom Cat-a? W odpowiedzi usłyszałem: tydzień. Jaki tydzień? Okazuje się, że gra powstawała 16 lat! :D
A jeśli chodzi o Space Travel, to przed chwilką uruchomiłem sobie grę (przyznaję: na emulatorze) i wyłożyła się po kilkunastu sekundach - obiekty przeciwników nie znikały z lewej strony, ale pozostawały przy lewej krawędzi robiąc tam śmietnik.
larek 2010-05-12 09:10:32
eee... to chyba nie gra się wyłożyła, tylko jest to zamierzony przez programistę efekt ;-)
Krótki 2010-05-12 10:32:33
TDC, ależ ja się nie czepiam, ja w ten sposób, zauważ, robię PR na rzecz Ciebie, abyś z tego, z czego jesteś znany, był znany jeszcze bardziej. "Dodam, iż będę to piętnował przy każdej okazji", jak to ujął jeden z tutejszych klasyków.
Samo 're-użycie' zmiennych (bo między re-użyciem a minimalizacją liczby zmiennych jest subtelna różnica, nie wiem czy trzeba studiować inf na jakimś uniwerku, żeby to zauważać), to oczywiście szczytna idea. Jeśli ktoś studiował inf na jakimś uniwerku, to wie, że nie ma ono nic wspólnego z teoretycznym programowaniem a z jego praktyczną stroną, bo niesie konkretną korzyść w systemach wbudowanych oraz w prymitywnych językach programowania.
Kaz 2010-05-12 10:51:01
Krotki - co masz do Jana Chryzostoma Paska? Akurat swietnie pisal, ciekawie i z jajem. A makaronizmy byly wtedy czescia stylistyki (he, he - starej stylistyki, ktorej tak bronisz w innym watku w przypadku amerykanow).
Pytanie: czy programista jest ten, ktory skonczyl informatyke na uniwerku oraz zauwaza roznice miedzy reuzyciem zmiennym i minimalizacja liczby zmiennych czy ten, kto pisze programy? Takie pytanie ode mnie, osoby zupelnie niezorientowanej jak to jest w srodowisku prawdziwych programistow :)
laoo 2010-05-12 11:54:01
Obaj są programistami. Z tym, że jeden gardzi drugim ;)
Kaz 2010-05-12 12:02:24
LOL
Krótki 2010-05-12 14:13:35
Masz racje Kaz - Pasek używał makaronizmów całkiem poprawnie, więc porównanie było zupełnie nie trafione.
Co do studiowania - spytaj TDCa, on pierwszy pochwalił się osobliwą znajomością arkanów życia studenckiego.
Ja tam nikim nie gardzę, ja się nabijam.
Długi 2010-05-12 14:49:32
Krótki, się nabijasz, a zarazem się podstawiasz. :P
"Nietrafione" powinno być pisane łącznie. :P
Krótki 2010-05-12 15:09:29
Masz rację, przyznaję to bez powoływania się na znajomości wśród studentów i makaronizowania.
tdc 2010-05-12 15:49:20
laoo :
> ale skąd pomysł na nazwy "A, B, C, C1, D,
Tak jak sam zauważyłeś programowanie na Atari (i innych 8bitowcach) się nieco różni od tego co mamy dziś.
Chodzi o dwie sprawy, pierwsza to taka, że sam sprawdzałem, że po wprowadzeniu w na tyle dużym programie pełnych nazw zmiennych to źródło robi się na tyle duże, że nie można go skompilować w Action! (trzeba kompilować z pliku), a nie chciałem tego utrudniać czytelnikom.
Druga sprawa to fakt, że źródło miało być opublikowane na łamach pisma i do dziś pamiętam minę naczelnego, że ma to wyglądać na wzór Bajtków z lat 80, dlatego i tu musiałem postąpić tak aby źródło było najmniejsze (np. nie ma w nim komentarzy, a na pewno by się przydały).
>No coś mi tu zgrzyta :)
Robiłem co mogłem... przykładowo najtrudniejsze do zrozumienia dla początkujących programistów są operacje na tablicach dlatego nazwy tablic robiłem nieco dłuższe, właśnie mając na względzie czytelników. Coś za coś, taki (prawie) złoty środek ;)
> a reusing zmiennych jest doskonałym zaciemniaczem kodu :)
Tak ale zostało to użyte w jednym miejscu a nie notorycznie. Po prostu chciałem przy okazji czytelników czegoś nauczyć.
> współczesne kompilatory są już na tyle sprytne, że same zoptymalizują sobie
Tak dziś raczej się o tym nie myśli, choć na pewno wiele rzeczy i tak można zoptymalizować zmieniając źródło, a nie ustawienia kompilatora. Co do Action! to przypomina on asm i należy samemu sobie kombinować tak aby było szybciej.
Larek:
> W odpowiedzi usłyszałem: tydzień.
Musiałem być już tak zmęczony że coś pomieszałem. Faktycznie było tak: około tygodnia trwało przygotowanie Space Travel z wersji 0,8 do 1,4 (oraz tego artykułu). Potem 3 tygodnie zmieniałem Space Travel w Tomcat ;)
> gra powstawała 16 lat! :D
:):)
> A jeśli chodzi o Space Travel, to przed chwilką uruchomiłem sobie grę (przyznaję: na emulatorze) i wyłożyła się po kilkunastu sekundach
Użyję klasycznego „Dziwne, u mnie działa” :D
Nie wiem, może uruchomiłeś z Basicem lub z inną opcją. Jak ktoś będzie miał jakieś problemy to może uruchomić grę z poziomu kompilacji źródła – wtedy będzie działać.
> obiekty przeciwników nie znikały z lewej strony, ale pozostawały przy lewej krawędzi robiąc tam śmietnik.
W artku jest napisane, że „przykładem uproszczeń jest (...) niezmazywanie przeciwników z ekranu.”
Taką ciekawostką jest fakt, że w Tomcat też nie ma usuwania tej grafiki, a nawet są usunięte te zamazywania, które są w Space Travel. Dla początkujących proponuję aby sobie prześledzili dlaczego w Tomcat to nie jest potrzebne.
Krótki :
> ja w ten sposób, zauważ, robię PR na rzecz Ciebie
Dziękuję :->
> bo między re-użyciem a minimalizacją liczby zmiennych jest subtelna różnica,
Jeśli sugerujesz że jej nie znam to zwróć uwagę że w tym źródle użyte są obie.
> Jeśli ktoś studiował inf na jakimś uniwerku, to wie, że nie ma ono nic wspólnego z teoretycznym programowaniem a z jego praktyczną stroną
No właśnie podałem przykład operacji arytmetycznych na jednej zmiennej – to właśnie tylko teoretyczne programowanie, jak pisałem sztuka dla sztuki. Na małym Atari i systemach wbudowanych nie ma na to miejsca np. w grach itp.
> bo niesie konkretną korzyść w systemach wbudowanych
Byłbym zdziwiony gdyby na jakimś uniwerku poświęcano swój „cenny” czas na systemy wbudowane (czyli np. semestr po semestrze), ja studiowałem na politechnicznej uczelni i miałem z tych systemów chyba jeden przedmiot.
Kaz:
> informatyke na uniwerku oraz zauwaza roznice miedzy reuzyciem zmiennym i minimalizacja liczby zmiennych
Tę różnicę powinni zauważać obaj;) Tylko że ci z uniwerka poświęcili na to kilka wykładów oraz zadań na egzaminach, a ci drudzy pewnie nie mieli o tym mowy na: wykładach, ćwicz/lab i egz. ale zakładano, że wiedzą o co chodzi.
laoo
> Obaj są programistami. Z tym, że jeden gardzi drugim ;)
:D :D
Krótki
> on pierwszy pochwalił się osobliwą znajomością arkanów życia studenckiego.
Ja jeszcze nic nie pisałem o arkanach życia studenckiego ;):):)
...szczególnie o tej bardziej „osobliwej” stronie :D :D
> Ja tam nikim nie gardzę
Ja też nikim nie gardzę, choć martwi mnie podejście do programowania na uniwerku (akurat operacje na 1 zmiennej są dla mnie fajne – choć to tylko teoretyzowanie), szczególnie studenci, którzy dostają białej gorączki jak mają napisać jakiś program.
Co do teoretycznego podejścia to nie ma po porostu na nie miejsca w programowaniu np. gier na Atari. Tu musimy się zajmować tylko tym co jest przydatne dla kogoś kto chce poznać Action! lub uczyć się programować na Atari.
Krótki 2010-05-12 22:09:04
TDC>Jeśli sugerujesz że jej nie znam to zwróć uwagę że w tym źródle użyte są obie.
W tekście mianem minimalizacji liczby zmiennych określasz podzbiór tego zagadnienia (re-użycie). Uznałem że warto to doprecyzować, a przy okazji też sobie poszpanuję, a co.
TDC>No właśnie podałem przykład operacji arytmetycznych na jednej zmiennej – to właśnie tylko teoretyczne programowanie, jak pisałem sztuka dla sztuki.
Jak masz do dyspozycji system w którym jedyną pamięcią zmienną jest rejestr w procesorze, to nagle się okazuje że tylko w ten sposób można te operacje wykonać. Możesz więc dalej nazywać to sztuką dla sztuki - ale z jakiej innej przyczyny zachodzi potrzeba ograniczania ilości zmiennych niż właśnie ze względów praktycznych?
TDC>Na małym Atari i systemach wbudowanych nie ma na to miejsca np. w grach itp.
Oczywiście, bo Atari i systemy wbudowane jak żadne inne mają praktycznie nieograniczoną ilość RAM-u.
TDC>Byłbym zdziwiony gdyby na jakimś uniwerku poświęcano swój „cenny” czas na systemy wbudowane (czyli np. semestr po semestrze),
A co ma ilość zajęć na uczelniach do zagadnienia, które przed ww. wypowiedzią zacytowałeś?
TDC>Tę różnicę powinni zauważać obaj;) Tylko że ci z uniwerka poświęcili na to kilka wykładów oraz zadań na egzaminach,
TDC>szczególnie studenci, którzy dostają białej gorączki jak mają napisać jakiś program.
To właśnie określam mianem osobliwej znajomości arkanów itd. Wyrazy współczucia, że z takimi historiami i takimi studentami miałeś do czynienia. Ja na tym polu mam doświadczenia wprost przeciwne, i jak czytam takie wynurzenia - to oczy jak spodki, normalnie.
TDC>Co do teoretycznego podejścia to nie ma po porostu na nie miejsca w programowaniu np. gier na Atari.
Jak dotąd epitetu "programowanie teoretyczne" użyłeś tutaj Ty jeden. Jakkolwiek zatem Twoja opinia jest prawdziwa, to nie wiem do kogo była skierowana.
nosty 2010-05-12 22:12:11
uzywacie zmiennych i nazywacie sie programistami??
prawdziwy programista pisze od razu w kodzie szesnastkowym :P
Krótki 2010-05-12 22:26:41
Żeby nie było nieporozumień - artek wporzo, miło poczytać. Ale jeden przejaw erudycji autora mnie - no jak to ująć - doświadczył zbyt mocno.
jhusak 2010-05-13 10:34:22
A co wy Koledzy macie do Uniwerku?
tdc 2010-05-17 00:14:53
Jeszcze osobom, które będą chciały dopisać coś do gry Tomcat, podkreślę, że kod po skompilowaniu kończy się na adresie $8?00, a już od adresu $8F27 zaczynają się dane gry, które kończą się w $BF2A. Oczywiście adres końca kodu zależy od tego ile miejsca pozostawi nam dos, najlepsza jest tu Sparta X lub dos II+/D.
Dlatego trzeba bardzo dobrze sobie przemyśleć jeśli chcemy coś dopisać, bo np. dopisując kilka rodzajów broni może się okazać, że program się nie skompiluje bo zabraknie pamięci lub kod przekroczy granicę $8F27, co oczywiście zakończy się nadpisaniem kodu programu i pewnie go zawiesi.
----
Odpowiedź na wasze komentarze napiszę niebawem.