Rastertime-Verbrauch von SIDs - Erfahrungswerte?

Es gibt 35 Antworten in diesem Thema, welches 5.006 mal aufgerufen wurde. Der letzte Beitrag (22. August 2012 um 16:22) ist von sauhund.

  • Hi!

    Eigentlich dürfte man ja annehmen, dass die in den 80s aktiven Musicians schon von den Game-Codern nicht nur in Sachen RAM, sondern auch beim Timing sehr enge Grenzen gesteckt bekommen haben und dass heutzutage die gängigen Tools schon dafür sorgen, dass der Rasterkonsum der .SIDs nicht ausartet.

    Aber da man schon Pferde kotzen gesehen haben soll, würde mich interessieren, was so die (aus Coder-Perspektive: Negativ)-Rekorde in Sachen ausufernde .SID-Rastertime ist. Ich habe irgendwo mal was von #$18 Zeilen gelesen, aber keine Ahnung, wie fundiert das ist, finde das eher zweifelhaft. Meine auch mich zu erinnern schon über #$20 Teilen hinausgehende Tunes "in den Fingern" gehabt zu haben.

    Gibt es da Erfahrungswerte oder könnt Ihr mir besonders krasse bekanntere Beispiele nennen, also generell laaahme Player, aber auch spezielle Tunes, notfalls auch welche mit Digi-Instrumenten, aber jetzt nicht so'n 10-sekunden-lang rumknirschender converted-außem-radio-kack, schon bekanntere, qualitativ genießbare sachen.

    Danke im Voraus
    Ryk

    PS: Ach ja: True Stereo/DualSID Sachen dürften wohl auch ca. doppelt so raster-hungrig sein wie Mono, oder?
    PPS: Auch Quad Speed Kram interessiert mich.

  • Der Soundmonitor war glaub ich sehr hungrig in Sachen Rasterzeit.

  • Die alten Player gingen teilweise stark über eine Zeit von #$20 Lines hinaus. Die aktuellen Player brauchen meistens nicht viel mehr als #$18 Lines. Kommt aber auch drauf an wie gut der Player da optimiert ist, nimm z.B. mal die aktuellste Version des JCH mit den 22-25FX Playern von Dane, ich glaub der 24er ist sehr stark auf möglichst wenig Rasterzeit optimiert worden.

    Edit: Hab' mal schnell nachgeguckt, der 24er Player scheint auf den ersten Blick nicht mehr als #$11-#$12 zu verbrauchen.

  • zum Thema negativ-Rekord wird sich hoffentlich Peiselulli äußern können :biggrin: ich erinnere mich da an sein rumgeflame bezüglich eines speziellen "Musikheldens mit Rasterzeitwahn" :biggrin:

    Mein Handle ist eigentlich "Slator", allerdings hatte ich vor Ewigkeiten mal meine Zugangsdaten verlegt und mir hier ein neues Konto gemacht, daher nun Fratzengeballer in diversen Foren :-D

    Do you want to have unlimited lives ? [y/n] - besitzt mehr Hardware als seiner Frau lieb ist....

  • @all: schon mal Danke soweit!

    @geballer: auf peiselullis Schimpftirade bin ich ja mal gespannt :) Habe inspiriert von Deinem Hinweis auf Musikhelden mal ins Blaue geraten und mir Hülsbecks Katakis vorgenommen:

    Code
    Tune #$00 #$2b
    Tune #$02 #$2c
    Tune #$04 #$2c


    Das ist schon mal nicht gerade "heldenhaft niedriger" Rasterzeitverbrauch :S

    PS: Falls jemand Lust auf Tools 4 Fools hat zum Experimentieren (start mit SYS49152, nicht über Syntax Error nach dem Laden wundern, NICHT ClearScreen machen, der SID ragt nunmal über Basic Start und Screen, oben links im Screen wird Konsum als Char angezeigt, sicher nicht superschön/toll, eben mal so hingerotzt.)

    Edit: Play und Ini waren vertauscht hehehe, man weiß schon, warum man meinen Code besser nicht assembliert :)

  • Danke, dann hatte ich ja richtig geraten, die gewählten Beispiele (DEZ bis 44 Zeilen) gehen ja auch in diese Richtung :D

  • Huiuiui, in der Zeit können ja locker 10-12 Boulderdash-Titellieder abgespielt werden :D

  • Zitat

    Hülsbecks Katakis vorgenommen:


    ramiro vaca. (man kann eigentlich grundsätzlich sagen: immer wenn die musik gut war hatte auch noch wer anders die finger im spiel =P)

    Zitat

    Meine Erinnerung an Chris Hülsbeck war, dass sein Player bis zu 50 Rasterzeilen gefressen hat ...


    wobei der player in giana sisters usw schon fast sparsam mit rasterzeit umgeht - der soundmonitor braucht bei peaks auch mal 100 zeilen =P

    electrosound ist btw noch so ein player mit fiesem rasterzeitverbrauch

  • Ich habe irgendwo mal was von #$18 Zeilen gelesen,

    im mittel oder worst case? für spiele ist eher worst case interessant. der darf nicht ausufern.

    an sich denke ich könnens schon mal so viel sein, wenn alle stimmen umschalten, glaube ich. es wären 6 rsterzeilen pro stimme. naja, unter 2-4 gehts nicht.

  • soundmonitor braucht bei peaks auch mal 100 zeilen


    OUCH!

    btw aktuell wird ja zT mal über Goat vs SDI diskutiert. Stimmt es, dass SDI weniger ökonomisch ist?

  • Btw., die Musikroutine in Friday the 13th spielt zwar (mangels schöngeistigem Huffi-Fluffi wie Vibrato o.ä.) einigermassen flott, aber das Initialisieren der Stücke kann auch schon mal n halben Frame dauern, weil nur die Anfangsadresse des jeweils ersten Tracks in der Songliste gespeichert ist und die übrigen Trackstarts mittels Durchsuchen der vorigen Spuren ermittelt werden.

  • weil nur die Anfangsadresse des jeweils ersten Tracks in der Songliste gespeichert ist und die übrigen Trackstarts mittels Durchsuchen der vorigen Spuren ermittelt werden.


    Hehehe, das erinnert mich an an ein paar selbst für meine Verhältnisse seeehr schlechte Codingversuche ins Sachen Sortier-Algo vor vielen Monden :D

  • Ich hab' mal bei einem Worktune von Dane nachgeguckt der den Newplayer 24FX nutzt, braucht max. $15 :)

  • Bedeutet das nun nicht wenig Rasterzeit von vielen vielen Optimierungen (weglassen von 'Auflösung' z.b Pulse-skipping usw) her kommt und deshalb die bestmögliche Ausgabequalität auf der Strecke bleibt? Besagte Dane Tunes hören sich in letzten Jahren ziemlich flach an, so nebenbei angemerkt.
    Goattracker macht das mit dem weglassen ja auch ber DEFAULT, auf kosten der Qualität.

  • @Naughty: So argumentieren tatsächlich auch einige Musicians, die ich kenne, mal abgesehen davon sind die oft bei Filter Use ziemlich entsetzt, wie groß der Unterschied bei Goat auf real hardware ist.

  • Normalerweise dürfte es da keinen Unterschied geben. Beim Optimieren des Players sollen ja bestimmte Befehlskombinationen in Assembler gegen andere ausgetauscht werden die weniger Taktzyklen benötigen aber zum gleichen Ergebnis führen. Zusätzlich könnte man noch im fertigen Tune nicht benötigte Routinen per Hand deaktivieren.

  • Whittaker: Panther! #$4f bzw 79 Zeilen Ein Wunder, dass da noch Rasterzeit für ein Ballerspiel übrig blieb...

    #$2F scheint sich als Durchschnittswert für ältere Player herauszukristallisieren (oder es haben einfach verdammt viele Leute den gleichen benutzt)

  • schlechtester Musikplayer: meine "Musikversuche" in Basic: 100% Rechenzeitverbrauch bei nur einer Stimme, da Tonlängen über Warteschleifen gesteuert wurden (als ich noch ein Kind war hab ich mich trotzdem gefreut der Kiste eine Melodie zu entlocken, obwohl die Programmierung mehr als mies war...)

    **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. ****

  • Zitat

    Normalerweise dürfte es da keinen Unterschied geben.


    gibts auch nicht, und natabamu schwafelt einfach nur wie immer quark. beim goattracker gibts ein ganz andres problem, nämlich das im tracker selber ein ganz anderer player benutzt wird als der mit dem am ende der gepackte tune gespielt wird (im GT ist zwar eine SID- aber keine CPU emulation) - und daher kommen die unterschiede.

    Zitat

    Beim Optimieren des Players sollen ja bestimmte Befehlskombinationen in Assembler gegen andere ausgetauscht werden die weniger Taktzyklen benötigen aber zum gleichen Ergebnis führen. Zusätzlich könnte man noch im fertigen Tune nicht benötigte Routinen per Hand deaktivieren.


    genau. es ist eine equivalente umformung bei der sich das endergebnis nicht ändert.