Hallo Besucher, der Thread wurde 9,4k mal aufgerufen und enthält 71 Antworten

letzter Beitrag von ThomBraxton am

Fullscreen Smooth Scroll zuckt

  • Ein verpasster IRQ ist wohl drin: Wenn du das Programm langsam ablaufen läßt, dann färbt sich der Rahmen stets einmal rot. Vermutlich inc von weiß, statt dem IRQ-Init schwarz

    Das müsste eigentlich okay sein. Ich setze die Bordercolor an zwei Stellen: einmal im Interrupt (weiß) und einmal in der screen RAM Kopierschleife (rotes zucken circa einmal pro Sekunde.



    Ich vermute, wenn Du das Color-RAM weglässt, dürfte es nicht mehr (oder nur noch ganz oben) zucken. Richtig?

    Korrekt



    Soll es denn ein Demo Effekt werden oder ein Game? Hast Du denn genug Speicher?
    Ich würde in der Mainloop immer auf einen Wert (wie 1 z.B.) warten, diesen dann im Raster setzen und dann die Unterroutine move_screen anspringen:

    Ich will mich mal an einer Game-Idee versuchen.
    Speicher - keine Ahnung, ist alles noch in der Experimentierphase.


    Ja, Dein Ansatz ist genau der, den ich auch versucht habe, allerdings im Scrolling Script selbst.
    Aber ich glaube ich verschiebe so ungünstig, dass das Softscrolling eben doch schon weiter ist.
    Ich muss herausfinden, ob ich das obige Script überhaupt nutzen kann, um die Kopierschleifen auf zwei Frames aufzuteilen.

  • Doch, schafft man. Ist aber nicht so ganz trivial ...

    Klar, habe ich ja oben auch gezeigt, mit Speedcode. Aber mit dem Loop von awsm halt nicht ... oder hast du noch ein weiteres Profi-Ass im Ärmel :D


    Achso, da war auch noch ein Dreher in meinem Code.


    Brainfuck-Quellcode
    1. !for j, 0, 24 {
    2. !for i, 0, 38 {
    3. lda SCRRAM+1+i+(40*j)
    4. sta SCRRAM+i+(40*j)
    5. lda COLRAM+1+i+(40*j)
    6. sta COLRAM+i+(40*j)
    7. }
    8. }


    Ich will mich mal an einer Game-Idee versuchen.

    Soll denn das Scrolling in mehrere Richtungen gehen, oder nur nach rechts? Dann wäre das mit dem Speedcode ja trotzdem noch machbar.


    Du kannst sonst versuchen das Kopieren zu splitten, musst dann aber schon in der Rasterline nach dem ersten kopieren anfangen. Bin mir aber jetzt nicht sicher ob das hinkommt. Ansonsten bleibt nur Doublebuffer.


  • Danke übrigens für diese Schleife, ein guter Tritt in den Hintern, das häufiger zu nutzen :D


    Deine korrigierte Variante hat übrigens das gleiche Ergebnis, braucht aber mehr Rasterzeit.

  • Soll denn das Scrolling in mehrere Richtungen gehen, oder nur nach rechts? Dann wäre das mit dem Speedcode ja trotzdem noch machbar.


    Du kannst sonst versuchen das Kopieren zu splitten, musst dann aber schon in der Rasterline nach dem ersten kopieren anfangen. Bin mir aber jetzt nicht sicher ob das hinkommt. Ansonsten bleibt nur Doublebuffer.

    Vorerst nur nach rechts.
    Ich buddel' mich nochmal in das Thema Doublebuffering rein und melde mich dann mit anders gelagerten Verzweiflungsrufen wieder.

  • Die Rasterzeit dürfte gleich sein. In der Variante mit
    !for j, 0, 24 {
    !for i, 0, 38 {
    wird es nur sauber Zeilenweise aufgebaut. Wenn man dem Rasterstrahl rechtzeitig davonrennt, kommt man gerade so hin.


    Bei falschen Variante wird Spaltenweise aufgebaut.


    Bei der Variante mit den zwei Loops wird erst die obere Hälfte kopiert, dann die untere. Allerdings ist da der Loop nicht ausgerollt. Spart natürlich ~11k aber braucht auch mehr Rasterzeit.


    Edit: Achso, das mit der ersten Zeile habe ich gar nicht gesehn, wäre dann ja:
    !for j, 1, 18{
    !for i, 0, 38 {

  • Das PRG hatte ich gar nicht gesehen. Grad mal angeguckt.


    Du bist beim Raster vorm Interface nicht exakt auf der richtigen Rasterzeile (2 zu spät), fällt aber natürlich nicht auf in der grauen Zeile.

  • Du bist beim Raster vorm Interface nicht exakt auf der richtigen Rasterzeile (2 zu spät)

    Bzw. eher sechs zu früh, wenn die graue Char-Zeile eh optisch 'tot' ist.


    Also wenn 6 Zeilen nicht gescrollt werden ist das "problemlos" in einem Frame möglich.

    Verstehe ich grad nicht... :gruebel

  • Verstehe ich grad nicht... :gruebel

    Naja, 19 Zeilen zu scrollen verbrät ja logischerweise weniger Rasterzeit als 25 Zeilen zu scrollen.
    Und damit kann man auch problemlos ohne große Tricks Bildschirm und Farbram in einem Frame scrollen.

  • Also wenn 6 Zeilen nicht gescrollt werden ist das "problemlos" in einem Frame möglich.

    Wirklich problemlos? Dann müsste es ja noch mit einiger Optimierung des Codes möglich sein. Wenn ich mir die Rasterzeit ansehe, dann verstehe ich aber nicht, wo ich noch so signifikant sparen könnte, dass der Aufbau des Screens nicht mit dem Kopieren kollidiert.


    Anbei mal der letzte Stand, einiges habe ich wieder zurückgedreht (z.B. die ACME Schleife, die zwar performanter ist, aber mir zuviele KB schluckte). Oberen und unteren Bildbereich habe ich gesplittet, um diese später in zwei Frames unabhängig zu kopieren.


  • Anbei mal der letzte Stand

    Es geht in die richtige Richtung. Allerdings würde ich an Deiner Stelle vor allem das Double-Buffering implementieren, das ist eigentlich das wichtigste. Dazu würde ich die Routine für das Kopieren des Screen-RAMs mal von der für das Kopieren des Color-RAMs trennen. Erstere müsste man so umbauen, dass sie anstatt innerhalb des selben Puffers von einem Puffer in einen anderen kopiert. Was wiederum bedeutet, dass Du zwei dieser Routinen benötigst, einmal von Puffer 1 nach Puffer 2 und einmal von Puffer 2 nach Puffer 1. Diese Routinen kannst Du schon in einem früheren Frame aufrufen (denn was da passiert sieht man ja erstmal nicht). In dem Frame in dem das xscroll-Register wrapped und in dem Du im Moment alle Scrollingarbeiten machst, musst Du dann nur noch den Screenbuffer im VIC umschalten.


    Wenn Du soweit bist, hast Du schon mal den ganzen Frame frei, um Color-RAM-Scrolling zu veranstalten. Da kommt dann erst der Split in obere und untere Bildschirmhälfte ins Spiel.