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

letzter Beitrag von sauhund am

double buffering: so geht's :)

    da hier ja schon öfter mal das double buffering / scrolling in alle 4 richtungen usw. thematisiert wurde, und ich so was ja auch mal exemplarisch gemacht hab, habe ich meine double-buff-scroll-routine rausgekramt, dokumentiert und online gestellt:


    http://people.freenet.de/hannenz/sources.htm


    scrollt in alle 4 richtungen anhand joy #2, allerdings ohne Farb-RAM, das müsste man noch extra implementieren und enstorechend weiter optimieren, um Zeit dafür zu schinden.


    ach ja: da ja doch wieder gefragt wird, bevor man das readme liest: start mit SYS 10240

    *exhumier* Leider ist Hannenz Seite ja schon ein paar Jährchen down.


    Hat das zufällig noch jemand - oder eine andere gute Referenz für Double Buffering?


    Ich komme zur Zeit ohne aus - es ist erstaunlich, was man alles innerhalb eines Frames schafft, wenn man mit RAM nur so aast -, aber es ist schon Frickelkram und ich verspreche mir von Double Buffering neben RAM-Gewinn evtl. auch etwas Entspannung in Sachen Timing.

    Zitat von TheRyk

    *exhumier* Leider ist Hannenz Seite ja schon ein paar Jährchen down..

    Wo ist was down?



    people.freenet.de/hannenz/sources.htm ist jetzt http://hannenzwelt.hannenz.de/sources.htm, sonst ändert sich nix :)

    @Anta Ah :) Danke! Geil, ich dachte wirklich Hannenz hätte seine Seite gekillt und sich zurückgezogen.


    @Sauhund: naja, immerhin :o) Z.Zt. muss ich bei allem, was ich noch zusätzlich einfüge, wieder irgendwo an $d012 Splits rumschrauben oder reichlich tricksen, um nicht an der falschen Stelle zu schnell oder generell zu langsam mit gewissen Sachen fertig zu werden.

    das problem bei doublebuffer ist immer.... das du dann diverse routinen die auf den screen schreiben entweder doppelt im speicher halten musst (jeweils eine für jeden buffer), oder eine - warscheinlich langsamere - version implementieren musst die wahlweise den einen oder andren buffer beschreibt. daher klappt das mit dem ram sparen eher selten :)

    Da es ja schon angesprochen wurde: Hat denn jemand einen entsprechend kommentierten 4-way-Scroller mit Farb-RAM-Kopiererei?


    Das Blöde am C64 scrollen ist ja, daß man den generischen Ansatz komplett knicken kann/muß, und ziemlich auf das jeweilige Spiel zuschneidern muß (Tile-basiert, komplett freies Scrolling, etc.)

    @Sauhund: Hmh, that sucks :) Meine derzeitige Lösung kommt zwar ohne Double-Buffering aus, frisst aber schon exorbitant RAM (>10kB X-Scrolling inklusive Farbram). Ich dachte eigentlich nicht daran, das zu verdoppeln, sondern z.T. dynamisch/selbstmodifizierend zu gestalten, um am Ende zumindest nicht signifikant mehr RAM zu vergeuden. Muss mir allerdings Hannenz' Code erstmal reinziehen, womöglich hat der das ganze Rumkopiere längst nicht so speedy/hardcoded lösen müssen dank Double Buffering.


    Endurion: gerade bzgl. Generik sehe ich zur Zeit auch kein Land, sondern fürchte, dass ich das alles schon dann nochmal coden darf, sobald es denn mal um andere Formate, Y-Scrolling oder free scrolling gehen soll.

    Double-Buffering mit Farbram kann man eh nur mit viel Dehnung als solches Bezeichnen, das Scrollen des Farbrams muß halt weiterhin passend zum Röhrenstrahl laufen. Ansonsten überlässt man es halt dem Hauptprogramm, den unsichtbaren Bildschirm auf Verdacht zu scrollen und auf ein Zeichen der IRQ-Routine zu warten, daß wieder ein Puffer mit neuen Daten gefüllt werden darf.


    Und ein wirklich freies 4-Wege-Scrolling mit Double-Buffering düfte unlustig werden, weil man schlechter auf Verdacht festlegen kann, welche Bildschirmposition als nächstes angezeigt werden muß. Da kann ic mir vorstellen, daß das auch schonmal auf ein 9fach-Buffering hinauslaufen kann.

    Zitat von hoogo

    Double-Buffering mit Farbram kann man eh nur mit viel Dehnung als solches Bezeichnen, das Scrollen des Farbrams muß halt weiterhin passend zum Röhrenstrahl laufen.


    Wieder ein Argument für den C128: Der hat (natürlich im C128-Modus) zwei Farbram-Bänke und man kann getrennt für VIC und CPU einstellen auf welche zugegriffen wird ;)


    Zitat

    Und ein wirklich freies 4-Wege-Scrolling mit Double-Buffering düfte unlustig werden, weil man schlechter auf Verdacht festlegen kann, welche Bildschirmposition als nächstes angezeigt werden muß. Da kann ic mir vorstellen, daß das auch schonmal auf ein 9fach-Buffering hinauslaufen kann.


    Wenn man ein zusätzliches Frame Verzögerung zwischen Eingabe des Spielers und Ausgabe des neuen Spielbildschirms akzeptieren kann braucht es kein 9fach-Buffering - die Reaktion auf die Eingabe würde im Prinzip genauso wie ohne Doublebuffer bearbeitet und in ein Bild "umgesetzt" werden, nur wird das erst etwas später angezeigt.

    Zitat

    Wieder ein Argument für den C128: Der hat (natürlich im C128-Modus) zwei Farbram-Bänke und man kann getrennt für VIC und CPU einstellen auf welche zugegriffen wird ;)


    man kann das auch aufm c64 hintricksen indem man die charlines jeweils verdoppelt und mit 2 screens arbeitet. vmtl aber relativ unbrauchbar für ein spiel wegen der ganzen rastersplits :)

    Mit double buffering benötigt man nunmal eine Menge RAM um alle Routinen (Screens kopieren
    und neue Daten aus Tiles lesen und schreiben) unterzubringen. Für ein 8-Wege-Scroll
    braucht man etwas mehr als 4k.
    Wenn man die recht verbreitete Variante wählt, jeweils eine Char-Länge bzw. -Höhe
    am Stück zu scrollen, kann man Rasterzeit in Abhängigkeit von der Scrollgeschwindigkeit
    gewinnen - Je langsamer, desto kleinere Screenhäppchen kann man auf den
    inaktiven Screen kopieren, desto mehr Zeit bleibt pro Frame. Ausgenommen der Frame
    in dem das FarbRAM verschoben werden muss.

    Zitat

    Hä?


    also... es ist ein bischen tricky, aber man kann sich auf diese art einen screenmode bauen mit 24 nutzbaren characterzeilen, doublebuffer für video UND colorram, sowie als nebeneffekt der möglichkeit beides locker in einem frame kopieren zu können (zu den nachteilen weiter unten).


    durch entsprechendes beharken von $d011 kann eine characterzeile doppelt (beliebig oft) dargestellt werden (die details hat HCL irgendwo auf codebase erklärt, ist aber fast so trivial wie FLD). als ersten schritt baut man sich also eine routine welche alle 16 rasterzeilen, sprich jede zweite charline, $d011 beglückt so das am ende die ersten 12 charlines jeweils doppelt zu sehen sind. als zweiten schritt wechselt man alle 8 rasterzeilen, also jede charline, zwischen zwei zeichensätzen hin und her. als ergebnis bekommt man einen charactermode mit 12 zeilen und 16 pixel hohen zeichen. um nun besagten double buffer zu bekommen wird besagte routine einmal für jeden buffer abgelegt, wobei eine davon in den ersten 12 zeilen linecrunching macht so das die erste dargestellte zeile die eigentlich 12te ist. - voila, ein zweiter screen, inklusive colorram. nun kann man durch abwechselndes benutzen dieser beiden routinen den jeweils anderen buffer anzeigen, und man muss dank verdoppelter zeilen nur 12*40*2=960 bytes bewegen um den kompletten screen inklusive colorram zu scrollen - und das geht wiederum locker in einem frame, selbst mit nur wenig ausgerollten kopierschleifen.


    in demos wird diese technik oftmals noch weiter getrieben, und eine characterzeile mehrfach wiederholt wobei alle 8 zeilen ein anderer charset benutzt wird. so kann man relativ grosse grafik inkl. colorram recht fix umher scrollen


    nachteile:
    - alle 8 zeilen ein interrupt nötig welcher timinggenau sein muss. falls mehr als 4 sprites in einer rasterzeile sein sollen ziemlich lästig (ansonsten relativ unstressig, man sollte aber schonmal cycles gezählt haben :))
    - durch das linecrunching oben und den nur 24 nutzbaren zeilen vergleichsweise aufwändiges getrickse nötig um oben und unten eine saubere kante unter denen die sprites beim scrollen verschwinden zu erzeugen
    - durch die verdoppelung der zeilen gilt ein byte video- bzw colorram jeweils für zwei 8x8 grosse grafikblöcke, sprich die grafik muss entsprechend angelegt sein und ist ein wenig eingeschränkter bzgl colorram. (beim benutzen von tiles, speziell beim updaten derselbigen, kann das allerdings auch ein vorteil sein, da weniger daten bewegt werden müssen)
    - der zeichensatz ist doppelt so gross (kann allerdings natürlich auch doppelt so viele grafikdaten fassen)

    Zitat von sauhund

    also... es ist ein bischen tricky [...]

    Ist 'ne coole Sache. Es wird leider auch noch etwas komplizierter, wenn man nach oben und unten scrollen möchte, weil man dann die von Dir beschriebenen Routinen zum Anzeigen der beiden Buffer auch noch mal verdoppeln muss, um jeweils oben nur eine Zeile in "halber Höhe" (d.h. bei Dir dann 8 Pixel hoch) anzuzeigen, denn mit den untersten Bits von $D011 kann man ja nur 8 Pixel soft scrollen.


    Wäre eigentlich noch ein weiterer Nachteil, dass die Routine auf manchen C64 dann absturzgefährdet ist wegen des Linecrunching? Oder treten die ominösen Abstürze nur bei VSP auf? (Wird derzeit auch im CSDb Forum diskutiert.)