AMIGA 500 langsamer bei Spielen als ATARI ST ?

Zitat von Kris

Ich finde beide Systeme toll. Ich sah nie die beiden im Konkurrenz zueinander stehen.

Stimme auch zu. Ich habe zwar damals[tm] auf dem Amiga programmiert, habe jedoch ebenfalls den Atari ST deswegen nie als Konkurrenz gesehen, sondern hätte lieber auch noch einen gehabt. Heutzutage würde es mich sogar eher reizen, mal was für den Atari ST zu entwickeln, gerade weil ich es noch nie gemacht habe.

Etwas OT (sorry für soviel TechTalk ) :

Zitat von d020

Wegen der Bitplanes: Es müsste doch möglich sein die Linie nur einmal zu zeichnen (eventuell mit Blitter) und dann mit dem Blitter in die für die jeweilige Farbe notwendige Bitplan mit OR reinzukopieren.

Das wäre sogar noch umständlicher und erheblich langsamer als das normale Verfahren, mit dem Blitter gleich in alle vier Bitplanes die Linie zu zeichnen (s.u.). Das Linienmalen war auch nicht das Problem. Polygone bereiteten die Schwierigkeiten. Wenn man diese mittels des Blitters malen lassen wollte, mußte man wie folgt vorgehen [N.B. Kenntnisstand aus der Erinnerung von 1988 oder so. Falls jemand inzwischen bessere Verfahren kennt, möge er/sie es bitte mitteilen.]:

1.) Das Polygon wird überprüft, ob es teilweise außerhalb des Bildschirms liegt. Falls ja, werden die Schnittpunkte mit den Bildschirmgrenzen berechnet.
2.) Man malt auf einer zusätzlichen leeren Bitplane die Umrißlinien des Polygons. Da der Blitter aber immer alle Punkte der Linie setzt, ergibt sich das Problem bei den oberen und unteren Eckpunkten, daß hier nur ein Polygonpunkt an der Spitze entsteht. Beim nachfolgenden Füllen wird jedoch stets zwischen zwei Punkten gefüllt, wodurch es an den Spitzen zu Füllfehlern kommt. Da mußte man entsprechend gegenwirken (, was zusätzlich Zeit kostet).
3.) Die Malbitplane wird gefüllt.
4.) Das so entstandene gefüllte Polygon wird aus der Malbitplane viermal umkopiert auf die eigentliche Anzeigebitplane.
5.) Die Malbitplane wird für spätere Polygone wieder gelöscht.

Hier zum Vergleich die Vorgehensweise bei Virus:
1.) Es wird geprüft, ob das Polygon sich teilweise außerhalb befindet. Falls ja, werden aber keine Schnittpunkte berechnet (sehr aufwendig), sondern die Malroutine wird (über einen indirekten Sprung) so abgeändert, daß vor jedem Zeichnen einer horizontalen Polygonlinie getestet wird, inwieweit sich die Linie außerhalb des Bildschirms befindet.
2.) Virus verwendet DDA zur Berechnung der Umrißlinien des Polygons. Den Additionswert ermittelt das Programm aber nicht über eine Division, sondern holt sich den Wert aus einer (recht großen) Tabelle.
3.) Die Berechnung der linken und rechten Umrißlinie sieht so aus:

Hierbei besteht ein Dreieck aus maximal zwei solcher Routinen. Ein Viereck benötigt drei. Der Programmcode enthält für alle möglichen Formen von Dreiecken und Rechtecken die passenden Routinen mit dem jeweiligen Kern wie oben genannt.
4.) Das eigentliche Plotten auf die Anzeigebitplane sieht dann z. B. so aus:

Für die im Spiel relevanten geringen Polygonbreiten gibt es jeweils eigene Routinen. Für Breiten darüber gibt es eine allgemeine Routine.
Viele Polygone (nicht nur) bei Virus sind sehr klein und bestehen aus wenigen Zeilen. Allein das Setzen der Blitterregister zum Malen der Linien sowie dem Füllen, dem Umkopieren und dem Löschen ist bereits ein vielfaches aufwendiger als diese Routine. Es nutzt also nichts, wenn der Blitter irgendwie schnell den Speicher setzen kann, aber bereits die Initialisierung der Register mit mehr Aufwand verbunden ist als das Malen per Hand.
Verfügt ein Amiga über eine Turbokarte mit Fastram (z. B. sowas wie eine Blizzard 68030 50Mhz) gilt sogar, daß man den Blitter völlig vergessen kann, weil er a) nur auf das Chipram zugreifen kann, b) im Vergleich zum Prozessor viel zu langsam ist. Auf solchen Systemen malt man die Graphik in einem Puffer im Fastram und kopiert diesen dann (per Prozessor) ins Chipram auf die Bitplane. Anders gesagt: Wirklich nützlich war der Blitter für mich nie.

Zitat von enthusi

Virus? Also das Zarch?

Ja, genau!

Zitat von enthusi

Es ist schon bezeichnend dass das am Amiga/Atari so gespielt wird, dass man die Landschaft quasi nie sieht aus performance Gruenden.

Das kommt darauf an, wer vor dem Rechner sitzt. Also der computergesteuerte Demospieler fliegt häufig über die Landschaft hinweg, besonders in der dritten Landschaft mit ihren Hügeln und Schluchten. Allerdings muß ich gestehen, daß ich selber die Steuerung bis heute nicht beherrsche. Bin irgendwie zu blöd dafür.

Zitat von enthusi

Dabei schrieb Braben das auf einer ihm unbekannten CPU.

Ja, der konnte echt gut programmieren, was man auch an Frontier sah, bis heute eines meiner Lieblingsspiele.

Zitat von d020

Ja - Muss man denn wirklich immer 4x kopieren?

Solange man mit einer festen Farbpalette arbeitet: ja. Das Kopieren ist nämlich kein einfaches Kopieren, sondern eher ein Maskieren bzw. Ausstanzen der Anzeigebitplane, da für jedes Bit der Farbe die Anzeigebitplane an der Stelle des Polygons entweder gesetzt oder gelöscht werden muß.
Angenommen, das erste Polygon, das gemalt werden muß, hat die Farbe 1 (%0001). Dann müßte theoretisch auf einer leeren Bitplane nur eine Bitplane gesetzt werden, da die anderen bereits gelöscht sind. Ist die Farbnummer aber 15 (%1111), so müssen alle 4 Bitplanes gesetzt werden. Will man anschließend ein Polygon mit der Farbe 1 (%0001) darüber malen, so müssen auf drei Bitplanes die Bits wieder gelöscht werden. Nun weiß man halt bei einer festen Farbpalette nie, welche Farbe zuerst verwendet wird, und muß folglich immer dafür sorgen, daß die Bitmuster in allen Planes garantiert korrekt sind (gelöscht oder gesetzt).
Abhilfe schafft hier ein System, bei dem man die Farbpalette jeweils neu setzt. Dann würde es genügen, für die erste Farbe nur eine Bitplane zu setzen (immer %0001). Für die nächste Farben (%0010 und %0011) müßten dann zwei Planes bearbeitet werden usw. Ich habe solch ein Verfahren früher mal ausprobiert, und es hat auch gut funktioniert. Leider ist mir jedoch kein Spiel bekannt, daß so gearbeitet hat. Das kann mehrere Gründe haben: 1.) Eine umgebende Cockpitanzeige verlangt nach einer festen Farbtabelle. 2.) Das Spiel wurde entwickelt auch in Hinblick auf den Atari ST. Dort konnte man nicht mit einer Copperliste die Farben während des Bildschirmaufbaus einfach umdefinieren. 3.) Speicherplatz; Man braucht für die Routinen für 1, 2, 3 Bitplanes noch mehr Programmcode als ohnehin schon (jede Farbe, d. h. Bitkombination hat ja eine eigene Malroutine). 4.) Bei einem Spiel wie Virus macht es wenig Sinn, da ruckzuck alle Farben Verwendung finden und man wieder bei 4 Planes angekommen ist. 5.) Ist halt aufwendiger. Wozu sich die Mühe machen, wenn es auch so läuft.

Zitat von d020

Man könnte also einfach den Zeichenbereich vergrössern

Wie groß willst Du denn den Zeichenbereich vergrößern? Das Blöde ist, daß man sich bei vielen 3d-Spielen sehr nah an die Objekte heranbewegen kann, so daß man für die projizierten 2d-Bildschirmpunkte sehr hohe Werte erhält, z. B. x = -14439 und y2 = 24399. Eine Bitmap diesen Ausmaßes würde den Speicher des Amiga sprengen. Hinzukommt, daß dann solch ein großes Polygon auch gemalt werden will. Aus diesem Grunde arbeiten die 3d-Programme mit Clippingroutinen, die für die Teile des Polygons, die sich außerhalb des sichtbaren Bereichs befinden, neue Umgrenzungslinien berechnen. Dafür kommen aber jeweils eigene, schnelle Routinen im Programm zum Einsatz. Auf OS-Routinen wird dabei nicht zurückgegriffen.