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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorMq
   • CommentTime18 May 2020

    
   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. • 2: CommentAuthortebe
   • CommentTime18 May 2020

    

   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. • 3:
      
     CommentAuthorMq
   • CommentTime18 May 2020

    
   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. • 4: CommentAuthorMADRAFi
   • CommentTime18 May 2020 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. • 5: CommentAuthorxxl
   • CommentTime18 May 2020

    
   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. • 6:
      
     CommentAuthorMq
   • CommentTime18 May 2020

    
   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. • 7: CommentAuthortebe
   • CommentTime18 May 2020

    
   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. • 8: CommentAuthorxxl
   • CommentTime18 May 2020 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. • 9:
      
     CommentAuthorMq
   • CommentTime18 May 2020

    
   @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. • 10: CommentAuthorxxl
    • CommentTime18 May 2020

     
    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. • 11:
       
      CommentAuthorMq
    • CommentTime19 May 2020

     
    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. • 12: CommentAuthortebe
    • CommentTime19 May 2020

     
    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. • 13:
       
      CommentAuthorMq
    • CommentTime19 May 2020

     
    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. • 14: CommentAuthorMADRAFi
    • CommentTime19 May 2020 zmieniony

     
    Meczylem Tebego o to by nie musiec tego samemu pisac w swoich programach. I teraz to jest juz wbudowane :)
15. • 15:
       
      CommentAuthorjhusak
    • CommentTime20 May 2020

     
    Tebe, a jak to jest zrobione? (nie to, że jestem leniwy, ale chętnie pewnie wszyscy usłyszą/przeczytają)
16. • 16: CommentAuthorilmenit
    • CommentTime20 May 2020

     
    wewnętrzny licznik i powrót z każdego szóstego zawołania na NTSC?
17. • 17: CommentAuthortebe
    • CommentTime20 May 2020 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. • 18:
       
      CommentAuthorjhusak
    • CommentTime20 May 2020 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. • 19:
       
      CommentAuthorMq
    • CommentTime20 May 2020

     
    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. • 20: CommentAuthorzbyti
    • CommentTime20 May 2020 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. • 21: CommentAuthortebe
    • CommentTime20 May 2020

     
    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. • 22:
       
      CommentAuthorMq
    • CommentTime20 May 2020

     
    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. • 23:
       
      CommentAuthorjhusak
    • CommentTime20 May 2020

     
    I to zaczyna być idealne narzędzie. Generuje kod w ASM, który trudno zoptymalizować.
24. • 24: CommentAuthormarok
    • CommentTime6 Jun 2020

     
    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.