Hello, Guest the thread was called9.2k times and contains 35 replays

last post from spacer at the

Code für bitweises Verschieben von Character a -> b optimieren

  • So, ich konnte mich am WE endlich wieder mit dem Programm auseinandersetzen.


    Dabei habe ich mich hauptsächlich an den Vorschlägen von Acorn und JeeK gehalten.


    Da die Zeichen im Speicher hintereinander liegen, kann man hoch/runter auch mit Selfmod-Code kürzen.


    Deine Variante ist eigentlich mein Favorit, weil sie schön klar und übersichtlich ist.

    Da ich die Adressen (CHAR_AB, CHAR_CD,...) nicht als Konstanten definiert habe sondern vorher ermitteln und setzen muss fallen die Vorteile leider wieder unter den Tisch.

    Ich brauche so über 20 Bytes mehr als zuvor.


    Ich habe Deinen Code nicht abgetippt, mich aber mich an Deiner Idee orientiert.



    -------------------------------------------------------------------------------------------------------------------------

    Hier ist das bisherige Ergebnis:



    - Das erste Drittel kümmert sich nur darum die Adressen für die adr_*-Speicherstellen zu ermitteln und zu setzen.

    Dabei wird so viel Platz verbraucht, dass sich die ganze Vorteile im weiteren Verlauf nicht mehr rechnen.


    - Dann kommt die UP/DOWN-Bewegung nach Acorns Vorschlag. Die DOWN-Routine läuft sehr gut. Die UP-Routine funktioniert bei mir nicht.

    Wahrscheinlich fehlt mir die nötige Erfahrung um genau sagen zu können warum nicht.


    - Die Rechts/Links-Bewegung hatte ich ja schon präsentiert. Die habe ich nach dem Vorschlag von Neptun umgesetzt.

    Sie läuft super und bleibt auch so.


    Es läuft also im Ergebnis auf einen Mix aus meiner ersten Version für UP/DOWN und dem selbst-modifizierenden Code für R/L hinaus.

    Ich baue noch den Hinweis von Jeek mit ein (Tausch des Zwischenspeichers von PHA/PLA innerhalb der Schleife auf das X-Register) um ein paar Zyklen einzusparen.


    Wenn das Fertig ist kopieren ich das hier nochmal rein.


    VG


    aitsch

  • Also in Zeile 20 das SBC, sollte man da nicht sicherheitshalber ein SEC setzen. Mich wunderts, dass DOWN zuverlässig funktioniert ... Gegebenenfalls muss auch das High-Byte berücksicht werden, wenn es zum Unterlauf bei der Subtraktion kommt, was ja wahrscheinlich ist, weil das Low-Byte ja eher kleiner $F0 sein wird. Wenn aber in diesem Fall DOWN funktioniert (mit einem falschen High-Byte?), dann wird aber UP falsch sein, weil dort das (eigentlich) richtige High-Byte dann als falsch gelten könnte ...

    - Dann kommt die UP/DOWN-Bewegung nach Acorns Vorschlag. Die DOWN-Routine läuft sehr gut. Die UP-Routine funktioniert bei mir nicht.

    Wahrscheinlich fehlt mir die nötige Erfahrung um genau sagen zu können warum nicht.

    Wie zeigt sich das? Warum nicht im VICE testen, Breakpoint auf die Routine setzen und Schritt für Schritt durchgehen ...

  • Mit einer kleinen Änderung an COPY_DOWN, kann man das kopieren in einer Unterroutine ausführen. Übrigens ein JMP .END kostet 3 Byte. :D


  • Das eintragen der Adressen kostet jetzt zwar weniger, aber mit der Indirekten spart man doch mehr ein.

  • Ich hab nicht alles gelesen vielleicht verstehe ich das Thema deswegen nicht wirklich (vielleicht auch Thema verfehlt oder das war schon hier so vorgekommen), aber:

    Übrigens der Kram ist beliebig optimierbar.. Vor allem das Entrollen der Schleifen bring Performance wenn Speicher nicht so wichtig ist.. Ich würde das wahrscheinlich nie als Schleife schreiben..

    Have Fun!

    ( Hoffe das hilft vielleicht eventuell weiter! :) )

  • Ich hab nicht alles gelesen vielleicht verstehe ich das Thema deswegen nicht wirklich (vielleicht auch Thema verfehlt oder das war schon hier so vorgekommen), aber:

    Übrigens der Kram ist beliebig optimierbar.. Vor allem das Entrollen der Schleifen bring Performance wenn Speicher nicht so wichtig ist.. Ich würde das wahrscheinlich nie als Schleife schreiben..

    Have Fun!

    Danke für die Anregung.

    Speicher ist extrem wichtig.

    Das Spiel soll nach aktueller Planung 10 verschiedene Maps und zum Schluss noch einen Bosskampf beinhalten.

    Ich versuche alles auf einem unexpandierten VC-20 - also auf nur 3,5 kByte - unterzubringen.

    Es zählt also jeden Byte.


    Das ist die Challenge (oder auch nur der wahnwitzige Traum eines alternden Nerds)

  • Wenn es nur auf 3,5kByte läuft , fehlen die schönen vielen eigenen erstellten Char um den ganzen Screen schön optisch zu gestallten..

    Bei 3,5kByte musst du dann die unansehnlichen Char nehmen.


    Bei mir läuft es Teilweise schon mit dem Turbo Rascal ab 8kByte um den Screen schön aussehen zu lassen.

    Jetzt brauche ich nur noch die Abfragen zu machen zur Senkrechten, das andere funktioniert schon.

    In Turbo Rascal kann man noch schönen feinen eigenen ASM-Code reinbringen.


    Ich habe den Char-Sprite auch mal in ASM angefangen , wurde aber nach und nach unübersichtlich für mich.

    Ich habe so viele abfragen gehabt , die auch nötig waren.


    Gruss

  • Mein Ziel ist es auf jeden Fall mein Projekt in Assembler umzusetzen. Es ist der Spaß an der Sache.

    Eine andere Programmiersprache kommt für mich nicht in Frage.

    Bevor ich auf eine Speichererweitung für den VIC wechseln würde, würde ich eher das ganze Projekt auf dem C64 realisieren.


    Und ja, es werden "häßliche", einfarbige Charaktäre werden. Das war damals halt so und ich will auch keinen Preis damit gewinnen.


    VG

  • Quote

    Bevor ich auf eine Speichererweitung für den VIC wechseln würde, würde ich eher das ganze Projekt auf dem C64 realisieren.


    Na, so schnell gibst du den VIC20 auf , nur um nicht 3kB einzubauen.

    Ich dachte er war dein Freund um ihn total kennnenzulernen, also ist er ein kurzzeitiger Durchläufer.


    Dann bist du ja kein VIC20 fan .


    Gruss

  • Quote

    Ich suche schon länger, nach einer brauchbaren Lösung für Softwaresprites auf dem VC-20.


    Gib in Google "VIC20 oder VC20" ein , dann erscheinen einige schöne Spritevorschläge im ASM-Code für den VIC.

    Sind leicht lesbar und man kann sie verstehen. Es sind kleinere und Größere ASM-Programme.


    Die sind so gut geschrieben das man hier nicht Fragen braucht, sondern damit lernen kann.


    Gruss

  • Ich sehe keinen Grund aitsch ständig vorzuhalten, was er denn zu machen hat. Ich glaube, er fühlt sich ganz wohl, wie er die Sache angeht und man muss ihn da wohl auch nicht überzeugen das oder dies zu machen. Wirklich "Lernen" tut man nur, wenn die Idee selbst entwickelt, verbessert und von Grund auf selbst macht. Und wenn man bei einem Detail stecken bleibt, hier einfach im Forum fragt. Danach dann mit anderen Lösungen zu vergleichen, schadet natürlich nicht und sich daran zu verbessern. Aber von Haus aus sich Sachen aus dem Internet zu kopieren und daraus "lernen" zu wollen, reicht m.E. nicht, um sich wirklich gute Fähigkeiten anzueignen.

    Das wäre in etwas so, wenn ich ein guter Buchautor werden will und mir aus dem Internet die tollsten Werke der Weltliteratur herunterlade und "anschaue" bzw. lerne ... davon ist noch niemand ein auch nur halbwegs passabler Buchautor geworden. ;)