atarionline.pl Mad Pascal i playery cmc/rmt - 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:
         
        CommentAuthorMq
      • CommentTime18 May 2020 16:05
       
      Mam pytanko odnośnie muzyczki, którą chcemy odgrywać załóżmy w grze. Chodzi mi o różnice w playerach CMC i RMT. Mogę zrobić wystarczająco dobrą muzyczkę w jednym z tych dwóch programów, jest mi w zasadzie wszystko jedno w którym z nich będę robił, nie rozmawiam o ich możliwościach i porównaniu samych programów, natomiast interesuje mnie tu porównanie w dwóch innych ważnych dla mnie na tym etapie aspektach (a odpalam z MadPascala):

      1) który player odpalany raz na ramkę w przerwaniu VBL zajmie mniej czasu w tym przerwaniu

      2) czy któryś z playerów może zajmować znacząco mniej pamięci niż drugi (tu w sumie dodatkowo nasuwa mi się pytanie, czy jeśli zrobimy w rmt i w cmc taką samą muzyczkę (tyle samo dźwięków, patternów, tracków), to czy któraś zajmie znacząco mniej miejsca)
      • 2: CommentAuthortebe
      • CommentTime18 May 2020 16:05
       
      Player MPT 2.4
      coded by Fox
      07,19,25,30/07/96
      mads reloc by Tebe 06/03/2016
      original version by Jaskier/Taquart


      player MPT jest najszybszy
      • 3:
         
        CommentAuthorMq
      • CommentTime18 May 2020 18:05
       
      O, no to dzięki za odpowiedź, tyle że... player MPT nie jest ani playerem RMT, ani playerem CMC:-)

      Czyli na pierwszym miejscu stanie MPT, a w takim razie na drugie wrzucimy RMT czy CMC?:-)
      • 4: CommentAuthorMADRAFi
      • CommentTime18 May 2020 18:05 zmieniony
       
      RMT zre dodatkowa pamiec na bufor. Wiec oprocz 2kb na player wciagnie ci (bedzie uzywal) nawet 512 bajtow.

      Wez pod uwage 2 cechy dodatkowe
      RMT pozwala odgrywac w bardzo latwy sposob instrumenty jako efekty dzwiekowe w grze.
      CMC pozwala w sposob bardzo latwy zapauzowac odgrywany modul, przeprowadzic operacje IO i kontynuowac odgrywanie muzyki od tego samego miejsca.
      • 5: CommentAuthorxxl
      • CommentTime18 May 2020 19:05
       
      z tych dwoch CMC jest krotszy.

      jesli mslisz o szybkosci rozwazylbm tez DeltaMusic ->link<-

      co do odgrywania instrumentu jako SFX to jesli zorientowales sie w ograniczeniach tej metody i chcialbys cos wiecej np. jingle, automatyczna alokacje kanalow pod sfx, wyciszanie kanalow bez przerywania muzy itp. to od pewnego czasu pisze sfx engine ktory latwo mozna zintegrowac z CMC i RMT...:

      • 6:
         
        CommentAuthorMq
      • CommentTime18 May 2020 20:05
       
      Hmm...
      Czyli wydaje się, że wszystko będzie miało jakieś tam swoje za i przeciw.
      Ogólnie można powiedzieć, że jeśli o szybkość chodzi, to najlepiej było by się przesiąść na coś innego w ogóle.
      Podałem CMC i RMT jako te dwa, które biorę pod uwagę, bo te dwa dobrze znam i wygodnie mi się w nich pracuje. O ile programowanie mogę realizować w dowolnych językach, i nie robi mi zbytniej różnicy w czym programuję, o tyle przy robieniu muzy mam swoje przyzwyczajenia, a na to musi być odpowiedni moment twórczy i wena, więc muszę wtedy mieć wszystko pod ręką zgodnie ze swoimi przyzwyczajeniami. Dlatego nie zmienię programu na zupełnie inny - testowałem kiedyś MPT i mi nie leży niestety, co do innych softów, to tez każdy ma jakieś tam swoje rzeczy takie, które mi nie pasują (testowałem swego czasu różne trackery).
      Dlatego pozostanę przy którymś z tych dwóch wymienionych -oszczędności pamięci i cykli będę szukał gdzieś indziej.
      Za parę dni wrzucę jakieś zajawki tego nad czym pracuję, łatwiej będzie się odnosić do rzeczy, o które ewentualnie pytam.

      @xxl: a powiedz coś więcej o tym engine do iniekcji sfx. Jak to działa, ile zajmuje miejsca, ile czasu, gdzie się wpina itp.?
      • 7: CommentAuthortebe
      • CommentTime18 May 2020 20:05
       
      masz jakikolwiek player? użyj go i przepisz zapis do rejestrów POKEY-a na zapis do pamięci, otrzymałeś surowe dane dla AUDCTL, AUDF, AUDC

      od teraz masz możliwość odtwarzać twoje SFX w extremalnie szybki sposób
      lda _audctl,y
      sta audctl
      lda _audf,y
      sta audf...
      lda _audc,y
      sta audc...
      • 8: CommentAuthorxxl
      • CommentTime18 May 2020 21:05 zmieniony
       
      @Mq: sfx engine sam kontroluje ktore kanaly beda uzyte (przy inicjacji user wskazuje ktore moze uzywac), defaultowo nie przerwie (ale moze przerwac) sfx jesli zostanie wywolany przed zakonczeniem odtwarzania poprzedniego, moze odtwarzac sciezki (melodie) nie tylko "instrumenty", nie ingeruje w AUDCTL, pozwala wyciszyc kanaly z playera muzyki i dowolne ich kombinacje

      przkladowe sfx oraz dzingle mam powyciagane z roznych starych gier i przekonwertowane - nie ma edytora - wada

      zajmuje smiesznie malo. zabiera do 2 linii skaningowych.
      • 9:
         
        CommentAuthorMq
      • CommentTime18 May 2020 22:05
       
      @tebe: jeśli dobrze rozumiem, to w taki sposób można wziąć sobie jakiekolwiek muzyczki i/lub dźwięki, zrobić z nich tablice z danymi i odtwarzać tak jak podałeś w ekstremalnie szybki sposób. Tylko trzeba by wtedy to jakoś samemu sobie timingować, ale to już nie powinno być problemem. W taki sposób można by zrobić np. dedykowany player do dedykowanej muzyczki w grze. I powinno to wszystko zająć zarówno mniej pamięci jak i mniej czasu. Podoba mi się takie podejście. Muszę jednak trochę zgłębić Pokeya, a jeszcze za to się nie zabrałem. Na razie ogarnąłem dli, vbl, pmg, kolory, scrolling, fonty. Do muzyki dopiero się przymierzam i na razie odpaliłem sobie w tle muzyczkę RMT i zaczęło przycinać, więc stąd od razu rzuciłem pytanie na co się przesiąść. Dzisiaj jednak ogarnąłem trochę optymalizację i już odtwarzam muzyczkę bez problemu. Z muzyką to na razie umiem ją odtworzyć playerem RMT w Mad Pascalu i umiem robić muzykę w CMC i RMT, bo ogólnie znam się na robieniu muzy - nie tylko na Atari, tylko tak ogólnie. Jak dojdę do momentu, że będzie potrzebna dalsza optymalizacja, to spróbuję skorzystać z podsuniętej przez Ciebie koncepcji, a i też w podobny sposób spróbuję ogarnąć efekty dźwiękowe, bo za nie jeszcze się w ogóle nie zabrałem.

      @xxl: brzmi to fajnie, chętnie bym jakiś opis z przykładem tego zobaczył. Niemniej jednak najpierw muszę w ogóle dojść do etapu kiedy zabiorę się za jakiekolwiek sfx-y, spróbuję je jakoś tam wygenerować, a później będę kombinował jaką metodę wybrać docelowo.

      Dzięki za odpowiedzi, trochę mi rozjaśniły i naprowadziły na kierunkowanie mózgownicy w dalsze eksperymenty.
      • 10: CommentAuthorxxl
      • CommentTime18 May 2020 23:05
       
      I powinno to wszystko zająć zarówno mniej pamięci jak i mniej czasu.


      mniej czasu i wiecej pamieci. ale takie dane dobrze sie kompresuja...
      • 11:
         
        CommentAuthorMq
      • CommentTime19 May 2020 10:05
       
      No tak w tym sensie, że muzyczka faktycznie zajmie więcej pamięci, ale za to player już nie zajmie jej wcale:-) Niemniej jednak wydaje się, że na początek o wiele łatwiej jest skorzystać z któregoś gotowego playera dostępnego w Mad Pascalu. Zaczynam od tego, optymalizuję na razie inne miejsca programu, a jak mi przestanie wystarczać miejsca w ramkach, to będę kombinował z tym dalej.
      • 12: CommentAuthortebe
      • CommentTime19 May 2020 11:05
       
      playery w MP działają też niezależnie od PAL/NTSC, więc wystarczy tylko raz na ramkę je wywoływać i będzie OK
      • 13:
         
        CommentAuthorMq
      • CommentTime19 May 2020 18:05
       
      Przypadkiem to zauważyłem:-) Zajebiste:-)
      Odpaliłem swój projekt, leciała sobie muzyczka w tle i postanowiłem zająć się czymś innym. Przyszło mi do głowy, że sprawdzę, czy mi ta moja produkcja zadziała na NTSC, bo wcześniej tego nie sprawdzałem. Co prawda wszystko się wywaliło graficznie i zaczęło migać fontami i kolorami: słowem nie wyrabiają się zapewne procedury w DLI, bo w NTSC mają mniej czasu, ale to sobie poprawię. Natomiast wielkie było moje zaskoczenie, że muzyczka grała identycznie mimo zmiany z PAL na NTSC. Dzięki tebe, za te wszystkie mega dopracowane narzędzia i biblioteki:-)
      • 14: CommentAuthorMADRAFi
      • CommentTime19 May 2020 23:05 zmieniony
       
      Meczylem Tebego o to by nie musiec tego samemu pisac w swoich programach. I teraz to jest juz wbudowane :)
      • 15:
         
        CommentAuthorjhusak
      • CommentTime20 May 2020 09:05
       
      Tebe, a jak to jest zrobione? (nie to, że jestem leniwy, ale chętnie pewnie wszyscy usłyszą/przeczytają)
      • 16: CommentAuthorilmenit
      • CommentTime20 May 2020 09:05
       
      wewnętrzny licznik i powrót z każdego szóstego zawołania na NTSC?
      • 17: CommentAuthortebe
      • CommentTime20 May 2020 10:05 zmieniony
       
      _
      asl ntsc ; =0 PAL, =4 NTSC
      bcc skp

      lda #%00000100
      sta ntsc

      bne quit
      skp
      jsr play
      quit


      inicjalizacja zmiennej NTSC (gdy PAL = 0, gdy NTSC = 4)
      _
      lda #0
      ldx SYSTEM.TVSystem
      cpx #15
      sne
      lda #4

      sta ntsc
      • 18:
         
        CommentAuthorjhusak
      • CommentTime20 May 2020 10:05 zmieniony
       
      A, czyli najprościej.
      Bo ja uchem wyobraźni słyszę już te zniekształcenia i przedłużenia (a nie gubienia, jak napisałem) nutek jednoramkowych (perkusja)... Nie to, że krytykuje (bo nie) - ale gdzieś z tyłu głowy mam taki układ DLI, że wykonujemy 5 razy w ciągu 6 ramek, ale równomiernie.
      Zgadzam się, że normalnie tego nie słychać :)

      Tak się patrzę w te kilka rozkazów - niezła optymalizacja :)
      • 19:
         
        CommentAuthorMq
      • CommentTime20 May 2020 18:05
       
      Ja specem od optymalizacji nie jestem, bo tez nie jestem specem od assemblera. Ale ostatnio sobie napisałem w Mad Pascalu parę rzeczy, które wrzuciłem do VBL, no i przy kompilacji wyskakuje wtedy porada, żeby zrobić blok procedury VBL w ASM zamiast Pascala, no to sobie myślę czemu nie, w sumie tam jakieś Poke z dwoma if-ami na krzyż, to sobie poradzę - napisałem w assemblerze najlepiej jak umiałem, ale patrzę w plikahc pośrednich kompilatora jak on to zrobił żeby porównać i kurde każdorazowo kompilator robi to lepiej niż ja, a ja muszę szukać po internecie do czego służa kolejne rozkazy i co się dzieje w znacznikach... Krótko mówiąc na moim poziomie chyba wydajniejsze będzie cofnięcie się z procedurą VBL do Pascala:-) Tebe, znowu jestem pod wrażeniem:-)
      • 20: CommentAuthorzbyti
      • CommentTime20 May 2020 18:05 zmieniony
       

      Mq:

      (...) każdorazowo kompilator robi to lepiej niż ja (...) Tebe, znowu jestem pod wrażeniem:-)

      Podpisuję się pod powyższym, mam podobne doświadczenie z moją pierwszą próbą napisania tego samego w MADS co napisałem w MP :D

      Za drugą próbą poszło mi już odrobinę lepiej ale i tak @tebe to magik! :]
      • 21: CommentAuthortebe
      • CommentTime20 May 2020 19:05
       
      można podejrzeć, skopiować i wkleić kod który generuje MP bezpośrednio do bloku ASM

      jeśli wygenerowany kod MP nie korzysta ze stosu programowego to można taki kod bezpiecznie zostawić na przerwaniu VBL
      • 22:
         
        CommentAuthorMq
      • CommentTime20 May 2020 21:05
       
      Zacząłem tak robić, bo myślałem, że będę w stanie coś w tym kodzie jeszcze ręcznie poprawić i zoptymalizować.

      Czasami ma to sens, np. jak w Mad Pascalu mam jakąś pętle ze zmiennymi, a w samej pętli robię na tyle proste operacje, że da się to zrobić np. samym akumulatorem, to z poziomu assemblera można się w tych wygenerowanych pętlach pozbyć całkowicie tych zmiennych i zastąpić ich wykorzystanie po prostu rejestrem x lub y. Zmniejsza to trochę zużycie pamięci i pewnie przyspiesza, bo zamiast operacji na zmiennych robimy sobie np. tylko inx (przykładowo w pętlach typu for).

      Natomiast poza wyżej opisanym przykładem, nic innego nie udało mi się zoptymalizować, widać jestem cieńkszy w asm niż tebe:-)
      Z tego powodu rozważam powrót do niektórych fragmentów kodu Pascalowego zamiast asm, bo w zapisie kod jest krótszy, bardziej przejrzysty i czytelny, łatwiej pozwala odnajdywać się w długim programie i wprowadzać modyfikacje niż żmudne grzebanie w asm. Takie mam odczucia.
      • 23:
         
        CommentAuthorjhusak
      • CommentTime20 May 2020 22:05
       
      I to zaczyna być idealne narzędzie. Generuje kod w ASM, który trudno zoptymalizować.
      • 24: CommentAuthormarok
      • CommentTime6 Jun 2020 14:06
       
      interesuje mnie tu porównanie w dwóch innych ważnych dla mnie na tym etapie aspektach (a odpalam z MadPascala):

      1) który player odpalany raz na ramkę w przerwaniu VBL zajmie mniej czasu w tym przerwaniu

      2) czy któryś z playerów może zajmować znacząco mniej pamięci niż drugi (tu w sumie dodatkowo nasuwa mi się pytanie, czy jeśli zrobimy w rmt i w cmc taką samą muzyczkę (tyle samo dźwięków, patternów, tracków), to czy któraś zajmie znacząco mniej miejsca)



      Zrobiłem sobie stosowne teksty (odpalałem badany player raz po raz liczbę razy odpowiadającą 3-m minutom normalnego używania, 1 na ramkę), żeby się nimi też podzielić (niech będzie że i pochwalić).


      odp.1) Z tego co widzę na przykładzie "Lasermania", przewagę szybkości ma RMT. Dodatkowo przypuszczam że może mieć mniejsze swoje maksima (najwyższego notowanego obciążenia w ramce), ale tego nie wiem / nie sprawdziłem.

      odp.2) To trzba by policzyć całościowo. Bo najlepiej nie tylko sam player ale też brać pod uwagę różnicę wielkości modułu w różnych formatach. Moduł CMC może być wyraźnie mniejszy, jak pokazuje przykład Lasermanii, a player to rzecz o tyle zmienna, że RMT może generować optymalizowany kod pod muzykę (ograniczyć się do rodzaju wykorzystywanych typów dźwięków).

      Przy porównaniu obu playerów, warto zwrócić uwagę, czy na pewno dysponujemy wolną przestrzenią na stronie zerowej. Jeśli jej dramatycznie zaczyna nam brakować, to CMC jest tutaj idealnym rozwiązaniem, ponieważ jego player jest przystosowany do bezkolizyjnego używania pamięci tego obszaru. (Korzysta z makskymalnie 4 bajtów strony zerowej, za każdym razem zapisując i zwracając poprzednią ich zawartość przed i po powrocie z obsługi muzyki po przerwaniu.)

      (Oczywiście można byłoby pomyśleć o innej wersji playera do cmc, który by się o to nie troszczył w takim stopniu, która niewątpliwie byłaby znacznie szybsza niż to co jest dostępne teraz, ale tego aktualnie z pewnością nie ma.)


      To teraz uzyskane wyniki:

      Lasermania_2000.rmt
      1: A=01 X=E2 Y=6A
      2: A=01 X=BD Y=73

      lasermania.cmc
      5: A=01 X=D1 Y=89
      1: A=02 X=20 Y=E0
      2: A=02 X=27 Y=6B
      3: A=02 X=24 Y=76
      4: A=02 X=25 Y=72


      Cyfra przed dwukropką to rodzaj playera. Po drukropce są wartości czasu w ramkach zapisane w rejestrach (od lewa do prawa - konkretnie: A*$100+X) oraz w Y kalkulacja na wartości $D40B przed i na koniec, której do końca nie podejmuję się komentować (najmniej znacząca wartość, wyznacza niecałkowitą część ramki zajmowaną przez wywołania, ponad całe ramki).

      Playery RMT, to: 1: uniwersalny / standardowy - bez optymalizacji pod muzyczkę, 2: optymalizowany pod moduł (jako całość wszystkich podsongów).

      Playery CMC, to: 1: Jaskiera, powszechny standard, sprawdzony, stabilny; 2: Player poprzedniej wersji (nie do końca udanej) CMC2.2; 3: To pierwotna wersja Janusza Pelca, jednak z dwoma drobnymi poprawkami (Jaskiera), które zabezpieczają go przed błędami w odtwarzaniu; 4: Pierwotna wersja Janusza Pelca, bez poprawek - obecna chyba we wszystkich wersjach CMC, jakie powstały po modyfikacjach, oraz we wszystkich grach i produkcjach z epoki (zanim upowszechniła się ta wersja od Jaskiera); 5: To obecna wersja CMC2.2 .

      Czasem wyniki kształtują się trochę różnie w zależności od wybranej muzyki i różnice między playerami są nieco mniejsze lub większe niż wynikałoby to z proporcji wyciąganej na podstawie jakiegoś pojedynczego przypadku.