Hello, Guest the thread was called447 times and contains 16 replays

last post from zoidberg at the

Sprite ruckelt über den Bildschirm

  • Hallo,


    ich versuche mir gerade (wieder einmal ;)) ein paar Assembler Grundlagen zu erarbeiten.

    Mein Ziel war es, ein Sprite über den Bildschirm fliegen zu lassen.


    Das funktioniert prinzipiell, leider ist die Bewegung nicht flüssig, es hakelt ab und an mal.

    Getestet habe ich auch auf originaler Hardware, da sieht es flüssiger aus als in VICE, es hakelt aber trotzdem an der ein oder anderen Stelle.


    Könntet ihr da bitte mal drüberschauen, habe gerade keine Idee mehr was die Ursache dafür ist...


    Dann gleich noch eine andere Frage.

    Wenn ich das PRG-file im CBM Studio mit dem Basic Loader generieren lasse, dann wird das ewig groß.

    Wie kann man das kompakter machen?


    Geht das nur, indem man mittels einer Schleife die Bytes nach $0801... kopiert?

    Also analog zur Schleife mit den Spritedaten.


    Viele Grüße

    Jens

  • Wegen der Verzögerung: Mach das nicht mit einem Timer oder Zähler, mach das am besten mit dem VSync. Einfach auf einen bestimmten Wert in $d012 warten:


    lda #240

    -

    cmp $d012

    bne -



    Wegen der Größe:

    Assembler packen da einfach die erzeugten Blöcke hinterander. Lücken werden dann mit Nullen aufgefüllt. Gibt es einen Grund, warum du deinen Code und die Daten bei $c000 lagerst? Da wärst du bei der Größe problemlos noch unter deinen endgültigen Spritedaten ($3e80).

  • @ Endurion

    In den Zeilen 28-30 frage ich bereits das Rasterregister auf Zeile 0 ab:


    loop2

    lda $d012 ; Warte auf Rasterzeile 0

    bne loop2

    Das verlangsamte schon, aber das Sprite flitzte trotzdem noch zu schnell über den Bildschirm, aus dem Grund noch der Aufruf der Verzögerungssroutine.

    Außerdem war meine Idee, immer die Rasterzeile 0 abzuwarten, und dann im nicht sichbaren Bereich die Positionsregister der Sprites neu zu beschreiben.

    Damit wollte ich das Ruckeln verhindern.


    Einen besonderen Grund das Programm bei $c000 abzulegen gab es nicht.

    Das könnte ich anpassen.


    @ oobdoo

    Mit dem SEI wollte ich während meines Programmablaufs die Interrupts deaktivieren um auszuschließen, dass das Ruckeln des Sprites von irgendwelchen Interrupts verursacht wird.


    Aber trotz deaktivierter Interrupts und warten auf Rasterzeile 0 ruckelt es trotzdem noch X(


    Was könnte das denn noch sein?

  • In den Zeilen 28-30 frage ich bereits das Rasterregister auf Zeile 0 ab:

    Warte stattdessen mal vor den beiden STX auf Rasterzeile $fe, und nach den beiden STX dann auf Rasterzeile $ff.


    Die Rasterzeile $00 gibt es nämlich zweimal: EInmal als $000 und einmal als $100, aber um die zu unterscheiden, müsste man auch noch das Bit 8 des Rasterregisters überprüfen. Mit $fe und $ff hast Du das Problem nicht.


    Und das zweite Problem ist, dass STX/STX/INX/BNE einfach zu schnell ist: Danach ist man immer noch in der gleichen Rasterzeile. Deshalb die zwei Tests auf verschiedene Zeilen (die später wieder rausfliegen können, sobald da mehr Code hinzugekommen ist).

  • Hallo Neptun und Mac Bacon,


    danke für die Hinweise, das leuchtet mir ein.

    Ich werde das auch mal mit dem Interrupt versuchen, würde aber trotzdem gerne verstehen, warum das so nicht klappt.


    Ich habe jetzt mal versucht die beiden Abfragen auf $fe und $ff in mein Programm einzubauen.


    Lieder ruckelt es immer noch.

    Drei mal pro Bewegungsablauf hakt es kurz.

    Hab ich bei der Abfrage was falsch gemacht oder gibt`s noch ein weiters Problem?


  • Lieder ruckelt es immer noch.

    Drei mal pro Bewegungsablauf hakt es kurz.

    Hab ich bei der Abfrage was falsch gemacht oder gibt`s noch ein weiters Problem?

    Ich wüsste nicht, was da noch für ein Problem sein könnte, abgesehen von der Wiederholfrequenz des Emulators. Probier es mal an echter Hardware.

  • Ich habe es jedesmal am echten C64 getestet.

    Im Emulator läuft es auch nicht sanft durch, aber das Verhalten ist ein anderes im Vergleich zur echten Hardware.


    Dachte so ein kleines Progrämmchen wäre gut für den Einstieg geeignet.

    Hab nicht geglaubt, dass es so viele Probleme bereiten würde.


    Gibt es noch irgendwelche Tests die ich durchführen könnte um das Problem weiter einzugrenzen?

    Mich würde wirklich die Ursache interessieren.

  • Gibt es noch irgendwelche Tests die ich durchführen könnte um das Problem weiter einzugrenzen?

    Mich würde wirklich die Ursache interessieren.

    Die Ursache hat Acorn ja schon genannt, aber um so ein Problem selbst zu finden, ist die einfachste Methode: vor/nach dem interessanten Bereich ein INC/DEC $d020 zu schreiben. Damit sieht man dann an den Änderungen der Randfarbe, ob der Code immer an der gleichen Stelle im Frame ausgeführt wird, oder ob es Verzögerungen gibt (wie hier durch den Interrupt).

  • Hallo zoidberg,


    Im Beitrag 7 hatte ich nur das Problem mit der Abfrage der Rasterzeile behoben.


    Mein zweites Problem war, dass durch den Aufruf der Systemroutine $ffd2 (Zeichen ausgeben) mein vorangegangener Befehl SEI zum verhindern der Interrupts wieder aufgehoben wurde.

    Die Lösung ist einfach, der Befehl SEI muss nach dem Aufruf von $ffd2 eingefügt werden.