amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Amos - lohnt es sich noch? [ - Search - New posts - Register - Login - ]

1 -2- [ - Post reply - ]

2004-06-20, 11:27 h

platon42
Posts: 400
[Former member]
Zitat:
Original von dante:
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...

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.

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.

Man braucht halt einen minimalen Bereich außen um den sichtbaren Bereich, um dort in Ruhe zeichnen zu können. Das ganze lässt sich natürlich auch mit Double-Buffering kombinieren. Das Blitten wird mit dem Speicherwrap auch nur minimal komplizierter.

Turrican (Manfred Trenz) verwendet dieses Prinzip und wir wissen, ja, dass das wahnsinnig schnell und üppig scrollen kann (siehe Raumschiff-Level).
--
--
Best Regards

Chris Hodges

[ - Answer - Quote - Direct link - ]

2004-06-20, 11:51 h

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


Ja, das dachte ich mir dazu auch... man kann den Blitter auch ÜBERschätzen.

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

[ - Answer - Quote - Direct link - ]

2004-06-20, 13:08 h

whose
Posts: 2156
User
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 :D

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? :lach:


Grüße

[ - Answer - Quote - Direct link - ]

2004-06-20, 20:36 h

platon42
Posts: 400
[Former member]
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

[ - Answer - Quote - Direct link - ]

2004-06-20, 20:58 h

platon42
Posts: 400
[Former member]
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? :lach:

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.

Der Copper ist ziemlich mächtig. Z.B kann man mit den Modulo-Werten spielen, um ohne Speicher kopieren zu müssen, Vertikal zu zoomen/shrinken oder zu spiegeln. Man kann sogar zwei Sprites verwenden, um ein 16-farbiges Playfield zu erzeugen, nur aus zwei Sprites (man braucht dann aber riesige Copperlisten).

--
--
Best Regards

Chris Hodges

[ - Answer - Quote - Direct link - ]

2004-06-20, 23:25 h

whose
Posts: 2156
User
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 :rolleyes: 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

[ - Answer - Quote - Direct link - ]

2004-06-21, 01:07 h

dante
Posts: 111
User
@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.

[ - Answer - Quote - Direct link - ]

2004-06-21, 01:19 h

geit
Posts: 332
[Former member]

btr. 8 Wege Scrolling.

Also BoulderDäsh rendert alle Bildausgaben in Echtzeit und ohne Doublebuffering, wobei jedes Segment der Grafik jederzeit geändert werden kann.

Das passiert sowohl unter ECS, OCS AGA, als auch im RTG Modus.

Im Fenstermodus wird indirekt Double Buffering verwendet, da ich hier einen Screen nebst Bitmap simuliere, um die normalen Screenroutinen benutzen zu können. Danach wird der Kram dann ins Fenster kopiert.

BoulderDäsh macht mehr als 11000 Blitteroperationen pro Sekunde.

Guido Mersmann

[ - Answer - Quote - Direct link - ]

2004-06-21, 10:57 h

platon42
Posts: 400
[Former member]
Zitat:
Original von whose:
Ah ja :rolleyes: 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?


Einfach, indem er die Speicheradressen (siehe Posting von dante) für den Bildschirm DMA vor einer neuen Bildschirmzeile neu setzt.

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

Nope, eben nicht das ganze Chipram, sondern nur etwas mehr als ein Bildschirm, weil man ja mit dem Copper wrappen kann.

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

[ - Answer - Quote - Direct link - ]

2004-06-22, 00:28 h

Bjoern
Posts: 1730
User
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 :O

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

[ Dieser Beitrag wurde von Bjoern am 22.06.2004 editiert. ]

[ - Answer - Quote - Direct link - ]

2004-06-22, 23:16 h

whose
Posts: 2156
User
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



[ - Answer - Quote - Direct link - ]


1 -2- [ - Post reply - ]


amiga-news.de Forum > Programmierung > Amos - lohnt es sich noch? [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.