TommyGun Routinen

  • Hi all,
    da ich mal ein wenig mit TommyGun (<!-- m --><a class="postlink" href="http://www.users.on.net/~tonyt73/TommyGun/">http://www.users.on.net/~tonyt73/TommyGun/</a><!-- m -->) beschaeftigt habe und das Tool nicht schlecht finde, hab ich mal versucht Sprites aus dem Programm heraus darzustellen. Da es bisher keine Beispielroutinen gibt sind dabei folgende zwei kleinen Routinen zur Spritedarstellung herausgekommen.
    Die beiden Routinen habe ich "in a hurry" geschrieben, man kann also sicherlich noch Geschwindigkeit rausholen. Jegliche Vorschlaege werden gerne angenommen.


    Die Routinen habe ich bisher nur in Mode 0 benutzt. Die anderen Modes habe ich damit nicht getestet.


    Vielleicht hat ja noch jemand Lust, TommyGun ein wenig zu testen und baut z.B. die Map-Routinen, denn die gibts bisher auch nicht. Was meint ihr?



  • Hi,


    hier, die arbeitet etwas zügiger:



    CU,
    Prodatron

  • Oha, jetzt holste aber jede Kleinigkeit noch raus :D. Ich glaub ich muss mehr in selbstmodifizierenden Code denken. Hab ich frueher nie benutzt und ist irgendwie ein wenig ungewohnt ;). Solange man kein ROM schreibt...
    Muss demnaechst mal die Maps anschauen, vielleicht kann man da dann auch ne schnelle Routine basteln und dem Autor dann als Beispiel zukommen lassen.

  • Zitat von &quot;Octoate&quot;

    Oha, jetzt holste aber jede Kleinigkeit noch raus :D. Ich glaub ich muss mehr in selbstmodifizierenden Code denken. Hab ich frueher nie benutzt und ist irgendwie ein wenig ungewohnt ;). Solange man kein ROM schreibt...
    Muss demnaechst mal die Maps anschauen, vielleicht kann man da dann auch ne schnelle Routine basteln und dem Autor dann als Beispiel zukommen lassen.


    Also meine Routine braucht in der "inner loop" 5 ms pro byte, während die ursprüngliche 12 braucht, also mehr als doppelt so lang. Gerade bei so aufgelösten Schleifen ist selbstmodifizierter Code super, da man dann trotz fehlendem Zähler eine dynamische Ausführungswiederholung hat. Das findet sich in den Lowlevel-Screen-Routinen von SymbOS des öfteren.
    Die anderen Einsatzgebiete von selbstmodifiziertem Code (Variablen direkt in den Code schreiben, Jump-Ziele patchen, Befehle austauschen [z.B. Flag setzen oder löschen]) hat zwar auch Geschwindigkeitsvorteile, die sind aber oft nicht so extrem.


    CU,
    Prodatron

  • hallo, arbeitet die x-richtung byteweise oder pixelweise?
    mfg

  • Zitat von &quot;super_castle&quot;

    hallo, arbeitet die x-richtung byteweise oder pixelweise?
    mfg


    Die arbeitet byteweise. Für Mode 0 würde ich eh niemals pixelweise Routinen schreiben, da das geschwindigkeitsmäßig große Abstriche bedeutet und man ja jedes Sprite eh "nur" 2x ablegen muß, wenn man es pixelweise positionieren will.

  • das heisst ein softscrolling bekommt man nicht hin?
    es ist also in x-richtung eine blockverschiebung?


    der mauszeiger in symbos geht aber pixelweise, könntest du die routine mal hier reinstellen?


    mfg

  • Zitat von &quot;super_castle&quot;

    das heisst ein softscrolling bekommt man nicht hin?
    es ist also in x-richtung eine blockverschiebung?


    Du legst das Sprite ja 2x ab, die zweite Kopie ist um ein Pixel verschoben. Du hast dann ein "Softscrolling":
    - plotte an scradr+0 spritekopie 1
    - plotte an scradr+0 spritekopie 2
    - plotte an scradr+1 spritekopie 1
    - plotte an scradr+1 spritekopie 2
    - plotte an scradr+2 spritekopie 1
    usw...


    Zitat

    der mauszeiger in symbos geht aber pixelweise, könntest du die routine mal hier reinstellen?


    Für den lege ich je nach Screenmode ebenfalls mehrere Kopien an, in Mode2 sind es 8 pixelverschobene Kopien, in Mode1 sinds 4 und in Mode0 (fliegt allerdings bald raus) sind 2.


    Hier der innere Teil der Routine, die den Mauszeiger plottet:



    Da die Routine clipping-fähig ist, sind die drei Zeilen ab mspout2 notwendig, ansonsten kann man die weglassen, wenn die Maskenbreite immer gleich der sichtbaren Breite ist.

  • Nach was zu den Transparentfähigen Routinen:
    Wie man sieht, benötigt Octos Innerloop 37 Microsekunden, die SymbOS-Mauszeiger-Innerloop nur 22 Microsekunden, wobei diese durch die zusätzliche And-Maske sogar flexibler ist, was die transparenten Pixel betrifft. Eigentlich kann man meinen, daß man für Mode 0 keine And-Maske benötigt, da es bei 16 Farben kein Problem ist, eine (also die 0) davon fest für Transparenz zu reservieren. Aber es ist Geschwindigkeitsmäßig halt ein großer Vorteil.


    Auch so richtig viele Gedanken über transparentfähige Spriteroutinen hat sich Richard Wilson, der WinApe Author, hier gemacht:
    <!-- m --><a class="postlink" href="http://www.cpcwiki.com/index.php/Programming:Fast_Sprites">http://www.cpcwiki.com/index.php/Progra ... st_Sprites</a><!-- m -->


    Cool ist die Idee, die And/Or-Maske zusammenzuklatschen, man braucht dann kein IX mehr und man spart weitere 4 Microsekunden pro Byte (knapp 20%). Wenn ich mal dazu komme, stell ich die SymbOS-Mauszeigerroutine auch darauf um.


    CU,
    Prodatron

  • Zitat


    Du legst das Sprite ja 2x ab, die zweite Kopie ist um ein Pixel verschoben. Du hast dann ein "Softscrolling":



    mus es nicht 8x abgelegt werden für eine byteverschiebung in pixel?


    mfg

  • Wie gesagt:
    - in Mode2 sind es 8 pixelverschobene Kopien
    - in Mode1 sinds 4
    - und in Mode0 sind 2


    Und weil Octo wohl in Mode0 arbeiten will, braucht er nur 2 Kopien.


    CU,
    Prodatron