Zitat:

---

Original von dante:

Zitat:

---

Original von eye-BORG:
Nein, tile-basierende Games haben immer den Screen geswapt und komplett neu gezeichnet.

---

---

Zitat:

---

Für 4-Wege-Scrolling kann man mehr nehmen, um Richtungswechsel abzufangen ohne plötzlichen Anstieg der Rechenzeit, also 2 Tile-Reihen/Spalten extra pro Richtung, bei obigen Beispiel dann 14x12 Tiles.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von platon42:
Heh, das wäre ja lustig und ziemlich doof -- das waren dann solche Games, die nur 25fps hatten...

---

Zitat:

---

Bei 8-Wege-Scrolling kann man einen minimal größerer Screen verwenden als der sichtbare, man braucht also *nicht* einen vier mal größeren Screen und dann horizontal und vertikal vierfach Updaten.

---

Hab ich sowas geschrieben? Oder beziehst du dich auf nen anderes Posting?

Ich beschrieb nur, das man beiderseits der Bitmap einen Buffer braucht fürs Scrollen.

Egal. Bis Fussball dauerts ja noch ein wenig, ich mach jetzt meinen Amiga an und guck mal, ob ich nen alten Source find.



[ Dieser Beitrag wurde von dante am 20.06.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von platon42:

Zitat:

---

Original von eye-BORG:
Nein, tile-basierende Games haben immer den Screen geswapt und komplett neu gezeichnet.

---

Heh, das wäre ja lustig und ziemlich doof -- das waren dann solche Games, die nur 25fps hatten...

---

Nein, im Gegenteil

Ist natürlich bissi sehr verallgemeinert mit dem "komplett neuzeichnen", aber im Grunde war und ists schon so. Ein vernünftig geproggtes Tile-Game arbeitet nur auf veränderte Bereiche, das bedeutet, daß nur veränderte oder (von Sprites) überschriebene Tiles neu gezeichnet werden, Kopieroperationen werden mit dem Blitter im Backbuffer durchgeführt. Das geht bedeutend fixer als man manchmal glaubt. Bei AsteroidsTR wird im Scroll-Zyklus der komplette Bildinhalt mit dem Blitter umkopiert, das erreicht locker 75 Frames auf ner CVPPC...

Zitat:

---

Bei 8-Wege-Scrolling kann man einen minimal größerer Screen verwenden als der sichtbare, man braucht also *nicht* einen vier mal größeren Screen und dann horizontal und vertikal vierfach Updaten. Der Trick war, dass man einfach per Copper den Screen vertikal gewrappt hat: Sprich, wenn man nach unten gescrollt hat, und man nun eigentlich Speicher von "weiter unten" anzeigen müsste, wird an der Bildschirmzeile, an der der Speicher zuende ist der Anfang des Bildschirmspeichers wieder angezeigt. Horizontales Scrolling kann man dann auch beliebig in beide Richtungen machen, ohne dass man irgendwie irgendwas groß kopieren müsste.

---

Ich hoffe mal ich stelle jetzt keine dumme Frage:

Ist das nicht auch nur eine Art, den kompletten Bildspeicher mit dem Blitter zu kopieren? Ich meine, das klingt für mich so, als würde der Blit letztendlich mit Hilfe des Coppers durchgeführt, statt das Ganze vom Programm selbst aus zu steuern. Liege ich da richtig? Ich mein, man kann ja das Chipram schlecht "umkrempeln", oder?


Grüße

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von dante:

Zitat:

---

Bei 8-Wege-Scrolling kann man einen minimal größerer Screen verwenden als der sichtbare, man braucht also *nicht* einen vier mal größeren Screen und dann horizontal und vertikal vierfach Updaten.

---

Hab ich sowas geschrieben? Oder beziehst du dich auf nen anderes Posting?

---

Ne, ich wollte es nur mal erwähnen

Zitat:

---

Ich beschrieb nur, das man beiderseits der Bitmap einen Buffer braucht fürs Scrollen.

---

Falls Du meintest, man braucht einen doppelt so breiten (für horizontales Scrolling) Screen, dann müsste ich Dir hier eben widersprechen (nein, geht jetzt nicht um Double Buffering, ist nochmal ein anderer Schuh). Aber das mit dem Puffer stimmt, wenn Du einen kleinen "Zeichenstrip" meinst

--
--
Best Regards

Chris Hodges

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Ist natürlich bissi sehr verallgemeinert mit dem "komplett neuzeichnen", aber im Grunde war und ists schon so. Ein vernünftig geproggtes Tile-Game arbeitet nur auf veränderte Bereiche, das bedeutet, daß nur veränderte oder (von Sprites) überschriebene Tiles neu gezeichnet werden,

---

Na, das ist schon klar, aber wir sprachen ja von komplett...

Zitat:

---

Kopieroperationen werden mit dem Blitter im Backbuffer durchgeführt. Das geht bedeutend fixer als man manchmal glaubt. Bei AsteroidsTR wird im Scroll-Zyklus der komplette Bildinhalt mit dem Blitter umkopiert, das erreicht locker 75 Frames auf ner CVPPC...

---

Naja, ich dachte wir reden hier von guter alter Hardwareprogrammierung am Amiga-Chipset -- da kannst Du von solchen Raten nur träumen

Zitat:

---

Ist das nicht auch nur eine Art, den kompletten Bildspeicher mit dem Blitter zu kopieren? Ich meine, das klingt für mich so, als würde der Blit letztendlich mit Hilfe des Coppers durchgeführt, statt das Ganze vom Programm selbst aus zu steuern. Liege ich da richtig? Ich mein, man kann ja das Chipram schlecht "umkrempeln", oder?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von platon42:

Nein, es findet eben kein Kopieren statt (außer eben für das Zeichnen der reingescrollten Randbereiche), und tatsächlich wird für die Displayhardware das Chipram "virtuell" umgekrempelt, weil der Copper ja an jeder beliebigen Bildschirmposition Register ändern kann -- wie bei Turrican z.B. die vier Bitplanepointer, um an z.B. in Zeile 172 den Bildschirmspeicher wieder von oben anfangen zu lassen.

---

Ah ja Wie hat man sich das technisch vorzustellen? Ich hab da im Moment keine konkrete Vorstellung davon, wie der Copper das dann handhabt. Irgendwie müssen die Bilddaten, die sich durch das Scrolling ja verändert haben, wieder an eine bestimmte Startposition für das Scrolling gebracht werden um neu Zeichnen zu können. Wie macht der das konkret, ohne die Bilddaten wieder an die Scrollposition 0 zu kopieren? Im Moment kann ich mir das nur so vorstellen, daß das übergroße Display technisch gesehen durch das gesamte Chipram "durchwandert". Wäre nett wenn Du mir das mal erläutern könntest, wahlweise auch per Mehl, das wäre nämlich prima Futter für meine Artikelreihe. Auch mal etwas für die Nicht-GraKa-Besitzer

Grüße

[ - Antworten - Zitieren - Direktlink - ]

@whose, mal vereinfacht beschrieben: du hast bei Ocs/Ecs 6, bei Aga 8 Register, die Pointer auf einzelne Bitplanes enthalten, und diese Pointer kann man natürlich beliebig ändern, um innerhalb des Chiprams einen Speicherbereich als Bild anzuzeigen. Darauf basiert letztendlich auch diese Scrolling-Geschichte: man hat 2 (oder beliebig mehr) Bitmaps bestehend aus soviel Bitplanes wie gebraucht werden. Eine Bitmap davon wird angezeigt, in einen der anderen nicht sichtbaren Bereiche wird rein gerendert, und wenn man damit fertig ist, werden einfach die oben erwähnten Pointer auf diesen Bereich geändert, und voila - dieser Bereich wird angezeigt. Nichts mit Blitten oder so
Das ist halt "intelligentes" Hardwaredesign und einer der Gründe, warum der Amiga einige Jahre lang erheblichen Vorsprung vor den Brute Force-Methoden (z.B. für simples Doublebuffering Megabyteweise Grafikdaten sinnlos herumschaufeln) der PC's hatte.

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Ah ja Wie hat man sich das technisch vorzustellen? Ich hab da im Moment keine konkrete Vorstellung davon, wie der Copper das dann handhabt. Irgendwie müssen die Bilddaten, die sich durch das Scrolling ja verändert haben, wieder an eine bestimmte Startposition für das Scrolling gebracht werden um neu Zeichnen zu können. Wie macht der das konkret, ohne die Bilddaten wieder an die Scrollposition 0 zu kopieren?

---

Zitat:

---

Im Moment kann ich mir das nur so vorstellen, daß das übergroße Display technisch gesehen durch das gesamte Chipram "durchwandert".

---

Zitat:

---

Wäre nett wenn Du mir das mal erläutern könntest, wahlweise auch per Mehl, das wäre nämlich prima Futter für meine Artikelreihe. Auch mal etwas für die Nicht-GraKa-Besitzer

---

Ein Bild sagt mehr als tausend Worte. Heißt es.

Gegeben sei folgendes Tile-Level:

Bild: http://www.platon42.de/gfx/8wegelevel.png


Am Anfang sehen wir folgenden Ausschnitt:

Bild: http://www.platon42.de/gfx/8wegescroll1.png


Nun scrollen wir etwas nach rechts:

Bild: http://www.platon42.de/gfx/8wegescroll2.png


Am rechten Rand wird neu gezeichnet und zwar teilweise in den Speicherbereich, der vorher am linken Rand war -- das macht aber nichts, weil der ja im nächsten Frame nicht mehr sichtbar ist (wenn man richtig viel scrollt, sollte man auch double buffering einsetzen, damit man die Zeichenoperationen, die dann ggf. tatsächlich im sichtbaren Bereich passieren, nicht sieht). Soweit alles noch trivial.

Nun scrollen wir etwas nach oben. Da wir aber oben keinen Speicher mehr haben, müssen wir de facto im unteren Bereich zeichnen und dem Copper nach ein paar Zeilen sagen, dass er wieder von oben anfangen soll:

Bild: http://www.platon42.de/gfx/8wegescroll3.png


Und zur Verdeutlichung nochmal schnell, so sieht das ganze im Speicher in etwa linear aus:

Bild: http://www.platon42.de/gfx/8wegescroll4.png


Hab auch noch mal im Internet gesucht, ob noch jemand eine gute Erklärung dafür hat, und bin auf folgende Seite gestoßen. Sourcecode ist wohl auch dabei

http://www.mds.mdh.se/~dat95jed/prog/?prog68000.htm


Die Webseite ist insgesamt ziemlich cool muss ich sagen. Von horizontalem Zooming mittels des Shift-Registers hatte ich noch nie gehört -- das ist zugegebenermaßen recht genial
--
--
Best Regards

Chris Hodges

[ - Antworten - Zitieren - Direktlink - ]

Mal so nebenbei:

@Chris

Hab heute mein AmosPro wieder ans Laufen gebracht und deine Amcaf Extension installiert. Wollt nur mal (sehr verspätet ) mein Lob dafür ausprechen, meinen Respekt hast du

mfg
Björn
--
visit http://www.ac-de.de

[ Dieser Beitrag wurde von Bjoern am 22.06.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von platon42:
...

---

Ohne Worte!

Danke Dir für die enorm detailreiche Erläuterung. Nu hab ichs begriffen. Die Zeichnerei spielt sich immer in einem kleinen Bereich des Chiprams ab, nur die Ausgangsposition des Scrollings wird jedesmal verschoeben, so daß das Bild andauern an anderer Position neu entsteht. Je nach dem, wo man gerade mit dem Scrolling ist. Genial! Danke Dir auch für den Link. Diese Technik werde ich als positives Beispiel für die Möglichkeiten der Amiga-Customchips anführen. Damit auch die Jünger der "Scrolling durch brutale Busgeschwindigkeit"-Fraktion einmal sehen, was man mit einem lahmen Systembus alles erreichen kann wenn man das Drumherum genial entwirft.

Grüße

[ - Antworten - Zitieren - Direktlink - ]