neue Spiele Programmieren Part #2


  • Innovating
  • 2691 Aufrufe 25 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • neue Spiele Programmieren Part #2

    Hallo Leute,

    ich habe meinen Gamescroller nun soweit mit rechts/links Bewegung fertig, das ganze habe ich via Hardcopy + soft gelöst .... nun möchte ich noch das Farbram mit kopieren, Rasterzeit hätte ich noch von $4a-$f2 frei (Screenbereich) frei ....

    meine Idee wäre, nur die Zeilen vom Farbram Scrollen (abfrage durch zeichen), die auch benutzt werden, wäre dann etwas unflexibel was das Level design angeht (z.B max. 5 Farbscroller/screen habe) .... mit einer dma-delay Variante (screen+farb komplett) hätte ich Probleme mit meiner Kollisions Routine, da ich die Sprite Position auf x/y Screen umrechne und vergleiche ....

    würde mich über konstruktive Lösungsvorschläge (prinzip)freuen ...

    gruß Inno

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Innovating ()

  • Wenn deine Kopierschleife dem Rasterstrahl hinterherläuft und es auch sonst dein Timing nicht durcheinanderbringt, dann darf das Kopieren auch mehr als einen Screen an Rasterzeit verbraten, würde also im Prinzip ohne schwere Gedanken gehen.

    Was meinst Du mit Zeilen, die auch benutzt werden? Dein Scroller ist z.B. 22 Zeilen hoch, aber nur 5 davon sind bunt? Ansonsten würde mir zum Sparen von Rasterzeit erstmal einfallen, die Level aus Kacheln von z.B. 5*y aufzubauen und je Kachelzeile nur eine Farbe zu erlauben. Beim Scrollen muß dann nur eine Kante neu gezeichnet werden, die übrigen 4 Zeichen der Kachelzeile hätten schon die korrekte Farbe, und man muß nur eine "grobe" Scrollposition mitführen, braucht man nichtmal einen Zugriff auf den Kachelspeicher für. Bei nur einer Farbe je Kachel spart man noch mehr, aber wozu?

    Noch kompliziertere Sachen lohnen sich wohl nur, wenn wirklich sehr wenig Zeichen umgefärbt werden müssen
    Vollmond war gestern!
  • Es besteht auch die Möglichkeit, daß Scrolling über mehrere Frames zu verteilen, wenn man denn weiß in welche Richtung demnächst gescrollt wird. Dank $D016 und $D011 muß man ja erst ab 8 Pixel Bytes verschieben, so daß man normalerweise 2-4 Frames Zeit hat. Man scrollt also erstmal die Zeichenmatrix im Hintergrund und erst danach das FarbRAM. Diese Technik wird auch von Turrican verwendet (deswegen folgt das Scrolling dort nicht exakt der Spielfigur, sondern scrollt immer in eine der 8 "einfachen" Richtungen).

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Fröhn ()

  • von hoogo : Wenn deine Kopierschleife dem Rasterstrahl hinterherläuft und es auch sonst dein Timing nicht durcheinanderbringt, dann darf das Kopieren auch mehr als einen Screen an Rasterzeit verbraten, würde also im Prinzip ohne schwere Gedanken gehen.

    Was meinst Du mit Zeilen, die auch benutzt werden? Dein Scroller ist z.B. 22 Zeilen hoch, aber nur 5 davon sind bunt?

    @hoogo : genau das meinte ich ... aber das war nur ein Gedanke den habe ich auch schon wider verworfen, da ich ja links/rechts scrolle, müßten die ja immer an der selben Stelle sein, auch doof irgendwie :) ...
    ... zum Rasterstrahl hinterher, mein Screen ist halt gesplittet, da ich den oberen Bereich bis $4a mit einem Koala Bild fülle (zwecks Status Anzeige), am besten wäre natürlich das jede Zeile (von den 20) mit jeweils einem Farbblock gesetzt werden kann, also im Prinzip nochmal so ein Hardcopy für das Farbram das das dann mitscrollt, denke das wird dann nicht hinhauen, mit der Rasterzeit, muß das mit mehr RT Screens mal ausprobieren . ...

    @fröhn : werde das auch mal ausprobieren, während des softscrollings ...

    danke schonmal für die Antworten ...

    gruß Inno
  • Jemand hatte letztes Jahr in Lemon64 ein nette Konzept für ein Scrolling vorgestellt, in dem er per VIC Trick die Charlines verdoppelte und somit 8x16 Pixel Tiles erhielt. So braucht man nur die hälfte an Videomatrix umherschieben. Ist zwar auch etwas knifflig, aber eine gute Idee.

    Hier mal ein Link zu dem Thread!

    @Innovating: Wenn man Colorramscrolling macht, nutzt man bei Spielen eigentlich immer DoubleBuffer, wenns vernünftig werden soll.

    Noch ein Tipp:
    Achte in deinen Kopierschleifen für den Hardscroll darauf, das du keinen zusätzlichen Taktzyklus durch eines Pageüberschritts verbratest. Also beispielsweise:

    ldx #$50
    lda $04ef,x
    sta $04f0,x

    Hier braucht lda & sta jeweils einen Taktzyklus länger. Das summiert sich ganz schnell auf ein paar Rasterlines. In meinem Scrollingsbeispiel das ich vor einer weile mal hochgeladen hab, hab ich das auch umgangen.

    Also, sobald man mit einen indexregister in die nächste Page Adressiert, brauchts ein Taktzyklus länger.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von biguser ()

  • Original von biguser
    Jemand hatte letztes Jahr in Lemon64 ein nette Konzept für ein Scrolling vorgestellt, in dem er per VIC Trick die Charlines verdoppelte und somit 8x16 Pixel Tiles erhielt. So braucht man nur die hälfte an Videomatrix umherschieben. Ist zwar auch etwas knifflig, aber eine gute Idee.

    8x15 wäre sinnvoller, das geht dann wenigstens auch :D


    @Innovating: Wenn man Colorramscrolling macht, nutzt man bei Spielen eigentlich immer DoubleBuffer, wenns vernünftig werden soll.

    Oder nen kleinen Scrollbereich. Siehe "The Last V8" oder "Red Max".
  • @biguser : ok, danke für den hint mit dem Pageüberschritt :-), da kann ich dann noch etwas rausholen ...
    .. zum Thema double buffer

    Im Moment sieht es so aus
    1.softzähler, lda $d016,and#$07, eor#$c0,sta $d016, inc$d016
    2.Hardcopy (Schleifenbetrieb) (alle 20 Zeilen durch lda $0401,x Sta$0400,x)
    3. 1 Zeichen/Zeile (also insg.20) wird reinkopiert jeweils rechts oder links - richtung

    an welcher Stelle und wie sollte das mit dem double buffern aussehen, über $dd00 Umschaltung ?


    gruß Inno

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Innovating ()

  • Original von Innovating
    Im Moment sieht es so aus
    1.softzähler, lda $d016,and#$07, eor#$c0,sta $d016, inc$d016


    ehm.... diesen code machst du aber hoffentlich nicht direkt hintereinander...
    denn das gibt böses border geflacker... (da ja nach 07 -> 08 , und nicht 00 verwendet wird)
    ... und der eor#c0 macht ja keinen sinn....

    warum nicht:

    lda $d016
    clc
    adc#0x (wert zwischen 1 und 8)
    and #07
    (und wenn du multicolor willst noch ein: ora #10)
    sta $d016

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Roland ()

  • Muß gar nicht über $dd00 gemacht werden, $d018 (53272) tuts auch.
    Dein Softscrolling arbeitet ja vermutlich im RasterIRQ. Wenn das einmal durchgescrollt hat switcht es den Screen, scrollt das Farbram und setzt ein Flag, daß der nächste Screen aufgebaut weden kann.
    Das Hardscrolling läuft z.B. im Hauptprogramm (oder in Bruchstückchen im IRQ), wartet auf das Flag und hat dann gemütliche 7 Frames Zeit, den gerade unsichtbaren Screen neu zu füllen.

    PS. Dein Softscrolling sieht ein bisschen falsch aus.
    Vollmond war gestern!
  • @Roland : mmm... habe oben "nur" vergessen, das in meinem Scroller noch ein cmp #c7 mit drin habe, und wenn ich den eor auf multicolor setzte dann geht das auch, also macht ja eigentlich die Kombination schon das was ich wollte, ohne geruckel, aber ich weis ja auch von wem der Vorschlag kam, insofern übernehme ich das mal :) ... thx !

    @Hoogo : ok, habe mir das Register noch mal angeschaut, du meinst also über das setzten der Bits 4 - 7 ?

    gruß Inno
  • Ja die wird er meinen.

    Du bleibst quasie in der gleichen Grafikbank (rührst also $dd00) nicht weiter an, ausser beim initialisieren und schaltest zwischen den Screen via $d018 um.

    Ein gute mögliche Speicheraufteilung wäre:
    $c000 - Charset
    $c800 - Screen 1
    $cc00 - Screen 2
    $d000-$fffc0 - Sprites

    Deine Anzeige ist ja bitmap, die würd ich in eine andere Bank Packen um genug Speicher in der Game Grafik Bank frei zu haben. Da musst du dann natürlich via Raster $DD00 umschalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von biguser ()

  • Hallo .. also, bin gerade dabei das mal so umzusetzten wie ihr das Vorgeschlagen habt, wollte nochmals wissen ob das so gemeint war :

    -ein charset (level) für zwei screens, via $d018 nur den Screen umswitchen .. ok

    -sichtbar : screen #1
    -joy li/re Abfrage
    -softscrolling in entsprechende Richtung, !während dessen den gesamten Screen+Farbram in Screen #2 (noch unsichtbar) gemütlich umkopieren.
    -softscrolling ende, Flag set
    -sichtbar : screen #2

    für weitere li/re -moves dann

    -sichtbar : screen #2
    -joy li/re Abfrage
    -softscrolling in entsprechende Richtung, !während dessen den gesamten Screen+Farbram in Screen #1 (jetzt unsichtbar) gemütlich umkopieren.
    -softscrolling ende, Flag set
    -sichtbar : screen #1

    dann wieder von oben ... ?


    gruß Inno

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Innovating ()

  • hi ...

    habe das jetzt mal umgesetzt, und funktioniert nun Pixelweise links/rechts (20 Zeilen) ... habe das erste Ergebnis mal mit drangehängt ... das mit dem Farbram ist nun (sollte) kein Problem mehr sein, da ich genügend RT/Frame habe zum "dazuklatschen" ... beim ersten links move ruckelt das nochmal kurz (anderer offset muss noch rein), ansonnsten geht das schon mal ganz gut, am unteren Rasterbalken sieht man das Umschalten der Bänke, und es wird gemütlich kopiert :) ...

    schonmal besten Dank Inno
    Dateien
    • dbltest1.prg

      (47,62 kB, 23 mal heruntergeladen, zuletzt: )
  • hi inno,
    schon auessert perfekt, hatte auch schonmal ueber die moeglichkeit nachgedacht so zu scrollen, nur habe mich nie so richtig an die umkopierer rangetraut, ich denke das problem ist, warum es ruckelt nicht das kopieren sondern die, lass mich luegen die verengung des bildschirmes um das weiche scrolling einzuleiten, weiss glaube es ist $d011 oder $d016.
    ich glaube du setzt die diese zu setzenden zeiger immer wieder auf anfang und deshalb ruckelt das kurz.
    ist das moeglich, habe mir das jetzt nicht im monitor angeguckt, rate mal so drauf los
  • Hi ...
    ich meinte eigentlich damit, beim allerersten mal LINKS, also wenn der Screen noch steht, dann ruckelt das mal kurz (da bereits kopiert wird, obwohl die Richtung noch unbekannt ist) :) ... bei der Testversion ging es mir erstmal darum das Prinzip umzusetzten mit dem umkopieren und der Bänke switchen, da für mich das völlig neu war, das das auch über $d018 geht (habe das immer über $dd00 gemacht) :) und wichtig ist es für mich, das das auch pixelweise funktioniert, und das tuts schon fast gut ... und bei meiner jetzigen Version ruckelt da nix mehr, habe da nun Sprite Bewegung und Farbram mit integriert, und vorallem schnelleres scrollen ...

    gruß Inno

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Innovating ()

  • also ich braeuchte fuer ein spielchen demnaechst auch einen vollbild scroller, in alle richtungen, mit color ram, leider braeuchte ich ein pixelgenaues scrolling, also ich kann nicht die richtung abschaetzen, habe es noch nicht ausprobiert, aber lese hier sehr aufmerksam mit ... ;)

    eine einschraenkung haette mein scrolling aber, und zwar will ich nur 3 richtungen zu lassen, also oben/links/rechts

    ist es wirklich soooooooooo aufwendig mit double buffer ein scrolling hinzukriegen ?? weia ... :roll:
  • also rechts links scrolling ist mit double buffer hinzubekommen aber von oben nach unten.... also gut double hin und her hier gab es fuer mich immer ein anderes problem denn es ruckelte nicht nur bei mir sondern blinkte und oben links gab es dann immer so komsiche zeichen...
    naja ist schon lange her ;)
    aber bei deinem gewuenschten scrolling brauchst du wohl ein vgsp scrolling, ich hab zwar keine ahnung wie dieses funktioniert aber gesehen habe ich es schon ;-))))))))
  • Also wenn nun gar nicht vorhersagbar ist, welche Hardscrollposition als nächstes gebraucht wird, dann würde ich mit noch mehr Bildschirmen arbeiten, hier 4 Stückern. AUsser dem aktuell angezeigten wären noch 3 für andere Scrollpositionen frei, Hardscrollen dann durch switchen und neuverteilen der Rollen. Wird z.B. nach rechts gescrollt, kann der alte Bildschirm die Rolle des linken übernehmen. FIes beim nach oben scrollen ist, daß das Farbram nicht aus sich selber kopiert werden kann, das muß dann jedesmal von irgendwoher schnell erzeugt werden.
    Vollmond war gestern!