atarionline.pl Scramble in Action! - 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.

    • 1: CommentAuthorilmenit
    • CommentTime26 May 2020 zmieniony
     
    @zbyti:
    Takie już ma wymagania ANTIC. Z DeRe Atari Chapter 3:
    A full character set has 128 characters in it, each with a normal and an inverse video incarnation. Such a character set needs 1024 bytes of space and must start on a 1K boundary. Character sets for BASIC modes 1 and 2 have only 64 distinct characters, and so require only 512 bytes and must start on a 1/2K boundary.

    CHBAS to shadow. W którym momencie go ustawiasz?
    • 2: CommentAuthorzbyti
    • CommentTime26 May 2020 zmieniony
     
    @ilmenit planowałem przeczytać tą książkę jak już zrobię tę "prostą" grę bo wtedy lepiej zrozumiem treść mając jakąś praktykę za sobą ;)

    Dzięki za wskazanie właściwego rozdziału i ustępu ale wciąż mnie to trochę dziwi ;)

    CHBAS przestawiam w VBLANK.

    ;----------------------------------------------------------
    ; VBLANK PROCEDURE CALLED ONCE PER FRAME
    ;----------------------------------------------------------

    PROC VBLANKD=*()
    [PHAXY]
    IF HSCROLI=$B THEN
    IF LMS=LOOPEND THEN
    DRAWLINE() RESETVARS()
    ELSE
    LMS==+1 SCREENI==+1
    FI

    BTMP1==+1
    IF BTMP1=1 THEN CHBAS=$60 FI
    IF BTMP1=2 THEN CHBAS=$64 FI
    IF BTMP1=3 THEN CHBAS=$68 FI
    IF BTMP1=4 THEN CHBAS=$6B FI
    IF BTMP1=5 THEN CHBAS=$68 FI
    IF BTMP1=6 THEN CHBAS=$64 FI
    IF BTMP1=7 THEN CHBAS=$60 BTMP1=0 FI

    HSCROLI=$F
    FI
    HSCROL=HSCROLI HSCROLI==-1
    [PLAXY]
    [JMP OLDVBL]
    • 3: CommentAuthorilmenit
    • CommentTime26 May 2020
     
    kilka pomysłów:
    1. wstaw breakpoint i zobacz, czy się chbas ustawia na $6b
    2. wstaw drugi breakpoint i zobacz, czy się chbase ustawia na $6b
    3. wstaw breakpoint na początek tej procki (ora znajlepiej na koniec) i zobacz w jakiej kolejności następują zmiany powyższych rejestrów w stosunku do tej procedury. Może np. przekroczyłeś czas na przerwanie?
    • 4: CommentAuthorantrykot
    • CommentTime26 May 2020 zmieniony
     
    $6b się nie dzieli przez 4, $6c powinno być
    • 5: CommentAuthorzbyti
    • CommentTime26 May 2020 zmieniony
     
    @antrykot właśnie też znalazłem tego babola, shame on me! :D
    • 6: CommentAuthorilmenit
    • CommentTime26 May 2020
     
    @antrykot - rzeczywiście, to jest to.
    • 7: CommentAuthorantrykot
    • CommentTime26 May 2020
     
    Dodam, że w haskellu to kompilator sam takie błędy znajduje.
    • 8: CommentAuthorilmenit
    • CommentTime26 May 2020
     
    @antrykot - podeślij o tym jakieś info
    • 9: CommentAuthorzbyti
    • CommentTime26 May 2020 zmieniony
     
    OK. To animacja "terenu" gotowa.

    Jestem skłonny pogodzić się z tym, że obiekty animują się synchronicznie gdy robotę robi mi zmiana CHBAS.

    Teraz tylko przepiszę jeszcze kod testowy na jakiś ludzki.

    Sorki za zawracanie głowy z tym $6B ale spałem dziś tylko 3h ;)

    Jeszcze muszę jakoś sprytnie wykorzystać to (3/4 1K)*4 wolnego bo te zestawy mają po $100. Niestety w Action! słabo steruje się kompilatorem pod tym względem.

    Michał, miałeś uwagi co do szybkości animacji, sprawdź proszę XEX i wydaj swoją opinię bo mi się podoba dokładnie tak jak jest teraz.
    • 10: CommentAuthorantrykot
    • CommentTime26 May 2020
     
    @ilmenit, muszę najpierw wymyślić jak to zrobić...
    • 11:
       
      CommentAuthoranonymus
    • CommentTime26 May 2020 zmieniony
     
    Tylko błagam o jedno, żeby radary nie strzelały:D
    • 12: CommentAuthorzbyti
    • CommentTime26 May 2020 zmieniony
     
    @anonymus w takim razie mają źle naprowadzać do lądowania? Stary... W tej grze nie masz prawa przeżyć jednej iteracji generatora terenu! ;D

    Jeżeli radary nie będą strzelać to tylko dlatego, że nie chciało mi się oprogramować do tego logiki ;)
    • 13: CommentAuthorzbyti
    • CommentTime26 May 2020 zmieniony
     
    Animacja uproszczona do 3 klatek z nowym timingiem.

    Procedura wyniesiona z VBLANK do głównej pętli. Skoro zmiany są na rejestrze cieniu CHBAS to czas w przerwaniu lepiej zaoszczędzić na muzykę itd.

    COARSEI==+1
    IF COARSEI=6 THEN CHBAS==+4 FI
    IF COARSEI=8 THEN CHBAS==+4 FI
    IF COARSEI=14 THEN CHBAS==-4 FI
    IF COARSEI=16 THEN CHBAS==-4 COARSEI=0 FI

    Więcej na ten element nie ma sensu teraz poświęcać czasu.
  1.  
    @zbyti

    good job!

    wersja 15 bardzo ładnie na żywym sprzęcie wygląda ta animacja czaszy radarów - taka nie za szybka i nie za wolna.

    ->link<-
    • 15: CommentAuthorzbyti
    • CommentTime27 May 2020 zmieniony
     
    @mkolodziejski dzięki, chyba warto wrócić do 4 klatek, 3 klatki wyglądają sztucznie.

    Niesamowicie szarpie ten film, grabber + YT.
    • 16: CommentAuthorMADRAFi
    • CommentTime27 May 2020
     
    Mysle ze 3 klatki daja rade. Wyglada ok.
    Szczegolnie ze kazda klatka to + 1kb do nowego fontu :)
    • 17: CommentAuthorzbyti
    • CommentTime27 May 2020 zmieniony
     
    Na razie pamięci mam "w opór", do tego w wolne 3/4 kilo na zestaw mogę "wsadzić" inne dane, więc się nie zmarnuje.

    Zmniejszyłem szanse rysowania rakiety na ekranie o połowę bo jak na mój gust było za gęsto, skutkuje to tym, że radar jednak zostanie "działem" by nie było nudno na planszy ;)

    Dziś porobię w Action! coś innego co by nie patrzeć za długo w jeden kod ;)
    • 18: CommentAuthorxxl
    • CommentTime27 May 2020
     
    nie wiem czy to dobrze zrozumialem: animacja na fontach jednego znaku ze zmiana calego zestawu znakow?

    1. jeden zestaw znakow. co ramke zmieniac 8 bajtow definicji znaku a nie caly zestaw. ide o zaklad ze procka zmieniajace te bajtow bedzie krotsza niz ta ktora podmienia zestawy. juz nie mowie o ilosci danych.

    jesli dojdzie wiecej znakow do animacji to na tej samej zasadzie bedzie mozna zrobic rozna szybkosc animacji poszczegolnych znakow.
    • 19:
       
      CommentAuthorIRATA4
    • CommentTime27 May 2020
     
    ... o rany,jakbym miał zmieniać wszystkie znaki przy animacji twarzy postaci w mojej grze,to chyba bym zwariował.
    są standardowo dwa zestawy,więc w drugim znak może być inny i można zrobić podmiankę ...
    • 20: CommentAuthorxxl
    • CommentTime27 May 2020 zmieniony
     
    oczywiscie rozumiesz roznice miedzy: "jeden znak" a "wszystkie znaki"?
    • 21: CommentAuthorzbyti
    • CommentTime27 May 2020 zmieniony
     
    @xxl za pierwszym razem ->link<- zrobiłem tak jak opisujesz, że w zestawie znaków podmieniałem tylko ten który chciałem animować ale MoveBlock w Action! generował zdecydowanie zauważalny narzut.

    ; Action! RUNTIME: MoveBlock=*(CARD d, s, l)

    0E9D: 85 A0 STA $A0 ;TSLNUM
    0E9F: 86 A1 STX $A1 ;TSLNUM+1
    0EA1: 84 A2 STY $A2 ;MVLNG
    0EA3: A0 00 LDY #$00
    0EA5: A5 A4 LDA $A4 ;ECSIZE
    0EA7: D0 04 BNE $0EAD
    0EA9: A5 A5 LDA $A5 ;ECSIZE+1
    0EAB: F0 18 BEQ $0EC5
    0EAD: B1 A2 LDA ($A2),Y ;MVLNG
    0EAF: 91 A0 STA ($A0),Y ;TSLNUM
    0EB1: C8 INY
    0EB2: D0 04 BNE $0EB8
    0EB4: E6 A1 INC $A1 ;TSLNUM+1
    0EB6: E6 A3 INC $A3 ;MVLNG+1
    0EB8: C6 A4 DEC $A4 ;ECSIZE
    0EBA: A5 A4 LDA $A4 ;ECSIZE
    0EBC: C9 FF CMP #$FF
    0EBE: D0 E5 BNE $0EA5
    0EC0: C6 A5 DEC $A5 ;ECSIZE+1
    0EC2: 38 SEC
    0EC3: B0 E0 BCS $0EA5
    0EC5: 60 RTS

    Aktualnie te parę "IF-ów" nie kosztuje CPU zbyt wiele a mam (jeżeli zechcę) animację wszystkich znaków.

    Czy przełączenie CHBAS jest "kosztowne" i pożera mi VBLANK? Czy to jednak tylko zmiana wartości bez narzutu na CPU bo ANTIC podczas rysowania wiersza dopiero zaciąga dane?

    W tej chwili animują się tą metodą 4 klatki czaszy radaru i "światełka" na jednej z rakiet. Zmiana całego zestawu jest najmniej kłopotliwa a załatwia kilka spraw.

    Kod gry ma w tej chwili niecały 1KB, więc dostępną pamięcią się jeszcze nie martwię.

    COARSEI==+1
    IF COARSEI=8 THEN CHBAS==+4
    ELSEIF COARSEI=9 THEN CHBAS==+4
    ELSEIF COARSEI=10 THEN CHBAS==+4
    ELSEIF COARSEI=18 THEN CHBAS==-4
    ELSEIF COARSEI=19 THEN CHBAS==-4
    ELSEIF COARSEI=20 THEN CHBAS==-4
    COARSEI=0 FI

    ;----------------------------------------------------------

    111D: E6 61 INC $61 ;FKDEF+1
    111F: A5 61 LDA $61 ;FKDEF+1
    1121: 49 08 EOR #$08
    1123: F0 03 BEQ $1128
    1125: 4C 34 11 JMP $1134
    1128: 18 CLC
    1129: AD F4 02 LDA $02F4 ;CHBAS
    112C: 69 04 ADC #$04
    112E: 8D F4 02 STA $02F4 ;CHBAS
    1131: 4C 9E 11 JMP $119E
    1134: A5 61 LDA $61 ;FKDEF+1
    1136: 49 09 EOR #$09
    1138: F0 03 BEQ $113D
    113A: 4C 49 11 JMP $1149
    113D: 18 CLC
    113E: AD F4 02 LDA $02F4 ;CHBAS
    1141: 69 04 ADC #$04
    1143: 8D F4 02 STA $02F4 ;CHBAS
    1146: 4C 9E 11 JMP $119E
    1149: A5 61 LDA $61 ;FKDEF+1
    114B: 49 0A EOR #$0A
    114D: F0 03 BEQ $1152
    114F: 4C 5E 11 JMP $115E
    1152: 18 CLC
    1153: AD F4 02 LDA $02F4 ;CHBAS
    1156: 69 04 ADC #$04
    1158: 8D F4 02 STA $02F4 ;CHBAS
    115B: 4C 9E 11 JMP $119E
    115E: A5 61 LDA $61 ;FKDEF+1
    1160: 49 12 EOR #$12
    1162: F0 03 BEQ $1167
    1164: 4C 73 11 JMP $1173
    1167: 38 SEC
    1168: AD F4 02 LDA $02F4 ;CHBAS
    116B: E9 04 SBC #$04
    116D: 8D F4 02 STA $02F4 ;CHBAS
    1170: 4C 9E 11 JMP $119E
    1173: A5 61 LDA $61 ;FKDEF+1
    1175: 49 13 EOR #$13
    1177: F0 03 BEQ $117C
    1179: 4C 88 11 JMP $1188
    117C: 38 SEC
    117D: AD F4 02 LDA $02F4 ;CHBAS
    1180: E9 04 SBC #$04
    1182: 8D F4 02 STA $02F4 ;CHBAS
    1185: 4C 9E 11 JMP $119E
    1188: A5 61 LDA $61 ;FKDEF+1
    118A: 49 14 EOR #$14
    118C: F0 03 BEQ $1191
    118E: 4C 9E 11 JMP $119E
    1191: 38 SEC
    1192: AD F4 02 LDA $02F4 ;CHBAS
    1195: E9 04 SBC #$04
    1197: 8D F4 02 STA $02F4 ;CHBAS
    119A: A0 00 LDY #$00
    119C: 84 61 STY $61 ;FKDEF+1

    Nie zapominajmy, że ja piszę w Action! a nie w ASM.

    Tak czy inaczej, zastanowię się jeszcze nad problemem.
    • 22: CommentAuthorMq
    • CommentTime27 May 2020
     
    Jak trzymasz kilka zestawów znaków w pamięci i tylko przełączasz zestaw, żeby robić animację, to jest faktycznie najmniej kosztowne czasowo, bo przełączenie całego zestawu bez żadnego relokowania danych to tylko jedno "Poke".
    Wady:
    1) dużo pamięci zajmują całe zestawy, zwłaszcza jak nagle musisz dołożyć np. 1,2,3 klatki do animacji
    2) wszystkie animowane elementy musisz mieć o tej samej ilości klatek animacji, lub wielokrotność jakiejś najmniejszej wspólnej ilości i je powtarzać
    3) wszystkie elementy gry muszą się animować synchronicznie razem, co chyba nie będzie ładnie wyglądało - ale to już zależy jakie i ile będzie tych elementów

    W moim Kolesiu właśnie siedzę nad animacjami tła, na samym początku rozważałem taką samą metodę jak Twoja, ale szybko z niej zrezygnowałem. Zamiast tego animuję pojedyncze znaki.
    Zalety:
    1) każdy znak może mieć inną dowolną ilość klatek animacji
    2) każdy znak można animować z inną prędkością (stosując odrębne liczniki ramek/czasu itp)
    3) start animacji każdego znaku może być w innym momencie
    4) można wiele różnych rzeczy animować na tych samych znakach (np. u Ciebie możesz animować radar, a jak przelecisz cały ekran, to na następnym ekranie już możesz na tych samych znakach animować coś innego)

    To takie tam moje obserwacje, bo niemal przed chwilą przechodziłem podobną drogę jak Ty:-)
    • 23: CommentAuthorzbyti
    • CommentTime27 May 2020 zmieniony
     
    @Mq dzięki za podzielenie się swoimi doświadczeniami :]

    Sądzę, że skoro to ma być strzelanka w której "sporo się dzieje" a nie coś bardziej statycznego co można pooglądać to zostawię sobie CPU na animowanie ruchu rakiet, kolizje, ruszanie duszkami itd.

    Co prawda to wszystko dzieje się co 4 ramkę, ale jak chcę się zmieścić w ramce to nie może mi co 4-tą "chrupać" ;)

    Akcja gry nie powinna zostawić wiele czasu na kontemplowanie powtarzalności animacji, gracz powinien być skupiony na tym by "przeżyć".

    Raczej zostanę przy metodzie zmiany CHBAS chociaż w każdym innym przypadku wybrałbym podmianę danych znaku i napisał jakiś własny MoveBlock w ASM.
  2.  
    @zbyti

    poprzepinałem okablowanie i sterowniki - teraz grabber leci prosto z OSXa, a nie przez wirtualkę z W10, jest 50 fps, przynajmniej pozornie.

    wersja 16: ->link<-
    • 25: CommentAuthorzbyti
    • CommentTime27 May 2020
     
    @mkolodziejski dzięki za wrzutkę :]

    Po rastrze widać, że jest "zbyt biały" jak na coś co zapala się co 4 ramkę ;)
    • 26: CommentAuthorMq
    • CommentTime27 May 2020
     
    @zbyti, oczywiście spoko, rób tymi podmianami zestawów znaków, nie ma w tym nic złego.
    Natomiast zwrócę Ci uwagę na coś, co sam cytowałeś, żebyś to rozważał w trakcie prac:-) Jak napisano, cała ramka ma 20tys cykli, a więc jakieś 4,5tys instrukcji. Ty robisz wszystko jak rozumiem co 4 ramki, więc masz miejsce na jakieś 18tys. instrukcji. Szczerze mówiąc mógłbyś dać coś do roboty temu prockowi, bo Ci zaśnie jak chcesz tylko to co napisałeś robić:
    "sporo się dzieje" a nie coś bardziej statycznego co można pooglądać to zostawię sobie CPU na animowanie ruchu rakiet, kolizje, ruszanie duszkami itd.

    Zobacz załącznik, masz swoje 4 ramki. Idle = nudzę się:-)
    • 27: CommentAuthorzbyti
    • CommentTime27 May 2020 zmieniony
     
    @Mq dzięki za uwagi :]

    Na ten moment wszystko robię w trakcie "zgrubnego" scroll'a ale jak dojdą kolizje, duszki, dźwięki, lot pionowy rakiet to już będę to ogarniał co ramkę.

    Chodziło mi, że sporo to się będzie dziać a teraz oszczędzam CPU jak mogę chociaż nic wielkiego się nie dzieje :]
    • 28: CommentAuthorMq
    • CommentTime28 May 2020
     
    Spoko.
    Słuchaj, z tego co zauważyłem (oczywiście sam to sobie sprawdzisz doświadczalnie), to w VBI co każdą ramkę warto robić takie rzeczy jak scroll, i trzeba robić ustawienie adresu pierwszego DLI. Te rzeczy trzeba zrobić na początku przerwania, żeby na pewno się wykonały zanim Antic zacznie coś wyświetlać. Co ramkę też gramy muzykę jeśli ma lecieć w tle i żeby zawsze grała równo, to warto ją też grać zaraz na początku VBI, bo jak ją grasz później, a z racji różnych warunków po drodze VBI trwa minimalnie choćby inną ilość czasu, to muzyka gra nierówno i sprawia wrażenie kulawej.
    Natomiast całą resztę rzeczy możesz robić co kilka ramek ze spokojem. Nikt nie porusza joystickiem 50 razy na sekundę, żebyś musiał co chwilę to sprawdzać ani nie będziesz wykonywał 50 ruchów gracza na sekundę i tyleż samo wszelkich kolizji, zmian, animacji itd. Jak zrobisz to 10 razy na sekundę, czyli przykładowo co 5 ramek, to i tak będzie wszystko dynamiczne.
    Dlatego skoro już masz taki układ że robisz coś tam co 4 ramki, to zrób sobie w VBI licznik do 4, wstaw 4 if-y sprawdzające ten licznik i wykonuj sobie 4 różne bloki funkcji rozłożone na te 4 ramki.
    Ja nie wiem czy to jest najsłuszniejsza droga, ale sam sobie tak wymyśliłem i działa to mi bardzo dobrze, a miejsca w ramkach mam jeszcze pełno.
    Z tego co widzę po swoich eksperymentach, to dynamiki i płynności nie traci się na tym że komputer jest za słaby i się nie wyrabia, bo on tak na prawdę jeszcze całkiem sporo może pociągnąć. Problemy pojawiają się jak się robi różne rzeczy niesynchronicznie w niewłaściwych momentach. Np. jak w głównej pętli sobie ustawiasz jakąś zmienną od scrolla, i ta zmienna ustawia się co ramkę, ale zawsze w innym momencie i później nawet jeśli scroll robisz w VBI równo od początku, to ta zmienna się ustawi czasem przed VBI, a czasem po i masz szarpanie. Tak samo z animacjami PMG, z animacjami na znakach, czy z muzyką, co już trochę wyżej opisałem.
    • 29: CommentAuthorzbyti
    • CommentTime28 May 2020
     
    @Mq Bardzo ciekawe uwagi praktyczne, do niezwłocznego zastosowania - dziękuję! :]
    • 30:
       
      CommentAuthorshanti77
    • CommentTime28 May 2020
     
    Moim zdaniem jednak warto sprawdzać joystick co ramkę (w szybkiej rozgrywce), może nikt nie wykonuje 50 różnych ruchów na sekundę, ale tak naprawdę obsługa nie zabiera tak dużo czasu. Odczytując wskazanie manipulatora co 5 ramek wprowadzamy opóźnienie 1/10s , czyli mamy mniejszy czas reakcji, poza tym jeśli zmieniamy pozycję naszego bohatera co kilka ramek, to zależnie od jego prędkości, musimy przesuwać go zamiast o 1 pixel o kilka punktów, co spowoduje mniej płynny ruch.
    • 31: CommentAuthorMq
    • CommentTime28 May 2020
     
    Jeśli zmieniamy pozycję gracza co np. 3 ramki, to również co tyle musimy robić obsługę sprawdzania poszczególnych kierunków joya i go interpretować. Jeśli wtedy jednak będziemy robić odczyt joya co ramkę, to przecież odczyt z ramki 2 i 3 nadpisze odczyty poprzednie.
    • 32: CommentAuthorxxl
    • CommentTime28 May 2020 zmieniony
     
    BHP i podpowiedz:

    1. odczyt z rejestru sprzetowego PIA przechowuj i do niego sie odwoluj - dwa kolejne odczyty z PIA (np. porownania) nawet jesli nie zmieniasz pozycji joya moga dac rozne wyniki (drgania)

    2. podpowiedz: dane z joya zbieraj w jednostkach w jakich sa wykorzstywane (jesli AI bedzie ruszalo playerem lub jesli bedziesz robil np. replay oprocz wychylenia zapisuj czas - w tych samych jednostkach co poprzednio - wychylenia - pozwoli to rowniez wykryc sytuacje gdy np. skaczesz a skok trwa krocej niz reakcja czlowieka, efekty niestety widoczne w wielu grach robisz jeden skok ale player wykonuje ich np. 3 albo np. skok powinien wkonac sie dopiero po przekroczeniu czasu wychylenia - przypadkowe ruchy) - ten czas oczywiscie zalezy od implementacji bo czasem lepiej zbierac co ramke + znacznik czasu
    • 33:
       
      CommentAuthorshanti77
    • CommentTime28 May 2020
     
    @Mq ale dlaczego nasz pojazd ma być animowany co 3 ramki, ekran i tak jest przesuwany co ramkę, więc i rakieta też może być animowana co ramkę. Będzie płynniejszy ruch. Kolizje można sprawdzać co kilka ramek.
    • 34: CommentAuthorzbyti
    • CommentTime28 May 2020 zmieniony
     
    THX panowie za powyższe wskazówki :]

    Dziś nie programuję, dziś oglądam tę serię:



    Pierwszy odciek i widoczny powyżej drugi oraz trzeci to jak znalazł dla początkujących programistów 6502.
    • 35: CommentAuthorMq
    • CommentTime28 May 2020 zmieniony
     
    @shanti: to prawda, w sumie to wszystko zależy o ile się ma przesuwać postać w trakcie ruchu, jak szybko ma się przesuwać i ile klatek animacji ma ta postać mieć.

    Patrzę trochę przez pryzmat gry, którą akurat robię, tylko że u mnie jest postać człekokształtna, więc animacja chodzenia ma dużo klatek. Całość musi być zsynchronizowana odpowiednio, bo jak ludek robi krok, to musi przemieścić się w tym czasie o określoną ilość pikseli, żeby nogi nie przesuwały się wzdłuż podłoża, tylko przekraczały kolejną odległość proporcjonalną do długości kroku. Czyli animacja musi się synchronizować z przemieszczaniem postaci.
    W takim wypadku synchronizuję sobie animację z przemieszczeniem, a później prędkość reguluję właśnie tym, że ruch wykonuję co określoną ilość ramek i z tą samą częstotliwością sprawdzam też joya.
    Oczywiście nie można przesadzić z pomijaniem ramek, bo będzie tak jak pisze shanti opóźnienie, które powyżej jakiejś wartości zacznie być zauważalne. Rząd wielkości co 1,2,3,4 ramki jest ok, powyżej nie wiem do ilu można tak rozszerzać, ale chyba nie ma sensu.

    Inaczej jest w grze, w której latamy pojazdem, bo on może być animowany odrębnie, a przemieszczany odrębnie i nie musi być między tymi dwoma ruchami, żadnej korelacji, więc faktycznie można przesunięcie robić co ramkę z dokładnością do piksela i uzyskać w ten sposób większą płynność ruchu. W takim wypadku oczywiście odczyt joya należy robić również co ramkę.

    Uwagi xxl-a słuszne: ja np. robię tak, że odczytuję stan joya raz na trzy ramki (pasuje mi akurat tyle do synchronizacji pozostałych rzeczy) i ten odczyt zapisuję do zmiennej. Następnie wszystkie operacje, interpretacje, animacje, ruchy, kolizje przeprowadzam w oparciu o stan tej zmiennej, a kolejny odczyt stanu joya odbywa się znowu dopiero za kolejne trzy ramki. W ten sposób wszystkie procedury operują zawsze na tym samym odczycie joya, nie ma żadnych drgań, ani zmian w trakcie interpretacji itp.
    • 36:
       
      CommentAuthoranonymus
    • CommentTime28 May 2020
     
    Zbyti, będziesz pisał emu NES na Atari?;)
    • 37: CommentAuthorzbyti
    • CommentTime28 May 2020 zmieniony
     
    @anonymus materiały gościa to genialna sprawa! Dzięki nim mając podstawowe pojęcie można lepiej zrozumieć zasadę działania mikrokomputera takiego jak Atari 800.

    A już jego komentarze w kodzie 6502 to obowiązkowa lektura ;)

    olc6502.h ->link<-
    olc6502.cpp ->link<-

    ;-------------------------------

    Znakomite wprowadzenie: Assembly In One Step ->link<-

    Przy nauce nieodzowny wydaje się ->link<-
    • 38: CommentAuthorzbyti
    • CommentTime30 May 2020
     
    @paw

    DRAWROCKET

    lda RANDOM
    ora #1
    and #7
    tay
    iny
    sty SHIPTYPE
    ROCKETBODY
    ldx ROW
    inx
    jsr DRAWROW
    ROCKETHEAD
    lda SHIPTYPE
    ldx ROW
    inx
    inx
    jmp DRAWROW
    dr1
    rts

    Jesteś pewny, że chcesz tak gęsto? Ja ostatnio zwiększyłem zakres z 15 do 31 by rzadziej się losowały rakiety.

    PROC DRAWROCKET=*()
    SHIPTYPE=(RANDOM%1) & 31
    IF SHIPTYPE>7 THEN RET FI
    POKEADDR=SCREENI-$30 ELMPOKE(SHIPTYPE) SHIPTYPE==+1
    POKEADDR=SCREENI-$60 ELMPOKE(SHIPTYPE)
    RET
    • 39: CommentAuthorpaw
    • CommentTime30 May 2020
     
    @zbyti
    Już skorygowałem, jak wspominałem staram być tak blisko originału w action! jak się da. Jeżeli coś zmieniam to albo się pomyliłem albo inaczej nie potrafię.
    A ostatnio pojawiła się też opcja "po co zmieniać skoro działa".