Hallo Besucher, der Thread wurde 5,9k mal aufgerufen und enthält 36 Antworten

letzter Beitrag von Bytebreaker am

Full Screen Scrolling mit ColorRAM

    Das war ein multidirectional Scrolling.
    Wenn ich mich noch richtig erinnere, war gerade mal eine Hand voll Rasterzeilen übrig.
    Leider hab ich den Sourcecode bei den ganzen Tests so verändert, dass ich den ursprünglichen Code nicht mehr habe.


    Eine der späteren Versionen war das: https://csdb.dk/release/?id=150394
    Da hatte ich dann schon Doublebuffer genutzt.

    Hier ist das Ergebnis meines Projekts.


    Load „qt4.prg“,8


    Dann run.


    Die Scrollroutine (4scroll.prg, Start bei $3000) wird vom Basic Programm qt4.prg aus aufgerufen. Das Basic Programm baut auch einen Scrollbereich Vollbildschirm mit ColorRAM auf. In diesem Beispiel ist der Scrollumfang nur der eine Screen. Mein Programm ermöglicht aber das Nachladen von Scrolldaten.


    Mit dem Joystick eine Richtung wählen. Feuer stoppt das Bild. Erst dann kann man erneut die Richtung wechseln.


    Das stabil zu kriegen war schon alles ziemlich nah am Nervenzusammenbruch. Es ist zwar noch ein paar wenige Rasterzeilen Platz, aber für ein Spiel oder ein Intro müsste ich so oder so umbauen, denn Interrupts sind bis auf den NMI aktuell gesperrt. Schon allein Musikwiedergabe würde daher nicht ohne erneutes Anpassen gehen.


    Dennoch war es eine lehrreiche Übung.

    Sieht cool aus! Cooler Fullscreen Scroll!


    Mir ist nochwas aufgefallen, da ich hier gerade selber eine Routine für sowas am Wickel habe. Das Ding ist, dass du eigentlich 1,5 Frames zur Verfügung hast um den gesamten Screen zu scrollen.


    Wenn dass der Screen ist:
    0
    1
    2
    .
    .
    .
    12
    .
    .
    .
    24


    Kannst du auf Rasterzeile "12" warten. Bei der setzt du die neuen Properties für Rasterzeile "0" in ein paar ScreenRamAddress Zwischenspeicher..


    Und beginnst dann fröhlich (wobei du auf Rasterzeile "12" bist) die Zeilen 0 - 12 zu updaten.


    Wenn du danach mitnem IRQ oder ähnlichem bei Rasterzeile "0" vorbeikommst schreibst du die Zwischenspeicher Werte in die eigentlichen Register.


    Du bist also am Screen ganz oben und hast Zeile 0..12 dadurch schon gescrollt. Jetzt kommt es nur noch darauf an Zeile 12..24 in einem Frame zu scrollen.
    Dazu lohnt es sich immer nur 1-x Zeilen mit einem einzelnen Loop zu bearbeiten. Und mehrere solcher Loops zu verwenden. Vielleicht reicht auch ein einzelner..
    Der Rasterstrahl bleibt dann immer vor deinem Updaten des Screen/Colorrams.


    Ich glaub vor "20 Jahren" hatte ich sowas auch bei Turrican gesehen.


    Claus hatte ja auch geschrieben, dass es üblich ist das auf eine halbscreen Weise zu machen.


    Also im Prinzip hast Du so 1,5 Frames Zeit für das Scrollen. Vielleicht ist das bei Dir ja schon so..


    Wollte das bloß nochmal schnell anmerken..

    @ bkn


    Danke für das Feedback und den 1.5 Frames Hinweis. Das ist ja im Grunde das „Hinter dem Strahl bleiben“ wovon Claus spricht. Den Hintergrund nehme ich wahrscheinlich sogar für das spätere Intro wenn mir nichts besseres einfällt.


    Ich bin eigentlich überhaupt kein Rasterstrahl Fan und beherrsche schlecht den Überblick über Zyklus-Verbrauch im Verhältnis zur Strahlposition. Aber wenn man den C64 mag muss man da durch.

    Es gibt noch eine weitere Möglichkeit, die ohne Raster-IRQ oder sonstige Tricks auskommt. Das ganze ist dazu noch sehr einfach umzusetzen, da der Bildschirmspeicher nicht wie üblich umkopiert werden muss. Kurz gesagt, in den Bildschirmspeicher werden einfach die Level/Grafikdaten (bei Hardscroll) kopiert.


    Vorteile:
    1. Das kopieren der Daten erfolgt immer von oben nach unten.
    2. Mit den Zeiger auf die Leveldaten wird die Hardscrollrichtung bestimmt.
    3. Es reicht eine Speedcode-Routinen für alle acht Richtungen.
    4. NTSC/PAL/DREAN/SCPU/VSP-Bug/DTV kompatible.
    5. Keine Begrenzung beim Scrollspeed.


    Nachteile:
    1. Sehr wenig Rechenzeit übrig.
    2. Nur mit Zeichen = Farbe noch sinnvoll.
    3. Bei NTSC fast keine Rechenzeit übrig.


    Abhilfe:
    Mit Doublebuffer ist das ganze natürlich deutlich entspannter.

    Meinst Du, dass man im RAM einfach die Daten so vorliegen hat wie sie auf den Bildschirm sollen? Und man folglich nicht aus dem Screen-RAM, sondern aus RAM außerhalb des Bildschirms kopiert? Wenn ja, fällt mir ein weiterer Nachteil ein: die Daten so zu speichern braucht viel Platz, denn Tricks zur Reduktion wie Tilemaps etc. sind nicht möglich.

    Zitat von Claus

    Meinst Du, dass man im RAM einfach die Daten so vorliegen hat wie sie auf den Bildschirm sollen? Und man folglich nicht aus dem Screen-RAM, sondern aus RAM außerhalb des Bildschirms kopiert? Wenn ja, fällt mir ein weiterer Nachteil ein: die Daten so zu speichern braucht viel Platz, denn Tricks zur Reduktion wie Tilemaps etc. sind nicht möglich.


    Giana SIsters und Katakis machen das auch so. Dort werden die Level jeweils vollständig entpackt. Siehe auch: Scrolling Workshop

    Ah, richtig. Wenn man nur in eine Richtung (bzw. auch die Gegenrichtung) scrollt, kann man natürlich den Level aus sich wiederholenden Segmenten zusammensetzen und so Speicher sparen. Hm, eventuell auch bei 2d-Scrolling. Interessant, habe ich gar nicht bedacht . Aber die Segmente müssen groß sein, sonst wird der Rechenaufwand wohl irgendwann zu groß (4x4 Tiles wird man kaum mit 50Hz bildschirmfüllend darstellen können).

    Es gibt noch einen ungewöhnliche Trick, der einen doppelt soviel Zeit zum kopieren verschafft. Der Trick besteht darin nur mit 25Hz zu scrollen, damit es nicht ruckelt wird jedes 2te Frame die Bildschirmdarstellung ausgeschaltet. Das Scrolling wird dadurch doppelt so langsam, da das ganze flimmert kann man es nur bedingt einsetzen, für Credits/Demos oder so.

    Hallo,


    danke für die weiteren nützlichen Hinweise und Tips.


    Ich habe jetzt mal einen Vertikalscroller versucht, und zwar als "scrollbaren Brief" inkl. ColorRAM.
    Das Programm startet direkt per Basic-Zeile, lässt sich also starten per Drag 'n Drop in VICE.


    Die Steuerung ist wie bei der Vorgänger-Demo: Feuertaste stoppt den Scroll. Hoch / Runter = Richtungswechsel. Erst wenn man wieder Feuer gedrückt hat kann man die Richtung wechseln.


    Jetzt muss ich schauen, dass ich das enger und kleiner kriege und lauffähig, auch wenn ein regulärer Raster IRQ Musik abspielen will. Je nachdem wieviel Platz dann noch für Logik ist, kann man ein Spiel oder ein Intro um die Scroll-Routine machen. Ich denke um so Themen wie "25Hz Scrolling" werde ich wohl auf kurz oder lang nicht drum herum kommen wenn das ColorRAM weiterhin stets mitkopiert werden muss und da noch ein paar mehr Sachen am Schirm passieren sollen.

    Für alle die es interessiert:


    Hier


    https://csdb.dk/release/?id=177613


    ist das Ergebnis der Scroll-Experimente als fertiges Intro zu sehen.
    Kaum waren Sprites da, hat sich schon wieder das Timing verändert. Es hat gereicht, dass sie eingeschaltet waren ohne bewegt zu werden.
    Ab und zu glitcht es daher in der obersten Bildchirmzeile beim Aufwärtsscrollen. Aber ohne die Sprites fehlt der Pep.

    Zitat von Bytebreaker

    Es hat gereicht, dass sie eingeschaltet waren ohne bewegt zu werden.

    Für weitere Hintergründe: https://bumbershootsoft.wordpr…raster-timing-on-the-c64/ ;)


    Sehr schön! Den Glitch kriegst Du noch gefixt, da bin ich sicher! :thumbup: