atarionline.pl Nowa gra: Biedny Pies Antoni - Forum Atarum

    Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

    • :
    • :

    Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    5. Gry / Games  »   Nowa gra: Biedny Pies Antoni

    W dół

    Od 101 do 150 z 178

    1. <
    2. 1
    3. 2
    4. 3
    5. 4
    6. >
      • 1:
         
        CommentAuthormgr_inz_rafal
      • CommentTime3 Mar 2012 11:03 zmieniony
       
      Gra właściwie skończona, aż do znalezienia bugów :) Zamiast dalej ją upiększać, spróbuję zabrać się za coś ciekawszego niż Atari Basic.

      Jeden bug został dzisiaj poprawiony. Polegał na tym, że w pewnych okolicznościach wyznaczona ścieżka nie trafiała w wyjście:


      Plik z grą w załączniku.

      A tutaj jeszcze gameplay na YouTube:
      • 2:
         
        CommentAuthorlarek
      • CommentTime3 Mar 2012 11:03 zmieniony
       
      Na filmie najbardziej spodobało mi się "RU." ;)

      Dziś rano przed pracą zagrałem sobie kilka razy i zaskoczyło mnie trochę, że można sobie bezkarnie chodzić po ślimakach i drzewach. Być może było to już poruszane, ale nie śledziłem wątku od początku i dopiero po zagraniu zwróciłem na to uwagę. Wydaje mi się, że drzewa i (tak przecież duże) ślimaki powinny być barierą nie do przejścia.
      A jakby ślimaki przesuwały się w prawo to byłoby już super :)
      • 3: CommentAuthorBrix
      • CommentTime3 Mar 2012 12:03
       
      Cha cha cha! :D Niesamowite, ta gierka jest znacznie lepsza niż się spodziewałem :) Może sobie ją dzisiaj wieczorkiem przejdę, oczywiście korzystając z drobnych przekrętów jak "Print Screen" i "Save state" ;)
    4.  

      larek:

      zaskoczyło mnie trochę, że można sobie bezkarnie chodzić po ślimakach i drzewach (...) Wydaje mi się, że drzewa i (tak przecież duże) ślimaki powinny być barierą nie do przejścia.

      Ozdobniki w postaci drzew i ślimaków służą jako punkty odniesienia pomagające w zapamiętaniu trasy. Też za bardzo wizualnie nie podoba mi się to, że można po nich chodzić albo że kosiarka je wycina przy wyznaczaniu trasy, w związku z czym miałem pomysł, aby algorytm sadzący drzewa i ślimaki wstawiał je tylko poza wyznaczoną trasą, ale już nie chciało mi się implementować...
      A jakby ślimaki przesuwały się w prawo to byłoby już super :)

      Straciłby wtedy swoje znaczenie jako punkty odniesienia.

      Brix:

      Niesamowite, ta gierka jest znacznie lepsza niż się spodziewałem :)

      Dzięki.

      Może sobie ją dzisiaj wieczorkiem przejdę, oczywiście korzystając z drobnych przekrętów jak "Print Screen" i "Save state" ;)

      Tylko nie zdradzaj nikomu, jak wygląda teraz obrazek końcowy :)

      PS. Drobny przekręt jest też wbudowany w samą grę :) Może znajdziesz ;)
      • 5: CommentAuthorBluki
      • CommentTime4 Mar 2012 22:03 zmieniony
       
      Niektórzy chwalą „Biednego psa Antoniego”, a ja dla odmiany dorzucę kilka uwag, elementów do poprawki.

      1) „Parę sekund będzie ciemno”. Oj, nie ładnie oszukiwać! Ciemno jest aż przez 37 sekund. Tak długi czas oczekiwania na „rozgrzanie” gry był dobry w epoce lampowej, a nie mikroprocesorów; może zniechęcić każdego do grania.
      2) Nie jest ustawiany lewy margines na 2, co w pewnych sytuacjach prowadzi do błędów w wyświetlaniu napisów.
      3) Nie jest blokowany klawisz BREAK.
      4) Brak „cywilizowanego” sposobu opuszczania gry. Po naciśnięciu ESC (lub innego klawisza) powinno następować przejście do nadrzędnego programu „AUTORUN.BAS”, a w razie jego braku do BASIC-a. Wcześniej powinny być przywrócone standardowe ustawienia jak np. RAMTOP. Takie rozwiązanie ułatwia ew. wczytanie nowej gry z tej samej dyskietki.
      5) „Wduś jakiś guzik”. Nie lubię duszenia, a poza tym mam Atari ponad 25 lat i gdyby były w nim jakieś guziki, na pewno bym przez ten czas to zauważył :) Mam też zastrzeżenia do paru innych napisów, ale niech tam...
      6) Za długie linie (np. l. 75), powinny zawierać najwyżej 120 znaków łącznie z numerem linii. Próba zmiany czegokolwiek w takiej długiej linii zakończy się komunikatem błędu.
      7) Wielokrotnie pojawia się „OLD559=PEEK(559), a przecież zawsze standardowo OS wstawia tam wartość 34. Jeśli ta zmienna jest potrzebna to wystarczy zainicjować ją tylko raz. Chyba, że coś przegapiłem.
      8) Do czego służy linia 666?
      9) Linia 4010. POKE 106,144 powinno być przed GRAPHICS. Samo wpisanie do 106 wartości, niczego nie zmienia. Dopiero po wykonaniu GRAPHICS, OS przesuwa pamięć obrazu pod RAMTOP.
      Na końcu tej samej linii jest instrukcja „PRINT...” Po co, skoro ekran jest wyłączony, a następna instrukcja włączająca równocześnie czyści go.
      10) Jak to możliwe, że pies przecina na pół drzewa i ślimaki? Taka sytuacja jest dla mnie nie do przyjęcia. Pies powinien przechodzić przed obiektem. Odtworzenie znaku „pod psem” nie stanowi przecież większego problemu.
      11) W czasie rysowania pieska słyszymy „kocią muzykę”. Rzeczywiście biedny piesek, skoro musi jej wysłuchiwać :D
      A przy okazji – nie jest to już zarzut – piesek przypomina mi bardziej filmowego „smoka szczęścia” z „Niekończącej się opowieści” (Wolfganga Petersena).

      Jeśli uda się poprawić parę błędów, wtedy będzie to naprawdę świetna gra!
      • 6:
         
        CommentAuthorlarek
      • CommentTime4 Mar 2012 22:03
       
      Ej, ale to jest gra, a nie listing z Bajtka w dziale "Poprawne programowanie" :)
      • 7:
         
        CommentAuthormgr_inz_rafal
      • CommentTime5 Mar 2012 11:03 zmieniony
       
      Bluki, dzięki za Code Review, na pewno sporo można się z niego nauczyć. Początkowo nawet chciałem kogoś o to poprosić, ale mówię - kurde, ludzie mają swoje sprawy :)

      Poniżej kilka komentarzy i dalszych pytań dot. spraw technicznych. Kwestie gustu (muzyka, grafika, napisy) pomijam, no bo gust każdy ma swój :)

      Zatem:

      Bluki:

      1) „Parę sekund będzie ciemno”. Oj, nie ładnie oszukiwać! Ciemno jest aż przez 37 sekund.

      Akurat można kawę zrobić :) Będzie do poprawki jeśli ogarnę ASM.

      2) Nie jest ustawiany lewy margines na 2, co w pewnych sytuacjach prowadzi do błędów w wyświetlaniu napisów.
      Gra nie korzysta z lewego marginesu i nie zauważyłem problemów z wyświetlaniem. Możesz wskazać takie okoliczności?

      3) Nie jest blokowany klawisz BREAK.
      Istotnie, nie jest. Czy warto to robić? W końcu break to break :) Dopóki komuś po klawiaturze nie skacze jakiś biedny pies albo kot, to nic się stać nie powinno :)

      4) Brak „cywilizowanego” sposobu opuszczania gry.
      Jak wyżej. Za moich czasów do wyjścia, może nie całkiem cywilizowanego, służył ten czarny przełącznik z tyłu obudowy :) Ideę oczywiście rozumiem. Pamiętam też, jak w którymś odcinku Tajemnic Atari bodajże Janusz B. Wi$niewski opisywał DOSa gdyż pozazdrościł "innym komputerom", że mogą sobie ładować i wyładowywać programy bez wyłączania kompa. Swoją drogą, czy np. z Draconusa albo River Raida można jakoś cywilizowanie wyjść?

      6) Za długie linie (np. l. 75)
      Właśnie pamiętałem, że jest w BASICu limit - obserwowało się trochę rynek pięciolinijkowców :) Stąd też mocno się zdziwiłem, że BASIC łyka mi te linie jak bułki :) Na początku myślałem, że to jakieś rozszerzenie emulatora, ale Real Atari też łyknął, więc nic nie ruszałem. A linijki musiałem przedłużać, bo już mi się ciasno robiło w kodzie, o czym pisałem w jednym z innych wątków dot. edytora BASIC. Czy poza trudnościami w edycji niesie to jeszcze jakieś inne zagrożenia?

      7)Wielokrotnie pojawia się OLD559=PEEK(559)
      Rzeczywiście, nie pamiętam, abym za dzieciaka coś takiego pisał. Jednak jeden z tutoriali do Basica sugerował zapamiętanie poprzedniej wartości 559, tak też uczyniłem.

      8) Do czego służy linia 666?
      Debug helper. Była przydatna przy debugowaniu procedurki wyznaczającej szlak. Nie usuwałem, bo mam jeszcze pomysł na przyspieszenie koszenia trawy, więc może się jeszcze przydać.

      9) Linia 4010. POKE 106,144 powinno być przed GRAPHICS (...)Na końcu tej samej linii jest instrukcja „PRINT...”
      POKE i GRAPHICS już zamieniłem miejscami. Jak działało, tak działa :) Odnośnie PRINT - pozostałość po czasach bez wygaszania ekranu.

      larek:

      Ej, ale to jest gra, a nie listing z Bajtka w dziale "Poprawne programowanie"

      Zgadza się, choć takie podejście nie usprawiedliwia występowania błędów technicznych, jeśli takie są.

      W jednym z wcześniejszych postów w tym wątku anonymus podał linka do IKSa 1986_01, w którym były "Wyścigi Psów", żebym mógł zaczerpnąć semigrafikę. W tym samym numerze jest również poradnik dla programistów, sugerujący np. "6) należy pisać tylko jedną instrukcję w wierszu;". Tak też wystartowałem, ale szybko zabrakło linijek :) A potem jeszcze sklejałem linijki w jedno, żeby zyskać na pamięci :) Podobnie "10) należy komentować wszystkie zmienne programu;" - też musiałem usuwać REMy ze względu na pamięć :) Itp. Co innego współczesne kodowanie, gdzie więcej jest komentarzy dla Doxygena niż właściwego kodu, a co innego poczciwy Atari Basic, w którym muszę skoki przenosić jak najbliżej początku programu :)

      Generalnie, przyjąłem podejście pragmatyczne - ma działać :) Czytelność kodu na drugie miejsce.

      Podsumowując ogólny plan jest taki (wg priorytetów):
      1. Zabrać się za ASM i porobić coś fajniejszego
      2. Napisać w nim szybki generator znaków i wcielić go do Biednego Psa
      3. Spróbować rozgryźć podkolorywanie w GR. 0 i również wcielić je do gry
      4. Przyspieszyć algorytm koszenia trawy (jest jeszcze jeden pomysł). Może też przepisać go do ASM
      5. Usunąć drzewka i ślimaki z trasy, żeby nie można było ich przecinać


      --- EDIT: ---
      Hmm, coś mi ostatnio generator znaków nie chciał działać w TurboBeju. Może chodziło o to feralne POKE 106... Sprawdzę później :)

      --- EDIT2: ---
      Niestety, to nie ten POKE wywala Turbobeja...
      • 8:
         
        CommentAuthorKaz
      • CommentTime5 Mar 2012 12:03
       
      5. Usunąć drzewka i ślimaki z trasy, żeby nie można było ich przecinać


      To moze generuj je po wyznaczeniu trasy?

      Tak też wystartowałem, ale szybko zabrakło linijek :) A potem jeszcze sklejałem linijki w jedno, żeby zyskać na pamięci :) Podobnie "10) należy komentować wszystkie zmienne programu;" - też musiałem usuwać REMy ze względu na pamięć :)


      "Kolony 2106" prawie w calosci sklada sie z takich optymalizacji. Inaczej nie byloby szans na zmieszczenie w pamieci tego, co sie zmiescilo. Teraz oczywiscie program jest nieczytelny i nieedytowalny w edytorze Atari... ale to juz nie ma znaczenia :)
      • 9: CommentAuthorBluki
      • CommentTime5 Mar 2012 13:03 zmieniony
       

      mgr_inz_rafal:

      Akurat można kawę zrobić :) Będzie do poprawki jeśli ogarnę ASM.

      Chodziło mnie o to, że uczciwiej byłoby napisać „Będzie ciemno przez 37 sekund” albo chociaż „...30 sekund”. Sposób na przyspieszenie inicjalizacji podałem w którymś z wcześniejszych postów, ale dobrze, że planujesz to za jakiś czas zmienić, poczekam.

      Gra nie korzysta z lewego marginesu...

      Ależ korzysta! Jak każda w GR.0. Oto przykład po uruchomieniu spod mojego inicjalizera:



      Istotnie, nie jest. Czy warto to robić? W końcu break to break...

      Bez jaj! Przecież to tylko jedno POKE na początku i drugie przy wyjściu z programu. Czy River Raid albo Drakonusa albo... długo by wymieniać, można przerwać w ten sposób? To po prostu brzydko wygląda. Mówiąc inaczej, to kwestia profesjonalizmu.

      Za moich czasów do wyjścia, może nie całkiem cywilizowanego, służył ten czarny przełącznik z tyłu obudowy:)

      Od dawna wiadomo, że to najgorsze możliwe rozwiązanie.

      Swoją drogą, czy np. z Draconusa albo River Raida można jakoś cywilizowanie wyjść?

      To gry komercyjne, z założenia rozprowadzane jako całodyskowe. W takim przypadku nie ma dokąd wyjść, nie ma programu nadrzędnego – chyba że SELF TEST :)

      A linijki musiałem przedłużać, bo już mi się ciasno robiło w kodzie...

      Po to wymyślono renumerator.

      Czy poza trudnościami w edycji niesie to jeszcze jakieś inne zagrożenia?

      Nie.

      Co do ogólnych zasad programowania w BASIC-u. Trzeba je znać, ale jak sama nazwa wskazuje – są ogólne. W szczegółowych, konkretnych rozwiązaniach zawsze należy kierować się zdrowym rozsądkiem.
      Według mnie nie należy poświęcać przejrzystości programu jeśli nie jest to konieczne. Teraz pamiętasz co i jak, ale jeśli zajdzie potrzeba aby powrócić do programu za np. rok, to mętny kod będzie dużą przeszkodą, może nawet nie do pokonania.
    10.  

      Bluki:

      Ależ korzysta! Jak każda w GR.0. Oto przykład po uruchomieniu spod mojego inicjalizera:
      Czyli prawdopodobnie inicjalizer ustawia margines na 0 i nie przywraca go na 2 przy uruchamianiu gry. Podobnie będzie więc z teksem w okienku na stronie startowej oraz na podpisie przy końcowym obrazku. Rzeczywiście, rozsądnie byłoby sprawdzać wszystkie precondition na początku gry albo też zawsze polegać na POSITION, a nie na zwykłym PRINT. Poprawię to.

      Bez jaj! Przecież to tylko jedno POKE na początku i drugie przy wyjściu z programu.
      Przecież nie napisałem, że to ciężka praca, albo, że mi się nie chce. Parę razy Break mi się przydało, np. żeby przerwać program i zobaczyć ile zostało jeszcze wolnej pamięci. Zakładam, że jak ktoś wciska Break to wie co robi.

      Mówiąc inaczej, to kwestia profesjonalizmu
      Hmm... Stwierdzenie lekko kontrowersyjne :)

      Po to wymyślono renumerator
      Parę postów wyżej wyjaśniałem, dlaczego nie chcę z niego skorzystać. Chociaż teraz gdy czytelność kodu zeszła na drugi plan, mogę przelecieć nim po gierce.

      Według mnie nie należy poświęcać przejrzystości programu jeśli nie jest to konieczne. Teraz pamiętasz co i jak, ale jeśli zajdzie potrzeba aby powrócić do programu za np. rok, to mętny kod będzie dużą przeszkodą, może nawet nie do pokonania.
      Święta prawda. Z ilością pamięci byłem jednak w pewnym momencie pod ścianą, więc przejrzystość miałem gdzieś :) Zresztą, po wycięciu DATA to raptem 288 linijek kodu... Nie upłyną dwa piwa i każdy koder połapie się, co poeta miał na myśli :)
      • 11: CommentAuthorBluki
      • CommentTime5 Mar 2012 15:03
       
      Nie trzeba nic sprawdzać (margines). Wystarczy przed pierwszym GR.0 wstawić POKE 82,2.
    12.  

      Bluki:

      Wygląda na to, że masz sformatowaną dyskietkę w formacie SD (707 free sect.), a powinna być w ED (999+ free sect.).
      Wydaje mi się, że formatowałem jako ED. Jeśli spojrzysz na prawy, dolny róg MakeATR na załczniku, to widać tam wyraźnie "AtariDOS, ED".
      • 13: CommentAuthorBluki
      • CommentTime5 Mar 2012 21:03
       
      To jakim cudem zabrakło wolnego miejsca na dysku (error 162). Odczytaj katalog tego dysku z poziomu DOS-a i pokaż zrzut ekranu.
      • 14:
         
        CommentAuthorlarek
      • CommentTime5 Mar 2012 22:03 zmieniony
       
      Cóż, postanowiłem samemu sprawdzić jakie problemy są z kompilowaniem. Efekt w załączniku.
      Problemem jak na razie nie jest miejsce na dyskietce (choć pewnie później to też by wyszło - patrz kolejny post), ale konstrukcja programu - np. skoki do linii określonych w zmiennych, a nie stałych. Tego raczej kompilator nie przetrawi.
      • 15:
         
        CommentAuthorlarek
      • CommentTime5 Mar 2012 22:03 zmieniony
       
      A oto (prawie) instrukcja do kompilatora. Może się komuś przyda.


      i wszystko stało się jasne :)
      • 16: CommentAuthorBluki
      • CommentTime5 Mar 2012 23:03
       
      Ano tak. Mgr_inz_rafal nic nie wspomniał o tych błędach kompilacji.
      Można spróbować z kompilatorem TBXL, on chyba "łyka" skoki do linii określonych w zmiennych.
      ->link<- (źródło)
      ->link<- (pobieranie)
      • 17:
         
        CommentAuthorlarek
      • CommentTime5 Mar 2012 23:03 zmieniony
       
      Kompilator TBXL łyka program, ale uruchomić gry się nie da (wyświetla się informacja o ciemnościach, światło gaśnie i... na tym się kończy). Zresztą gra nie działa w Turbo-Basicu XL, więc byłoby dziwne, gdyby po skompilowaniu działała.
      • 18: CommentAuthorBluki
      • CommentTime6 Mar 2012 00:03 zmieniony
       
      Przyczyną niedziania raczej nie będą te nieszczęsne skoki. Skompilowałem kompilatorem TB grę SUPEREVERSION, a tam jest taki "kwiatek":

      • 19:
         
        CommentAuthorlarek
      • CommentTime6 Mar 2012 00:03 zmieniony
       
      TBXL ma trochę inny rozkład pamięci, jeśli można to tak ująć (np. w innym miejscu jest pamięć ekranu, RAMTOP jest inaczej ustawiony: Atari Basic PEEK(106)=160, TBXL=192). Może być cała masa rzeczy, które uniemożliwiają uruchomienie programu pisanego w Atari Basic w Turbo-Basic XL zarówno przed jak i po kompilacji (np. korzystanie z tablic liczbowych). Ale, jak już wspomniałem, jeśli ta gra nie działa w TBXL przed kompilacją, to nie ma co się spodziewać, że zacznie działać po potraktowaniu jej kompilatorem TBXL.
      A w zasadzie to po co ją kompilować? W obecnej formie jest całkiem dobra.
      • 20: CommentAuthorBluki
      • CommentTime6 Mar 2012 00:03
       
      Też uważam, że nie ma potrzeby kompilacji. Należałoby tylko zastosować procedurę maszynową do generatora znaków, aby nie trzeba było czekać całej wieczności. A człowiek nie jest już taki młody i czasu coraz mniej :D
      • 21:
         
        CommentAuthorlarek
      • CommentTime6 Mar 2012 01:03
       
      Procedurę maszynową? Nie ma takiej potrzeby.
      Niech mi AUTOR gry wybaczy...
      Na usprawiedliwienie dodam, że program nadal nie zawiera ani grama języka maszynowego, a przynajmniej ja nic takiego nie dodałem do kodu :)
      • 22:
         
        CommentAuthorTenchi
      • CommentTime6 Mar 2012 03:03
       
      Chyba nie minął nawet tydzień od ukazania się gry, a tu już zaczynają krążyć cracki z fixami... :)
      • 23:
         
        CommentAuthorKaz
      • CommentTime6 Mar 2012 05:03
       

      larek:

      A oto (prawie) instrukcja do kompilatora. Może się komuś przyda.


      Ta sama instrukcja, ale w wersji tekstowej, jest na AOL od stycznia 2008 roku w dziale FAQ, do ktorego link zapodawalem, ale przypomne:

      ->link<-
      • 24:
         
        CommentAuthorlarek
      • CommentTime6 Mar 2012 08:03
       
      Kaz, rzeczywiście... moje niedopatrzenie, przepraszam. Tak to jest jak się nie chce człowiekowi czytać :(
    25.  

      larek:

      Problemem jak na razie nie jest miejsce na dyskietce (choć pewnie później to też by wyszło - patrz kolejny post), ale konstrukcja programu -

      np. skoki do linii określonych w zmiennych, a nie stałych. Tego raczej kompilator nie przetrawi.

      Bluki:

      Ano tak. Mgr_inz_rafal nic nie wspomniał o tych błędach kompilacji.

      Rzeczywiście mogłem dać więcej info. W komentarzach do nowinki na głównej napisałem, że musiałem wprowadzić małe poprawki w kodzie - głównie właśnie skoki

      bez zmiennych oraz DIM bez zmiennych. Po tych zmianach kompilator dociągnął prawie do końca, zgodnie ze screenem:

      Niestety, nawet wycięcie 80 procent linijek DATA nie pomogło. Kompilator dobrnął wtedy do ostatniej linijki, ale i tak rzucił DiskFull.

      larek:

      Ale, jak już wspomniałem, jeśli ta gra nie działa w TBXL przed kompilacją, to nie ma co się spodziewać, że zacznie działać po potraktowaniu jej kompilatorem TBXL.

      Do tematu TBXL chciałbym jeszcze przysiąść, zwłaszcza, że jeszcze parę dni temu gra działała i mogłem mierzyć performance procedurki rysującej psa. Gra była już wtedy w wersji prawie skończonej (z generatorem znaków, itp.). Nie kojarzę od tego czasu jakiejś drastycznej zmiany, która zepsułaby kompatybilność z TBXL.

      Niech mi AUTOR gry wybaczy...
      Na usprawiedliwienie dodam, że program nadal nie zawiera ani grama języka maszynowego, a przynajmniej ja nic takiego nie dodałem do kodu :)

      Autor nie ma czego wybaczać, zwłaszcza pomocy :) Ale w pierwszej chwili zgłupiałem... Zniknęły moje DATA! Widzę, że to jest jakiś myk z fontem na dyskietce, co chyba dyskwalifikuje program jako przenaszalny przez CSAVE/CLOAD, nie? Trochę mi na tym zależy... W ramach nauki chyba szarpnę się jednak na tę wstawkę ASM.

      Bluki:

      To jakim cudem zabrakło wolnego miejsca na dysku (error 162). Odczytaj katalog tego dysku z poziomu DOS-a i pokaż zrzut ekranu.
      Nie wiem... Zwłaszcza, że miejsce jeszcze jest. Może kompil chciał utworzyć plik większy niż 360 sectors. Screen poniżej, załączam też obraz dyskietki dla dociekliwych (SOURCE.ATR).


      Kaz:

      To moze generuj je po wyznaczeniu trasy?
      Tak to właśnie będzie, tylko znowu spadnie trochę speed przygotowania planszy do gry. Kurde, każdy IF w Basicu ma - jak się okazuje - znaczenie prędkościowe :)
    26.  
      OK, mały update.

      Problemy z uruchomieniem pod TBXL wynikały z tej linijki:
      4010 POKE 106,144


      Początkowo wyglądała tak:
      4010 POKE 106,PEEK(106)-16

      ale zgodnie z sugestią Bluki-ego zmieniłem na sztywne 144.

      Nie sugeruję, że Bluki mi coś źle doradził. Ważne, że na razie poszło pod TBXL.

      Grę udało mi się też skompilować (bez modyfikacji etykiet skoków). Po uruchomieniu rzeczywiście "parę sekund" to "parę sekund", a nawet mniej. Niestety pograć nie można, gdyż wyskakuje "Fehler 3", tak jak na obrazku. Na razie niestety nie mam czasu bardziej pokombinować...

      Dołączam też gotową dyskietkę z DOSem, TBXL runtime i skompilowaną grą.

      • 27: CommentAuthorw1k
      • CommentTime6 Mar 2012 11:03 zmieniony
       
      i try make autostart program, but is strange..
      • 28: CommentAuthorBluki
      • CommentTime6 Mar 2012 15:03
       
      I tak to z Psa Antoniego zrobił się problem międzynarodowy :) Biedny piesek...

      mgr_inz_rafal:

      Widzę, że to jest jakiś myk z fontem na dyskietce, co chyba dyskwalifikuje program jako przenaszalny przez CSAVE/CLOAD, nie? Trochę mi na tym zależy...

      Nie dyskwalifikuje, ale czyni wersję kasetową uciążliwą. W takiej sytuacji łatwo i przyjemnie problem można rozwiązać tylko przy pomocy „protezy” o której wspomniałem wcześniej.

      Może kompil chciał utworzyć plik większy niż 360 sectors.

      To by tylko potwierdzało, że gra ma za dużą objętość, aby ją kompilować (przynajmniej przy pomocy MMG).

      ...ale zgodnie z sugestią Bluki-ego zmieniłem na sztywne 144.
      Nie sugeruję, że Bluki mi coś źle doradził. Ważne, że na razie poszło pod TBXL.


      Pozwolę sobie obalić pewien mit mówiący, że Turbo BASIC XL jest kompatybilny w górę z Atari BASIC-em. Nie jest. Pozwala uruchamiać programy napisane w Atari BASIC-u, a to nie to samo. Wiele gier będzie nieprawidłowo działać ze względu na znacznie większą szybkość TBXL. Efekty dźwiękowe w większości będą odtwarzane nieprawidłowo. O innych różnicach, w tym organizacji pamięci wspominał larek. W konkretnym przypadku wskazane jest ustawić RAMTOP na 176. W praktyce bez większych problemów uda się uruchomić tylko bardzo proste gry. Nieco inaczej jest w przypadku BASIC-a XE, ten ma tryb zgodności z AB, ale i on, prawdę powiedziawszy, nie jest 100 procentowy. Generalnie należy uruchamiać gry pod takim interpreterem BASIC-a, pod jakim gra jest napisana.
      Tylko po co przyspieszać „Psa”? Gra się doskonale sprawuje pod AB (z wyjątkiem nieszczęsnego generatora znaków). Aby otrzymać wyścigowego „Psa Antoniego”?

      Lepiej zastosuj szybko jakąś procedurę maszynową do generatora znaków, zanim problem „Psa Antoniego” z europejskiego stanie się światowym :D
    29.  

      Bluki:

      Tylko po co przyspieszać „Psa”? Gra się doskonale sprawuje pod AB (z wyjątkiem nieszczęsnego generatora znaków).
      To co leży mi na wątrobie, może nawet bardziej niż generator znaków, to długie oczekiwanie na wyznaczenie trasy. Pod TBXL działało zdecydowanie szybciej. Tak jak pisałem, mam tu jeszcze jeden pomysł na optymalizację ale nie wiem na ile okaże się on efektywny. Ostatecznie przepiszę tę część również do ASM, jeśli w ogóle podołam z tematem.

      Lepiej zastosuj szybko jakąś procedurę maszynową do generatora znaków
      W tym celu zaraz przeszukam forum pod kątek wskazówek do ASm i ewnetualnie zacznę nowy wątek.

      Generalnie należy uruchamiać gry pod takim interpreterem BASIC-a, pod jakim gra jest napisana.
      Kompilacja to poboczny wątek gierki, a właściwie bardziej poletko doświadczalne do powiększenia mojej wiedzy na temat Atarynki. Aż mnie korci, aby odkopać Bisona i Flexa, odkurzyć mózg i studenckie notatki oraz napisać jakiegoś kompila Atari Basic na PC :)
      • 30:
         
        CommentAuthorlarek
      • CommentTime6 Mar 2012 18:03
       

      mgr_inz_rafal:

      Aż mnie korci, aby odkopać Bisona i Flexa, odkurzyć mózg i studenckie notatki oraz napisać jakiegoś kompila Atari Basic na PC :)

      I to jest wiadmość dnia!
      • 31: CommentAuthorBluki
      • CommentTime6 Mar 2012 22:03
       

      mgr_inz_rafal:

      To co leży mi na wątrobie, może nawet bardziej niż generator znaków, to długie oczekiwanie na wyznaczenie trasy.

      I tu się nie zgodzę. Oczekiwanie na wyznaczenie trasy podnosi napięcie i atrakcyjność gry. To tak jak w żużlu: motory przed startem muszą trochę „powarczeć”, zanim taśma pójdzie w górę. Połowę atrakcji diabli by wzięli, gdyby zawodnicy podjeżdżali i od razu startowali. Co innego jednak, gdyby na starcie przez 40 sekund próbowali uruchomić maszyny...
    32.  
      OK, jest już procedura maszynowa do tworzenia znaków. Nie jest to szczyt wyrafinowania, ale pozwoliła uzyskać dziesięciokrotne przyspieszenie w stosunku do oryginału.

      Trochę dałem ciała, gdyż:
      1. Uparłem się, żeby procedury generujące znaki zawrzeć w zmiennej tekstowej, wywoływanej przez USR(ADR($)), aby zaoszczędzić miejsce. Ponieważ jednak nie umiałem w takim przypadku skorzystać ze skoków w ASM, więc kod to po prostu seria przesunięć z i do rejestrów...
      2. Dodatkowo, nie poradziłem sobie jeszcze z problemem adresowania względnego, dlatego też nie udało mi się w tym przypadku skorzystać z parametrów do USR(), np. USR(ADR($), nr_znaku, 4*2 bajty znaku). Gdyby nr znaku było 8 bitowe, to jeszcze bym dał radę :)
      3. W związku z tym wyszło mi 18 osobnych zmiennych X$ do odpalenia przez USR :( Dodatkowo w części z nich musiałem zamieniać znaczek 0A na inny, a potem podmieniać na CHR$(10) - tu objawia się drugie danie ciała, czyli wczytywanie programu przez H6 z tłumaczeniem znaków końca linii :) Z tego co widzę, na $9B chyba bym nie trafił...

      Ogólnie, te wszystkie znaczki zajmują pewnie więcej miejsca niż linijki DATA. Ale to dobry trade-off w zamian za prędkość :)

      Za to z mojej procedurki kopiującej znaki z ROMu jestem dumny :) Ładnie mi weszła między 1536 i 1571 i działa jak piorun :)

      Giery jeszcze nie publikuję, żeby nie było za często :) Przez weekend może trochę podziergam...

      No i muszę wieczorem sprawdzić, czy Real Atari nie wybuchnie od moich eksperymentów z ASM :) Może jakiś killer-poke tam nieświadomie przemyciłem...

      Poniżej krótki film z generowania znaków w obecnej postaci:


      ___________________
      EDIT: Heh, jedna debugowa pętelka zostawiona w kodzie... :) Bez niej już tylko 1,5 sekundy ciemności :)
      • 33:
         
        CommentAuthorjhusak
      • CommentTime9 Mar 2012 13:03
       
      Nie wiem, czy było poruszane, ale AB w pierwszych liniach działa szybciej, bo linie są wyszukiwane po numerach od początku liniowo.

      Więc najbardziej obciążające procek fragmenty kodu trzeba dać na początek.
    34.  

      jhusak:

      Nie wiem, czy było poruszane, ale AB w pierwszych liniach działa szybciej
      Tak, Bluki, larek lub już nie pamiętam kto sugerował taki myk parę wpisów temu. Zgodnie z tą sugestią przeniosłem bliżej góry logikę gry, bo tam jest największe zagęszczenie różnych skoków.
    35.  

      larek:

      I to jest wiadmość dnia!
      Parser może bym jeszcze wydziergał, ale syntezą kodu ASM już musiałby zająć się jakiś twardziel, bo ja to na razie dobrze opanowałem tylko PLA i RTS :)
      • 36: CommentAuthorBluki
      • CommentTime9 Mar 2012 16:03
       

      mgr_inz_rafal:

      Tak, Bluki już to sugerował parę wpisów temu.

      Kurczę, kompletnie tego nie pamiętam... (chociaż sugestia jak najbardziej słuszna). Osobiście stawiałbym na larka :)
    37.  
      Hmm, teraz też już nie pamiętam... ale, żeby nikomu nic nie ująć, poprawiam wpis :)
    38.  
      Na dzisiaj kilka zmian i jedno pytanie techniczne :)

      Zmiany:
      - Szybki generator znaków
      - Mniej migania ekranu (lepsze rozłożenie POKE 559)
      - Po obrazku końcowym można grać od nowa, a nie tylko wciskać RESET (optymalizacja pamięci za pomocą techniki CLR)
      - Ślimaki i drzewa zawsze są poza drogą - nie można się już przez nie przegryzać :)
      - Inny wygląd ślimaków, z każdym etapem coraz mroczniejszy :) Skoro mam już szybki generator znaków, to co sobie będę żałował :)

      Obrazki, ew. filmiki przedstawię jutro...

      I sprawa techniczna:
      Do dystrybucji gry używam DOSu: "Dos II+ D 6.4+ (Basic autorun).atr"
      Niestety, musiałem nieznacznie uprościć obrazek końcowy, bo brakowało pamięci. Z moich obliczeń wynika, że Dos ten potrzebuje 6384 bajtów dla siebie. Jest to dość dużo w kontekście walki o każdy bajcik, których teraz pozostaje wolnych tylko 617.

      I tutaj pytanie: Ponieważ 617 oznacza, że już praktycznie nic do gry nie dodam (no chyba, że kosztem dalszego upraszczania obrazka) szukam informacji, czy istnieje jeszcze jakiś prostszy, bardziej okrojony DOS, który zrobi mi autorun?
      • 39: CommentAuthorBluki
      • CommentTime11 Mar 2012 01:03 zmieniony
       
      Na mojej "dyskietce" AutoBAS masz ok. 250 bajtów więcej. Możesz też pokombinować z innymi DOS-ami, trzeba tylko umieścić AUTORUN.SYS i AUTORUN.BAS (no i "Psa") na takim ATR-erze.

      Uwaga. Nazwa Twojej gry może być dowolna, ale rozszerzenie musi być .BAS. Grę uruchamiamy z włączonym BASIC-em w emulatorze lub bez wciskania OPTION w Atari.
    40.  
      Kurcze, dla 250 bajtów chyba nie będę dalej kombinował... Może to nawet lepiej, bo najwyższy czas skończyć z psem i zająć się czymś trudniejszym :)

      Na razie dorzucam trzy screeny. ATRa wrzucę po testach.

      #1
      Nowa faza przygotowywania levelu - sadzenie drzewek i ślimaków poza trasą


      #2
      Drugi etap gry - zamiast ślimaków, niejadalne grzyby


      #3
      Etap trzeci i ostatni - zamiast niejadalnych grzybów złowieszcze czaszki z Marsa
      • 41: CommentAuthorBluki
      • CommentTime11 Mar 2012 13:03 zmieniony
       
      Jak uzyskać więcej RAM-u na grę.

      1) Zysk 2kB: RAMTOP=160, CHB=136 (czyli POKE 106,160:POKE 756,136)

      2) Zysk 3kB: RAMTOP=160, CHB=140. Jednak wykonanie GR.7 spowoduje uszkodzenie generatora znaków przez display list. Trzeba po GR.7 przepisać DL na 6 stronę pamięci, przełączyć ANTIC na nowy adres i odtworzyć generator znaków.

      3) Zysk 4kB: RAMTOP=160, CHB=224. Trzeba przepisać OS z ROM do RAM i zmodyfikować generator znaków pod adresem bazowym 224.

      4) Dwie wersje gry: dyskowa z doczytywanym obrazkiem końcowym i kasetowa bez albo z mocno uproszczonym obrazkiem.

      5) Zysk jakieś 33kB. Użyć BASIC-a XE w trybie extended. Wadą jest to, że część użytkowników nie będzie miała dostępu do gry na prawdziwym Atari (pod emulatorem bez ograniczeń). Wymagania to kartridż BASIC XE i komputer z co najmniej 128kB.

      To tyle co przyszło mi do głowy. Użycie TBXL dałoby jakieś 2-3 kB, ale konieczna byłaby przeróbka programu, co raczej nie ma sensu.

      PS. Trzeci poziom jest już tak mroczny, że aż ciarki przechodzą :)
      • 42: CommentAuthormono
      • CommentTime11 Mar 2012 21:03
       
      Przepisanie OSu do RAM może się źle skończyć dla DOS II/D+ i SpartaDOS X skonfigurowanego na OSRAM. Jeśli chciałbyś, żeby gra mogła być odpalana z SDX np za pomocą:
      BASIC PIES.BAS

      albo z wykorzystaniem RUNEXT (możliwość automatycznego skojarzenia rozszerzenia BAS z poleceniem BASIC) to proponuję nie iść w tym kierunku.
    43.  
      Bluki, dzięki za jak zwykle cenne wskazówki. Na razie nie będę dalej kombinował. Jestem z pamięcią "na styk" i biorę się powoli za jakiś nowy projekt :)

      A dla zwolenników mocnych wrażeń: prawie pół godziny rozrywki z psem na Real Atari, niestety nie w 3D :) Uwaga: SPOILER!

      "Biedny Pies Antoni" walkthrough


      PS. ATR jeszcze nie wypieczony...
      • 44: CommentAuthorat0mic
      • CommentTime12 Mar 2012 10:03 zmieniony
       
      SUPER!


      rozśmieszyło mnie tylko jak zamiast RUN napisałeś RU.

      niesamowity skrót ;) a jak ktoś nie wie o co chodzi to pełna profeska;)
      • 45:
         
        CommentAuthorKaz
      • CommentTime12 Mar 2012 11:03
       
      Obejrzalem caly filmik :)
      Rzucilo mi sie w oczy, ze kiedy misja jeszcze nie skonczona, juz pojawia sie 100% wykonania misji na gorze ekranu.
    46.  

      at0mic:

      a jak ktoś nie wie o co chodzi to pełna profeska;)
      Hehe, to trochę tak jak kiedyś się instalowało Linuxa tylko po to, żeby przy dziewczynie napisać "ls" i udawać, że się coś rozumie :)

      Kaz:

      Obejrzalem caly filmik :)
      Gratuluję :)
      kiedy misja jeszcze nie skonczona, juz pojawia sie 100%
      To wynik małego kompromisu między dokładnością obliczeń i prędkością psa. W tej chwili koniec misji to trochę ponad 100%, ale sztucznie przycinam wyświetlanie na 100 :)
      • 47:
         
        CommentAuthoranonymus
      • CommentTime12 Mar 2012 15:03
       
      obrazek końcowy to zgroza;D
    48.  
      Miło mi zaprezentować kolejną i już prawdopodobnie ostatnią wersję gry. Nie planuję więcej jej poprawiać, chyba, że ktoś odnajdzie jakiegoś buga - blockera.

      W załączeniu plik "Biedny Pies Antoni 2.0.atr".

      Zmiany w stosunku do ostatnio publikowanej wersji 1.8 wypisane są poniżej. Dwie pierwsze i najważniejsze wynikają w dużej mierze z przeprowadzonych na rodzinie testów oraz potrzeby zbalansowania poziomu trudności. Część z tych zmian opisałem już w jednym z poprzednim postów, ale wtedy nie publikowałem gry, więc pozwolę je sobie powtórzyć.

      Balans:
      1. Trasy do pokonania przez psa stają się coraz bardziej skomplikowane w miarę postępu gry. Nie tylko są węższe, ale również bardziej zakręcone (parę obrazków poniżej)
      2. Trampolina z kolei, w miarę postępu gry, pozwala zerknąć na trasę coraz dłużej

      Technikalia:
      1. Szybki generator znaków
      2. README.TXT dołączony do dyskietki jest w formacie ATASCII :)
      3. Mniej migania - lepsze umiejscowienie POKE 559
      4. Po obrazku końcowym można zagrać od nowa
      5. Drzewa i ślimaki zawsze umiejscawiane są poza trasą, nie można się już w nie wgryzać
      6. Inny wygląd ślimaka na każdym etapie

      Pozostałe zmiany:
      1. Dwa semigraficzne psy na ekranie tytułowym
      2. Nowy kolor drugiego etapu gry
      3. Podgląd procesu tworzenie fauny i flory

      Teraz czas zabrać się za coś w ASM :) Display Listę już mam :)

      PS. Oto wspomniane obrazki:

      Trasa łatwa:


      Trasa trudna:


      I trasa najtrudniejsza:


      I jeszcze bonus-track. Tyle bajtów mi zostało :)
      • 49:
         
        CommentAuthorxeen
      • CommentTime16 Mar 2012 23:03
       
      ogólnie to mi się w małym atari podoba. że można z przyjemnością sprawdzić jakiś pomysł - a pomysł jest naprawdę fajny. niezła grywalność jak na basic ;)
      dzięki
      • 50: CommentAuthorMaciek
      • CommentTime17 Mar 2012 00:03
       
      Dobra gra jak na pierwszy raz, dołączyłem ją do mojego weekendowego zestawu na jutro :) Teraz powoli zgłębiaj tajniki ASM, proponuję na początek wariant pośredni czyli wstawki ASM w Bazylu. I gorąco zachęcam do pracy na prawdziwym Atari! Nie zrozum mnie źle, ja też sobie coś tam robię w excelu i pixeluje w paincie, jestem przeciwnikiem crosscompilerów.

    Od 101 do 150 z 178

    1. <
    2. 1
    3. 2
    4. 3
    5. 4
    6. >