Fragen zu scrolling etc.

[Shining]

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.

[oobdoo]

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.

[oobdoo]

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

[TFM]

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. 

[Shining]

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  . Ü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....

[TFM]

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).

[Shining]

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).

[TFM]

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.

[cpcman]

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

[cpcman]

http://www.symbos.de/ läuft auch auf den MIST-FPGA.

[TFM]

Wenn schon offtopic, dann richtig... 

Schon mal probiert, ob www.FutureOS.de daruf läuft?

[cpcman]

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

[cpcman]

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

[cpcman]

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

[TFM]

Danke für die Infos! Gut zu wissen.