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 51 do 100 z 178

    1. <
    2. 1
    3. 2
    4. 3
    5. 4
    6. >
      • 1:
         
        CommentAuthormgr_inz_rafal
      • CommentTime25 Feb 2012 00:02 zmieniony
       
      Dzisiaj niewiele nowości, bo sporo czasu spaliłem na walkę z Display Listą... Ale dzięki temu powstała plansza tytułowa z niesamowitym, mrocznym klimatem :) Dodatkowo wyposażyłem psa w cel jego wędrówki - napędowe znicze do super-rakiety, którą wróci do swojej budy [ktoś tu pytał o dziwne gry na Atari?] :) Ograniczyłem też maksymalną długość spaceru do 150 kroków, żeby wykluczyć człapanie w nieskończoność.

      Właściwie zostało mi stworzenie zaskakującego zakończenia, udźwiękowienie wersji polskiej, obsługa wajchy i można robić pierwszą publikację :) Chyba zrezygnuję z dodatkowych przeszkadzajek, bo gra i tak jest dość trudna, przynajmniej dla mnie :)

      Nauką podkolorowywania duszkami zajmę się później.

      Oto dwa obrazki:


      • 2: CommentAuthorBluki
      • CommentTime25 Feb 2012 00:02
       
      Gra nabiera rumieńców :)
      Te znicze rzeczywiście wprowadzają mroczny klimat :)
      Ze trzy przeszkadzajki na wyższych arenach to by się przydały. Bez tego może być nieco monotonnie. Na konkretnej planszy wystarczy gdy pojawi się jedna.

      Gdzie się podziały ogonki i kreski w polskich literach?
    3.  

      Bluki:

      Gra nabiera rumieńców :)
      Dzięki :)

      Ze trzy przeszkadzajki na wyższych arenach to by się przydały
      Na pewno poprawiły by efekt wizualny, ale już teraz pograć jest tak trudno, że zastanawiam się nad ułatwiaczem, a nie przeszkadzajką :) Balansowanie jeszcze trochę odłożę w czasie. Może jak parę osób zdecyduje się zagrać to pojawią się sugestie, czy należy gierkę ułatwiać, czy utrudniać.

      Gdzie się podziały ogonki i kreski w polskich literach?
      Losy Pliterek jeszcze się ważą... Nie wiem, czy starczy mi wolnych miejsc na ich zdefiniowanie :(
      • 4: CommentAuthorBluki
      • CommentTime25 Feb 2012 01:02
       
      Zawsze jest sposób aby polskie litery się zmieściły - nawet gdy wszystkie znaki są zajęte. Bez tego gra będzie "kulawa", mamy przecież XXI wiek!

      Przeszkadzajka nie musi być straszna, byle by było urozmaicenie. Tak mi się wydaje.
      • 5:
         
        CommentAuthorjhusak
      • CommentTime25 Feb 2012 03:02 zmieniony
       
      Ta gra zaraża! chciałem się zalogować, a przez myśl mi przeszło:

      Zaloguj się, biedny psie!

      Co do polskich literek to podczas gry są potrzebne 3.
      ŁĘÓ.
      Tekst na początku też można tak zmienić, żeby miał mniej, niż wszystkie, polskich literek.
      Poza tym w grze duże literki, a na titlescreenie małe...
      Jeśli to jest ten sam generator znaków, to straszne marnotrawstwo oraz brak spójności - gdzieś był post, że duże są specjalnie.

      Chociaz z drugiej strony, takie nie-polskie literki tez maja swoj urok.

      A gdyby tak zmienić kolor na bardziej nie-basicowy?
      • 6:
         
        CommentAuthormgr_inz_rafal
      • CommentTime25 Feb 2012 19:02 zmieniony
       

      Bluki:

      Zawsze jest sposób aby polskie litery się zmieściły

      jhusak:

      Tekst na początku też można tak zmienić, żeby miał mniej, niż wszystkie, polskich literek.
      Poza tym w grze duże literki, a na titlescreenie małe...

      Teksty będę zmieniał na pisane małymi literkami. Zwolni się wtedy sporo dużych liter do przedefiniowania.

      jhusak:

      Ta gra zaraża! chciałem się zalogować, a przez myśl mi przeszło:
      Zaloguj się, biedny psie!

      Hehe, w takim razie muszę jeszcze bardziej podziałać podprogowo :) Może jak między levelami umieszczę napis "wpłać 100zł na konto mgr_inz_rafal" to część osób się zahipnotyzuje :)

      A zanim zmienię kolory na mniej basicowe chciałbym zapytać o przyczynę efektu widocznego na poniższym obrazku. Pojawia się on na końcy gry, gdy włączam GR. 7 i chcę narysować obrazek końcowy. Po dolnej części ekranu (tam gdzie są krzaczory) nie da się rysować. W okienku tekstowym widać wynik FRE(0), więc zapas chyba jeszcze jest. Ma ktoś jakieś pomysły?



      PS. Altirra nie wyświetla tych kolorowych artefaktów, ale również nie pozwala rysować po dolnej części ekranu...
      • 7: CommentAuthorBluki
      • CommentTime25 Feb 2012 20:02 zmieniony
       
      Pewnie masz źle ustawiony RAMTOP.
      Wykonując GRAPHICS n, system operacyjny tworzy „standardową” display list, a to oznacza dla GR. 7 , że adres ustawiony w RAMTOP (komórka 106) musi być podzielny przez 16. Na przykład 160, 144... Możesz umieścić pamięć ekranu w dowolnym miejscu RAM (byle wolnym), nawet podzielić ekran na kawałki umieszczone w różnych miejscach pamięci, ale wtedy trzeba stworzyć własną DL.

      Jako ciekawostkę dodam, że w grze WYPRAWA ekran podzielony jest na dwie części zlokalizowane w dwóch różnych miejscach RAM.
    8.  
      Dzięki! Rzeczywiście problem był w 106. Przed redefinicją znaków ustawiam POKE 106, PEEK(106)-4, co ustawia 106 na 155.

      Uratowałeś wieczór po raz kolejny :)

      Zmieniłem PEEK(106)-4 na PEEK(106)-16, wszystko zaczęło działać. Tak się tylko zastanawiam nad RAMem, bo teoretycznie na tablicę znaków potrzebuję 1kb, więc -4 było OK. Czy ustawiając -16 nie "tracę" czasem 3kb?
      • 9: CommentAuthorBluki
      • CommentTime25 Feb 2012 22:02
       
      PEEK(106)-16 to bardzo niebezpieczny sposób. Skąd masz pewność, że wartość pierwotna była prawidłowa? Bezpieczniej jest ustawić RAMTOP „na sztywno”, czyli POKE 106,144.
      Tak, tracisz 3kB na na program, ale zyskujesz na inne cele :) Rozmiar programu chyba nie jest tak duży, aby stanowiło to problem. Możesz też tak: POKE 106,160, a generator znaków umieścić pod adresem bazowym 136 (czyli od adresu 34816).
    10.  
      OK, poprawiłem na POKE 106, 144.

      Bluki:

      PEEK(106)-16 to bardzo niebezpieczny sposób. Skąd masz pewność, że wartość pierwotna była prawidłowa?

      Nie mam pewności. Po prostu założyłem, że po starcie Atari jest tam wartość prawidłowa. Nie brałem pod uwagę scenariusza, że Pies uruchamiany jest na czymś innym niż "czyste" Atari.

      Rozmiar programu chyba nie jest tak duży, aby stanowiło to problem.

      ? FRE(0) = 7008 :)
      Liczy się każdy kilobajt :)
      • 11: CommentAuthorBluki
      • CommentTime25 Feb 2012 22:02
       
      Chodzi o to, że przed Twoją grą mogło być uruchamiane coś innego, dlatego warto zawsze ustawiać na początku to wszystko, co może wpływać na "Psa" - np. lewy margines (kom. 82) czy RAMTOP.
    12.  
      Trzy poranne obrazki z postępów prac.
      1. Są już pliterki (oprócz dużego Ł)
      2. Małe napisy w trakcie gry
      3. Obrazek końcowy wykonany w technice PLOT, DRAWTO :)



      • 13: CommentAuthormar_tec
      • CommentTime26 Feb 2012 12:02
       
      Gratuluję pomysłu, zapału i powrotu do lat młodzieńczych.
      Nie rozumiem dlaczego masz magistra z kropką na stronie tytułowej?
    14.  

      mar_tec:

      Gratuluję pomysłu, zapału i powrotu do lat młodzieńczych.
      Dzięki.

      A żona nie może zrozumieć, o co mi chodzi :)

      Nie rozumiem dlaczego masz magistra z kropką na stronie tytułowej?
      Ja też nie :(
      Poprawię jak będę dorabiał Ł w RAFAL :)
      • 15: CommentAuthorBluki
      • CommentTime26 Feb 2012 13:02
       
      Biedny zezowaty piesek (jamnik?) Antoni :)

      Ogrodzenie ostrymi końcami jest wszędzie skierowane na zewnątrz z wyjątkiem dolnej części. Tak ma być, czy to błąd?
    16.  
      Ustawienie ogrodzenia jest celowe... Że niby tak trochę z ukosa widać :) Specjalnie przez to musiałem poświęcić dodatkowo dwa znaki na dwa dolne narożniki, które nie są symetryczne do górnych.
    17.  
      165 obrotów na XC12 i 7 minut później podrzucam jeszcze filmik wykonany na Real 800XL. Na początku listing, granie od 1:33 po zakończeniu działania generatora znaków.

      Filmik uwzględnia już zmianę koloru planszy na bardziej trawiastą.



      PS. Ścieżkę dźwiękową urozmaicał lokalny proboszcz ;)
      • 18: CommentAuthorcaruso
      • CommentTime26 Feb 2012 23:02
       
      Ach, te lokalne proboszcze... A lepszej (dla mnie) gry w Basic'u, oprócz "Hammurabi", chyba nie doznałem. Gratuluję i wspieram. :-)
      • 19:
         
        CommentAuthorKaz
      • CommentTime27 Feb 2012 00:02 zmieniony
       
      Te dzwony, a potem syrena policyjna doskonale sie komponuja z tymi mrocznymi przygodami psa Antoniego, proponuje je wstawic do gry jako sample :D

      Klimat gry przypomina mi produkcje Llamasoftu. Tak trzymaj biedny psie... tfu... Rafale :)
    20.  
      Mały update...

      Zmiany, które widać:
      1. Nie ma punktów ani numeru areny - zamieniłem je na procentowy wskaźnik ukończenia gry
      2. Dodałem dwa pomagacze w 1/3 i 2/3 drogi. Mają postać sprężynki, która wygląda jak śrubka. Pies może za ich pomocą rzekomo podskoczyć wysoko do góry, aby przez 4 sekundy rzucić jeszcze raz okiem na wyznaczoną trasę

      Zmiany, których nie widać:
      1. Optymalizacja ruchu psa. Kurde... Ale masakra z tym Basicem :) Wyszukałem i wywaliłem wszystkie niepotrzebne instrukcje, bo byle PRINT wykonuje się zauważalnie długo :) Przeniosłem też kod sterujący psem na początek programu, żeby skoki szybciej się wykonywały

      Kaz:

      dzwony, a potem syrena policyjna doskonale sie komponuja (...) proponuje je wstawic do gry jako sample

      Kurde, będzie problem, bo mam 505 bajtów wolnej pamięci :) Zastanawiam się, czy styknie mi jeszcze na jakieś biedne SOUND-y :) A jeszcze miał być bird na PMG :) Niepotrzebnie wstawiałem ten wysokiej jakości obrazek końcowy, a teraz szkoda mi go wywalić :)

      I dwa screeny:

      1. Pies na pierwszej "śrubce"


      2. Pies w pobliżu "śrubki"
      • 21: CommentAuthorbob_er
      • CommentTime28 Feb 2012 19:02
       
      ot, ale też o psach:
      • 22:
         
        CommentAuthorlarek
      • CommentTime28 Feb 2012 20:02 zmieniony
       

      mgr_inz_rafal:

      Kurde, będzie problem, bo mam 505 bajtów wolnej pamięci :)

      1.Usuń wszstkie REM-y. Szczególnie te na końcu listingu. Wydaje mi się, że spokojnie odzyskasz około 1KB.
      2.Pod koniec widzę również całą masę PLOT i DRAWTO. W takim przypadku upchnął bym to wszystko w postaci danych w formacie "I$,X,Y", gdzie:
      I$=instrukcja / np.: P=PLOT, D=DRAWTO
      X,Y=współrzędne

      Dane wyglądały by np. tak:
      DATA P,120,120,D,127,127,D,130,130,P,18,18,D,140,140,K
      co by było odpowiednikiem:
      PLOT 120,120:DRAWTO 127,127:DRAWTO 130,130:PLOT 18,18:DRAWTO 140,140

      A podprogram do rysowania np. tak:

      100 READ I$: IF I$="K" THEN RETURN
      110 READ X,Y
      120 IF I$="P" THEN PLOT X,Y:GOTO 100
      130 IF I$="D" THEN DRAWTO X,Y:GOTO 100
      140 IF I$=....(inne instrukcje)

      Jeszcze lepiej gdyby udało się zamienić wszystkie wspórzędne z liczb na znaczki ATASCII, a później je odkodowywać "w locie" na odpowiednie liczby. Zapis liczb zajmuje masę bajtów (8? - teraz nie jestem pewny), a jeden znak ATASCII zajmuje... 1 bajt i można w nim "ukryć" wartości od 0 do 255.


      3.Często używane stałe warto zastąpić zmiennymi. Zamiast wciąż wpisywać liczby 0,1,2 lub "x" robimy na początku:
      L0=0:L1=1:L2=2:Lx=x
      a później piszemy np. RND(L0) zamiast RND(0)

      4.Warto również umieszczać jak najwięcej instrukcji w jednej linii - jeśli to tylko możliwe
      • 23: CommentAuthormono
      • CommentTime28 Feb 2012 21:02 zmieniony
       
      Pod względem pamięciożerności DATA zajmuje tyle samo co REM. Ponieważ BASIC nie wie, jakie dane są trzymane (a mogą być przecież przeplatane dane liczbowe z tekstowymi), więc trzyma wszystko tak, jak jest wpisane - w postaci tekstowej (więc liczba 123 z przecinkiem zajmuje 4 bajty). Najmniej pamięciożerna metoda trzymania tablic to:
      A=ADR("bajty tablicy")

      bo konkretne bajty trzymane są bezpośrednio w pamięci programu. Dostęp do tego jest przez 
      PEEK(A+n)
      . Niestety PEEK jest dość wolny, ale chyba szybszy niż READ.
      Stałe tekstowe np. 
      A$="bajty tablicy":D=ASC(A$(1+n))
      wymagają zaadresowania tablicy i odczytu kodu ATASCII znaku - będzie wolniejsze. No i w pamięci będzie to trzymane 2 razy (raz w kodzie programu, drugi w obszarze tablicy znaków).
      Liczba podana wprost w stokenizowanym kodzie programu zajmuje 6 bajtów (8 bajtów zajmuje definicja zmiennej liczbowej, bo prócz tego ma jeszcze bajt z indeksem zmiennej i bajt z różnymi flagami), odwołanie do zmiennej 1.
      • 24: CommentAuthorBrix
      • CommentTime28 Feb 2012 21:02
       
      Skoro pamięci już tak mało, a pomysłów ciągle sporo, nieśmiało proponowałbym radykalne podejście: zmianę języka programowania :)
      • 25:
         
        CommentAuthorlarek
      • CommentTime28 Feb 2012 22:02 zmieniony
       
      Mono, masz oczywiście rację z danymi w DATA. I dlatego lepiej zamienić ciąg instrukcji "PLOT x,y:DRAWTO x,y: PLOT x,y:..." na dane zapisane w DATA + krótki podprogram do rysowania.
      Zakodowanie instrukcji i współrzędnych w znakach ATASCII daje jeszcze większe oszczędności.
      Przykład jak by to miało wyglądać:



      Zapodaję screena, bo chodzi mi o pokazanie szczególnie linii 100, gdzie mamy znaczki ATASCII. W 3 znakach (=3 bajty, ok niech będzie 4 bajty, bo jeszcze jest przecinek) można umieścić instrukcję i dwie współrzędne, np. "DRAWTO 123,78", co przy normalnym zapisie zajmuje bajtów kilkanaście. Przy wielu instrukcjach PLOT i DRAWTO, a w tej grze mamy taki właśnie przypadek, sporo zaoszczędzimy na pamięci.
    26.  
      mono, larek
      Dzięki za ciekawe pomysły. Najprościej będzie pozbyć się REMów :) Ale najciekawsza sprawa to kodowanie obrazka w ATASCII. Mogę też podobnie zakodować DATA do generatora znaków, na co zresztą wskazywał już Bluki na poprzedniej stronie wątku. Powalczę w najbliższych dniach i dam znać, ile udało się zaoszczędzić.

      Obrazek mogę nawet jeszcze bardziej zoptymalizować. Jego kod generuję sobie za pomocą makra w Excelu (tzn. tworzę obrazek w komórkach i potem skrypt generuje mi kod Basica). Obraz tworzony jest z poziomych linii, więc zawsze na zmianę występuje PLOT i DRAWTO (chyba, że jest do narysowania pojedynczy pixel, a to rzadki przypadek). Mogę zatem nie kodować instrukcji, tylko od razu współrzędne. Problem będzie tylko z COLOR, który czasem pojawia się przed PLOT, ale ograniczając rozdzielczość obrazka w pionie z 80 do 64, mogę wolne dwa bity współrzędnej pionowej wykorzystać na zakodowanie koloru :)

      Hmm, a właściwie skoro obrazek jest zbudowany z linii to wcale nie muszę kodować współrzędnej pionowej tylko znak końca linii, a ten może da się wcisnąć na jakiś bit współrzędnej poziomej :)

      Trochę piwa z butelki upłynie zanim to zrobię, ale zapowiada się ciekawy weekend :)

      Brix:

      Skoro pamięci już tak mało, a pomysłów ciągle sporo, nieśmiało proponowałbym radykalne podejście: zmianę języka programowania :)

      Zapewne po zakończeniu Psa spróbuję swoich sił w ASM :) Bądźcie gotowi na masę pytań :)
      • 27:
         
        CommentAuthorlarek
      • CommentTime29 Feb 2012 08:02 zmieniony
       

      mgr_inz_rafal:

      Mogę też podobnie zakodować DATA do generatora znaków

      I wcale nie trzeba tego robić ręcznie! Tak się składa, że znam jedyny (?) taki program, który potrafi to zrobić. Programem tym jest SupGen2000 2.0



      Jak już mamy wczytany nasz zestaw znaków, to wybieramy OPCJE->ZAPIS->nazwa pliku->.LST->MOVE i program zapisuje nam generator znaków w postaci linii ze znakami ATASCII. Zmienna GEN zawiera adres (numer strony) zestawu i może być dostosowana do własnych potrzeb.
      Wygląda to tak:




      Jedna uwaga! W ten sposób nie da się zapisać kodu 155 oraz podajże 34, więc jeśli znaki zawierają taki kod, to nic z tego nie będzie (można to obejść).

      A, jeszcze jedno. Podprogram generowany jest odpowiednikiem LIST, więc wczytać go do naszego programu należy poprzez ENTER "D:nazwa".
      • 28:
         
        CommentAuthorMaW
      • CommentTime29 Feb 2012 17:02 zmieniony
       
      można by też "zgrać" bloki pamięci z przetworzonymi znakami" i załadować z powrotem już w grze za pomocą procedury maszynowej...

      //EDIT: poniżej akurat testowałem ładowanie bezpośrednio zawartości do pamięci ekranu
      • 29:
         
        CommentAuthorlarek
      • CommentTime29 Feb 2012 20:02 zmieniony
       
      Przy magnetofonie sprawa z odczytywaniem czegokolwiek trochę się komplikuje, choć nie jest to niemożliwe. Gdyby autor gry porzucił taśmę na rzecz dyskietki to by dopiero można było szaleć z wczytywaniem zestawu znaków i grafiki :)
      • 30: CommentAuthorbolo
      • CommentTime29 Feb 2012 20:02
       
      Moim zdaniem te slimaki bardzo ulatwiaja gre
    31.  
      Zanim zacznę kombinować z doczytywaniem, muszę sprawdzić, ile ugram na poprzednich pomysłach optymalizacyjnych. Ostatecznie do końca gry nie jest daleko, więc nie będę musiał aż tak stawać na głowie w walce o każdy bajt.

      Do taśmy jestem przywiązany dlatego, że "stacja kaset XC12" to jedyne, czym dysponuję w ramach podłączania do prawdziwego Atari. Czekam wprawdzie na paczkę z Sio2SD, ale na razie...
      • 32: CommentAuthorBluki
      • CommentTime29 Feb 2012 23:02
       
      Wydaje mi się, że program powinien w całości zmieścić się bez doczytywania, po prostu kod jest daleki od optymalnego. Bardziej skomplikowane gry są pisane w BASIC-u. Moja "Dzika wyspa" korzysta w pewnym momencie z GR.7 i zostaje jeszcze ponad 7kB wolnego RAM.
      • 33: CommentAuthorgrzeniu
      • CommentTime1 Mar 2012 00:03
       
      Czy na ekranie głównym kropka po MGR jest dodana celowo w celu zwrócenia uwagi czy to tylko "zwykły" błąd ? :)
      • 34:
         
        CommentAuthorjhusak
      • CommentTime1 Mar 2012 00:03 zmieniony
       
      Jeszcze warto wspomnieć o bugu, który Basic ma. Mianowicie za każdym razem wykonując save czy csave, basic zapisuje cośtam jeszcze, co się kumuluje. Trzeba zrobić "list" i następnie po "new" dać "enter" - wtedy te śmiecie się skasują.
      • 35:
         
        CommentAuthormiker
      • CommentTime1 Mar 2012 06:03
       
      Tak, zapisywane są wszystkie zmienne, które zostały skasowane i już niby w programie nie funkcjanują. Chyba też jeszcze zapisują się te, które testowo były użyte w trybie natychmiastowym (poza listingiem).
      Także najlepiej zrobić tak, jak Kuba wyżej napisał. Od razu zrobi się luźniej.
      • 36:
         
        CommentAuthorlarek
      • CommentTime1 Mar 2012 07:03 zmieniony
       
      Można to w prosty sposób sprawdzić w Turbo-Basicu XL wpisując DUMP.



      Na powyższym przykładzie widać, że pomimo, iż zmieniliśmy linie 10 i usunięte zostały zmienne X,Y,Z$ to i tak w tablicy zmiennych one dalej zostały i zajmują miejsce.
    37.  

      Bluki:

      Wydaje mi się, że program powinien w całości zmieścić się bez doczytywania, po prostu kod jest daleki od optymalnego.
      Zdecydowanie masz rację. Tak się przez te parę lat kodowania na PC rozhulałem, że pisałem gierkę bardzo rozrzutnie, z czego teraz muszę się wycofywać :) O ile z samego kodu logiki gry pewnie za dużo już się wycisnąć nie da, to generator znaków i ciągi instrukcji do rysunku to duże pole do popisu. Chciałbym mimo wszystko utrzymać kod w duchu Basicowym i nie generować za dużo asemblerowych wstawek.

      Właściwie największym kilerem jest biedny rysunek biednego psa:
      Start Atari = 37902b
      Load program z rysunkiem (nie całą gierkę): 26391b, czyli ponad 11kb sam kod
      Po uruchomieniu programu w GR. 7: 23193
      Jeśli dobrze liczę, to sama grafika pozbawia mnie prawie 39% pamięci. Ale na to już są pomysły, tylko jeszcze nie miałem czasu ich wcielić :)

      grzeniu:

      Czy na ekranie głównym kropka po MGR jest dodana celowo w celu zwrócenia uwagi czy to tylko "zwykły" błąd ? :)
      Błąd. Zresztą już rozwikłany :) Nową planszę startową zamieszczam na końcu posta.

      jhusak:

      Jeszcze warto wspomnieć o bugu, który Basic ma.

      miker:

      Tak, zapisywane są wszystkie zmienne, które zostały skasowane i już niby w programie nie funkcjanują.

      Dobrze wiedzieć :) Choć daje się to we znaki przy pracy bezpośrednio na Atari. Ja właściwie klepię tylko w notepadzie, a potem ładuję plik do emulatora za każdym razem poprzedzając akcję cold resetem, co przywraca mi 37902b.

      A tu jeszcze obrazek strony tytułowej bez kropki po mgr i z literką Ł:
      • 38:
         
        CommentAuthorDracon
      • CommentTime1 Mar 2012 14:03 zmieniony
       
      Właściwie największym kilerem jest biedny rysunek biednego psa:
      Start Atari = 37902b

      Sa dwa rozwiazania - zlogosowac grafike (zamienic na tryb znakowy) albo zrobic obrazek psa z fontow systemowych (taki a[ta]scii-art). :)
    39.  
      Pierwsza optymalizacja inspirowana pomysłem larka.

      Zakodowałem obrazek w postaci linii DATA wg następującego schematu:
      1. W DATA na zmianę występuje współrzędna pozioma, raz dla PLOT, drugi raz dla DRAWTO. Czyli zapis DATA 4, 18 wykonuje PLOT 4,0:DRAWTO 18,0.
      2. Przeskok do następnej linii wykonany jest za pomocą -1
      3. -2 oznacza koniec rysunku
      4. Kolor zakodowany jest również na liczbie ujemnej wg wzoru COLOR = ABS(I+10), czyli -12 odpowiada COLOR 2

      Czyli, aby zakodować taki obrazek:
      10 COLOR 2: PLOT 10, 0: DRAWTO 50, 0
      20 PLOT 60, 0: DRAWTO 80, 0
      30 COLOR 1: PLOT 10, 1: DRAWTO 100, 1

      korzystamy z takiej linii DATA
      DATA -12,10,50,60,80,-1,-11,10,100

      wraz z prostą funkcją rysującą.

      Efekt:
      1. obrazek tworzy się koszmarnie wolno, prawie jak na starej drukarce :) Ale to dobrze, bo i tak mało kto dotrwa do końca gry, więc jak już dotrwa, to niech sobie ogląda :)

      2. FRE(0) wskazuje 8400 zamiast 505, czyli prawie 8kb do przodu :)

      3. Listing zmalał z 23965 bajtów do 20739 (rozumiany jako wielkość kodu źródłowego w notepadzie)

      ________________________________________________
      Druga optymalizacja: usunięcie komentarzy.
      Wynik: 11095b (+2695b)

      ________________________________________________
      Trzecia optymalizacja: zastąpienie stałych zmiennymi
      Wynik: 12676b (+1581b)

      ________________________________________________
      Czwarta optymalizacja: większe upakowanie liczb w DATAch do generatora znaków
      Wynik: 13260 (+584b) - zawsze coś :)
    40.  
      Bug! Ktoś rozdeptał trawę... :) HotFix dopiero jutro :)

      • 41:
         
        CommentAuthorlarek
      • CommentTime1 Mar 2012 22:03
       

      mgr_inz_rafal:

      (...) wraz z prostą funkcją rysującą.

      A można ją zobaczyć? Jeśli to nie tajemnica :)
    42.  
      Oto ona:

      8009 READ I
      8010 IF I = -Q2 THEN 8121
      8020 IF I = -Q1 THEN LINE=LINE+Q1:GOTO 8009
      8030 IF I < -Q2 THEN COLOR ABS(I+10):GOTO 8009
      8040 PLOT I, LINE: READ I:DRAWTO I, LINE
      8050 GOTO 8009


      8121 - wyskok po narysowaniu psa
      Q2 = 2
      Q1 = 1
      • 43:
         
        CommentAuthorlarek
      • CommentTime2 Mar 2012 11:03 zmieniony
       
      Dzięki. Faktycznie prosta procedurka, ale wcale to nie oznacza, że nie można jej choć trochę przyspieszyć. Moja wersja:
      Q0=0
      Q1=1
      QM1=-1
      QM2=-2


      8009 READ I: IF I<Q0 THEN 8020
      8010 PLOT I,LINE:READ I:DRAWTO I,LINE:GOTO 8009
      8020 IF I=QM1 THEN LINE=LINE+Q1:GOTO 8009
      8030 IF I<QM2 THEN COLOR 13+I:GOTO 8009
      8040 GOTO 8121


      Podprogram najwięcej robi PLOT-ów i DRAWTO-ów, więc niepotrzebnie, żeby każda rysowana kropka i linia poprzedzona była sprawdzaniem aż 3 warunków. Na moje oko wystarczy sprawdzenie jednego: czy pobrana dana jest "instrukcją specjalną"? Jeśli nie, to na 100% jest to współrzędna. I na takim założeniu oparłem mój program.
      Pozwoliłem sobie też zadeklarować liczby -1 i -2 jako zmienne, a nie zmieniać znaku liczb 1 i 2 w trakcie wykonywanie programu. Nie wiem, jaki jest zysk czasowy na takiej operacji, ale wydaje mi się, że coś tam zyskujemy. Ewentualnie, jeśli liczby -1 i -2 są rzadko używane w programie, to nawet można jest zostawić w postaci stałych i nie bawić się w zmienne.
      ABS() jest moim zdaniem zbyteczne i pewnie też minimalnie opóźnia program (choć zmiany koloru nie są chyba częste). Wymyśliłem, że wystarczy tylko dodawanie 13+I. Wybór koloru następowałby wg schematu:
      -10 = COLOR 3
      -11 = COLOR 2
      -12 = COLOR 1
      -13 = COLOR 0

      I ostatnia sprawa. Warunku końca rysowania nie trzeba sprawdzać, bo jeśli pobrana dana nie jest współrzędną, nie wynosi -1 i nie jest mniejsze od -2 to znaczy, że... kończymy rysowanie :)


      Gdyby i to było jeszcze trochę za wolne, to można pokusić się dać ten podprogram na początku gry. Basic szukając numeru linii, do której ma skoczyć, przeszukuje pamięć od początku. Jak procedura dużo "skacze", to warto dać ją na początek.

      Trzeba wziąć poprawkę na to, że to tylko moje teoretyczne rozważania i nie wiem, jak to się sprawdzi w praktyce. Ale chyba spróbować warto.
    44.  

      Dracon:

      zlogosowac grafike (zamienic na tryb znakowy)

      Możesz rozwinąć myśl? Na czym ta operacja polega?

      larek:

      Moja wersja
      Po kolejnej porcji zmian sytuacja wygląda nasępująco (czas mierzę w jednostkach wykorzystywanych przez TIME z TBXL):

      1. Dodanie QM1 i QM2 przyspieszyło tworzenie rysunku o 8 jednostek, choć pewnie wzrosło trochę użycie pamięci. Muszę jeszcze w pozostałych miejscach zdefiniować zmienne ujemne, bo takich miejsc typu -Q1 i -Q10 jest w kodzie więcej

      2. Zmiana kolejności IFów wg Twojego pomysłu zaoszczędziła 19 jednostek. Kodowanie kolorów zostawiłem po mojemu, bo nie chce mi się już zmieniać generatorów. Zrezygnowałem jednak z ABS() na korzyść zapisu: COLOR -I+10

      3. Kolejne 7 jednostek udało mi się ugrać modyfikując procedurkę jeszcze bardziej:
      8009 READ I: IF I >= Q0 THEN PLOT I,LINE:READ I:DRAWTO I,LINE:GOTO 8009
      8010 IF I<MQ2 THEN COLOR -I+10:GOTO 8009
      8020 IF I=MQ1 THEN LINE=LINE+Q1:GOTO 8009
      8040 GOTO 8121

      - rysowanie w jednej linijce (8009)
      - najpierw sprawdzam czy zmiana koloru, a dopiero później, czy nowa linia. Po optymalizacji pamięci pokuszę się o jakiegoś ładniejszego psa, więc i zmiany koloru będą następowały częściej

      larek:

      Gdyby i to było jeszcze trochę za wolne, to można pokusić się dać ten podprogram na początku gry. Basic szukając numeru linii, do której ma skoczyć, przeszukuje pamięć od początku.

      Właśnie z tego powodu na początek przeniosłem logikę gry, żeby pies trochę szybciej śmigał. O ile procedurkę rysującą jeszcze bym tam gdzieś wcisnął to zachodzi pytanie, czy razem z nią trzeba przesuwać DATA? Czy obecność danych niżej w kodzie wpływa jakoś na prędkość?

      Trzeba wziąć poprawkę na to, że to tylko moje teoretyczne rozważania i nie wiem, jak to się sprawdzi w praktyce. Ale chyba spróbować warto.

      Sprawdziłem, warto było :) Jak masz więcej takich teoretycznych rozważań to dawaj, chętnie sprawdzę :)
    45.  
      Dobra, pytanko:
      Właśnie kończę testy na Real Atari i jak wszystko pójdzie dobrze, to chciałbym opublikować gierkę... Jak to zrobić?

      Do dyspozycji mam listing w notepadzie, ale widzę, że w katalogu gier są w zasadzie tylko pliki .atr, .xex albo .cas. Jak takowe wygenerować?
      • 46:
         
        CommentAuthorjhusak
      • CommentTime2 Mar 2012 23:03
       
      Bierzesz atr dosa np Dos II/D 6.4 by Stefan Dorndorf
      Czytasz faq o samouruchamiających się programach w basicu

      Jak już masz uruchamiaczkę, to w dosie piszesz: job uruchamiaczka
      i po restarcie się uruchomi twoja gra.

      Nie zapomnij o readme.txt, gdzie umieścisz garść informacji o sobie/grze oraz licencję :)
      • 47: CommentAuthorBluki
      • CommentTime3 Mar 2012 00:03 zmieniony
       
      Możesz też zapisać grę na tej "dyskietce" w załączniku (jest to plik ATR). Grę z poziomu PC przenosisz np. programem „makeATR”. Uwaga. Twoja gra na dysku ATR musi mieć rozszerzenie BAS.
    48.  
      OK, coś się chyba udało :)
      Atari800Win niby łyka i można pograć :)
      • 49:
         
        CommentAuthorDracon
      • CommentTime3 Mar 2012 01:03 zmieniony
       

      Dracon:

      zlogosowac grafike (zamienic na tryb znakowy)

      Możesz rozwinąć myśl? Na czym ta operacja polega?

      W skrocie to zamiana obrazka, ktory zwykle ma 6-7 kB na odpowiednik w trybie znakowym, zajmujacy zwykle o wiele mniej w pamieci (nawet 50%!). Dodatkowo, w obrazku takim jak Twoj, bedzie jeszcze mozliwosc dodawania 5. koloru (znaki w inwersie) !
      :)
    50.  

      Dracon:

      W skrocie to zamiana obrazka, ktory zwykle ma 6-7 kB na odpowiednik w trybie znakowym
      Możesz wskazać jakiś przykład programu, który to wykorzystuje? Czy chodzi o to, aby zmienić na zasadzie semigrafiki? Tzn. wygenerować takie znaki, żeby ustawione obok siebie przypominały obrazek i uruchamiać w GR.2?

    Od 51 do 100 z 178

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