Bisher nutzen meine Games ja überhaupt kein scrolling. Ich möchte mich aber nun mal langsam damit befassen. Mir fehlt da aber so ein bisschen der Ansatz. Klar den Bildschirm scrollen mache ich mittels CRTC-Registern und muss dann das was ich "rausgescrollt" habe neu zeichnen. Es gibt ja auch beispiele, wie man den Bildschirm scrollt. Pixelgenaues scrolling ist dann ja scheinbar deutlich komplizierter.
Bei all den Beispielen fehlt mir aber irgendwie der Zusammenhang. Es gibt beispiel für Hardware-Scrolling, es gibt beispiele für screen-splitting aber es gibt nie ein Beispiel, wie man das alles zusammenpackt zu einer Spieleengine.
Muss man pixelgenau scrollen damit es gut aussieht ? Wie würde man hardwarescrolling mit einem statischen Bereich kombinieren ? Und vor allem, wie synchronisiert man das ganze mit seiner Gameengine ? Muss man einen Doublebuffer nehmen (dann muss man ja 2 mal zeichnen und scrollen)? Wenn man dann overscan benutzt, wäre der speicher ja schon total voll. Was für eine Sprite-Routine nimmt man ? Masked Sprites ? Sprites mit Ink 0 als Transparenz oder welche ?
Alles in allem fehlt mir irgendwie der Einstig/Ansatz wie ich am besten vorgehe aber dann auch zu einem vernünftigen Ergebnis komme.
Je nachdem was für weitere Antworten kommen, würde ich an Deiner Stelle eins der vielen CPC Listingsheftchen durchsuchen wo in Spiel mit Scrolling drin ist. Dieses dann Abtippen (DSK hier ins Forum stellen) und dann durch einen Disassembler jagen.
Die Listings haben den Vorteil das sie recht klein sind und man da noch einigermaßen den Überblick im Disassembler behalten kann.
CPC Magazin 6/7'92 Seite 22 + 36
CPC Magazin 4/89 Seite 63
CPC Magazin 2/87 Seite 154
CPC Magazin 11/86 Seite 106
Das sind jetzt super viel Fragen kurz vor dem Mittagessen, also erst mal ganz kurz:
Hardwarescrolling:
In Y (vertikal) kann man pixelweise (d.h. rasterzeilenweise) scrollen
In X (horizontal) kann man byteweise (d.h. zwei MODE 0 Pixel) scrollen
Solange man jeden FRAME scrollt ist es egal wie 'weit' man scrollt, dann wenn es immer der gleiche Abstand ist, dann ist das butterweich flüssig.
Overscan ist möglich, kostet 32 KB des Hauptspeichers und erfordert 50 fps Scrolling um gut aus zu sehen. In dem Fall muss alles seher präzise getimed sein.
Man kann natürlich aus per Software scrollen, das ist dann super laaaaaaaaaaaaaaaaaangsam.
Fang einfach mal ein mit Scrolling, und kümmer Dich später um Käse wie Screen Split etc. :)
Danke für Eure Hinweise.
Vor allem der Artikel von EGS in der CPCAI 6/7 92 war klasse. Der hat mich direkt dazu animiert mit Rastern zu spielen :zunge0020:. Übrigens als ich mit der Databox zu dem Heft rumgespielt habe, ist mir folgendes aufgefallen: Da ist ein Demo drauf um Werbung für den Soundtrakker zu machen und diese Werbung nutzt horizontale und vertikale Splitraster. Die wird auf meinem WinAPE korrekt angezeigt, auf dem JavaCPC wird das Sprite in der Mitte falsch angezeigt und alle Raster fehlen.
Back to topic: (Ich schreibe jetzt einfach was, so wie ich das verstanden habe, wenn was nicht stimmt, bitte korrigieren)
Raster basieren ja darauf, dass man in der Austastlücke, bevor das Raster gezeichnet wird, die CRTC umprogrammiert. Also z.b. andere Farbe, anderer Mode oder wir nehmen jetzt den Rest des Bildschims von woanders. Letzteres wäre ja auch die Möglichkeit ein scrollendes Spielfeld und ein nicht-scrollendes Anzeigefeld zu haben. Sinvoll auf einem CPC-TOS wäre ein Splitraster ja wahrescheinlich nur an einer der 6-IRQ-Positionen innerhalb des Bildaufbaus, oder ? Kann man irgendwie auch Positionen dazwischen erreichen, ohne dann per exaktem Timing darauf zu warten ?
Konkrete Frage: Was nimmt man bei einem scrollenden Bildschirm am besten für eine Spriteroutine und brauche ich für gutes Aussehen einen Doublebuffer ? Ein Doublebuffer hat ja auch diverse Nachteile: Doppeltes RAM, zweimal Zeichnen, umschalten. Eine Überlegung wäre ja auch MODE 0 zu nehmen und dann "MODE 4" zu machen. Dann hätte man keinen Doublebuffer nötig aber nur wenige Farben....
Beim Doppelpuffer muss man zwar in zwei Bildschirme zeichnen, aber nur halb so oft, also der Aufwand bleibt der selbe. Doppelpuffer sind nicht nötig, wenn man sehr präzises Timing verwendet und z.B. Sprites dann bewegt, wenn sie gerade nicht vom Elektronenstrahl gezeichnet werden. Eine simple Unterteilung wäre oben oder unten, und dann jeweils im anderem zeitlichen Teil des Bildaufbaus das Sprite zeichnen.
Beim CPC sind die sechs Interrupts das präziseste was Du haben kannst, aber:
- Der Plus hat einen Rasterzeilen-Interrupt
- Die PlayCity hat einen Rasterzeilen-Interrupt-ähnlichen NMI Generator.
Sprite-Routinen soltlest Du Dir immer individuell anpassen.
Zum Thema Untergrund: Es gibt schnelleres als Rasterzeile, per Resterzeile zu zeichnen (dann +&800 HEX ist eine 16 Bit Addition. Statt dessen kannst Du auch mit RES und SET die Adresse - hier das High-Byte der Video-RAM Adresse - anpassen).
Ich will mich halt nicht in eine Sackgasse begeben, deshalb noch ein paar Fragen:
1) Mein späteres Ziel wäre ja oben ein scrollender Bereich, unten ein fester Anzeigebereich. Kann ich dann trotzdem das Splitting erst einmal komplett ignorieren oder muss ich da was berücksichtigen ?
2) Es gibt ja beim scrollen "problematische Bereiche" wenn man dann Sprites zeichnen will (. Sollte ich den CRTC so konfigurieren, dass ich diese Bereiche am Rand habe und wenn ja, kann man das für horizontal und vertikal kombinieren ? (Ich will in beide Richtungen scrollen).
Naja, für einen festen und einen scrollenden Bereich, da wäre es am besten mit zwei verschiedenen Bildschirmspeichern zu arbeiten. Ansonsten: Ausprobieren! Macht am meisten Spass :) Kannst ja mal Dummy-Grafiken einsetzen um deine Scrolling-Routinen zu testen.
Allerdings: Versuche mal mit 2 oder 4, anstatt 8 Rasterzeilen pro Zeichenzeile zu arbeiten, dann dann musst Du beim Vertikal-Scrolling weniger RAM kopieren. Je mehr Du scrollst, desto mehr Bildschirmrand musst Du beschreiben, das kann eng werden wenn dann auch noch Sprites bewegt werden sollen. Lieber mal testen.
Damit kannst du alles machen:
http://ccz80pp.webcindario.com/ccz80pp-en.html
Hat 99 Sprite mit Pixelcollision. Text und Grafik/Sprite stören sich nicht gegenseitig
Kannst den Sprite Grenzen zuweisen und kannst da dann deinen Text Printen.
Mal testen .
Vielleicht kann man das mal hier als Thema nehmen dieses CCz80++
Ich benutze den MIST-FPGA mit dem CPC-Core :
http://lotharek.pl/product.php?pid=96
Arbeitet mit 576 KB, kann aber leider nur CPM 2.2 als zusatz.
Gruss
Gruss
http://www.symbos.de/ läuft auch auf den MIST-FPGA.
Wenn schon offtopic, dann richtig... ;)
Schon mal probiert, ob www.FutureOS.de (http://www.futureos.de) daruf läuft?
FutureOs läuft auch drauf.
Mir gefällt es nicht so.
Wer von den 6 echten Programmierer in Deutschland hat das denn drauf?
Der CPC wacht zur Zeit nicht aus dem Winterschlaf hier in Deutschland auf, schade.
Gruss
Scolling ist beim CPC als Textklötzchen am besten und einfachsten.
Feinscrolling ist zum Zähneausbeissen für uns , außer wenn du einen CPC+ hast.
Du kannst alle Forum durchschauen für den CPC , Sprite/Scolling zu programmieren sind tabu im Userbereich. Einige haben zwar mal angefangen damit...geht aber nicht weiter.
Ich habe es so gemacht, wenn ich einen Randbereich erreicht habe, habe ich auf den anderen Screen $4000-$7fff geschaltet wo die neue Scene dann bereits gezeichnet war. Macht einen netten Eindruck.
Ich spiele mit den CCz80++. Die dafür entwickelte Spriteengine ist Super.
Alle Programme werden je nach Wahl als Bin angelegt oder ASM zum internen nachbessern falls nötig oder mal aus Neugierde anschauen. Man kann auch den Ladebereich selber festlegen.
Gruss
TFM : Es laufen alle ROMS auf dem MIST-FPGA. Bis zu 128 ROMS gleichzeitig kann man dort reinsetzen bzw verteilen die der CPC-Core dann ansprechen kann mit |....
Gruss
Danke für die Infos! Gut zu wissen. :)
Ich hab jetzt einen Hardwarescroller incl. Rupture und Splitraster am laufen. Wenn ich den scroller mit 50 HZ neu zeichne ist der, wie TFM schon sagte, butterweich. Aber der ist eigentlich zu schnell. Wenn ich nur jeden 2 frame scrolle, ruckelts aber. Hat man irgendwie ne Chance das auch mit 25 Hz hinzubekommen ?
Quote from: Shining on 27. April 2017, 21:55:06
Ich hab jetzt einen Hardwarescroller incl. Rupture und Splitraster am laufen. Wenn ich den scroller mit 50 HZ neu zeichne ist der, wie TFM schon sagte, butterweich. Aber der ist eigentlich zu schnell. Wenn ich nur jeden 2 frame scrolle, ruckelts aber. Hat man irgendwie ne Chance das auch mit 25 Hz hinzubekommen ?
Jedes zweite Frame sind doch bei 50 Hz eigentlich 25 Hz oder? :-\
Was passiert denn, wenn Du es nur halb so weit scrollst? (Ist vermutlich nicht möglich, aber dann doppelte Breite des Textes verwenden?)
Hab mich vielleicht nicht gut genug ausgedrückt, mal etwas genauer:
Ich mache eine Laufschrift ( von rechts nach links) in Mode 1 und nutze zum Scrollen nur die Register 12 und 13 -> 8 Pixel in Mode 1.
Wenn ich jetzt nach jedem FrameFlyback (also 50HZ) 8 Pixel weiterscrolle, dann ist alles butterweich. Wenn ich nur jeden 2. Frame weiterscrolle (und natürlich auch nur dann weiterzeichne) dann ruckelt das total.
Ich habe mich jetzt mal eingelesen und man könnte, soweit ich das gelesen habe, das Scrolling durch die Nutzung von Register 3 auf 4 Pixel verkleinern. Dann wäre ich ja halb so schnell. Da steht aber bei, das es dann von Monitor/Anzeigegerät abhängt, ob das butterweich ist oder nicht. Bzw. das man dann je nach Anzeigegerät andere Werte nehmen muss. Ich will aber ja was programmieren was bestenfalls bei allen funktioniert.
Naja wenn es nicht anders geht, bzw. wenn ich keine Lösung finde, dann muss man beim Lesen der Laufschrift eben schnell sein ;).