Hello, Guest the thread was called31k times and contains 256 replays

last post from TheRealWanderer at the

AMIGA 500 langsamer bei Spielen als ATARI ST ?

  • "Der Archimedes beherrschte nur ein Hardware-Sprite (das in erster Linie als Mauszeiger verwendet wurde). Zudem hatte er keine Grafik-Spezialchips, so dass die Entwicklung von Spielen schwierig war. Trotzdem gab es auch beim Archimedes aufwendig gestaltete Spiele, darunter Umsetzungen von Amiga-Spielen, die ihren Originalen entsprachen."


    sagt Wikipedia zu dem Thema.


    Ich erinnere mich aber auch, das der Archimedes als der kommende Überflieger damals in den Zeitschriften angepriesen wurde.
    Aber scheinbar kam da nicht so viel.

  • Habe ich mal ausprobiert, sieht auf einem PAL-Monitor scheiße aus, total verwaschen. Wenn du das benutzt hast, selber schuld.

    Es gab auch am Amiga einen Monochrom Monitor. Mit 1024x1024. In 4 Graustufen. den A2024.


    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.

  • Ihr habt das einfach falsch gemacht. Den Amiga gab´s von den Eltern, den ST von der Oma.
    Ich hatte beide Systeme und fand und finde beide auch heute noch toll.
    Jedes System hat seinen eigenen Reiz, aber Design-technisch war Atari immer der Gewinner!

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

    Sehe ich genauso. In beiden Geräten schlägt das gleiche Herz. :love:


    Ich habe schon damals die Sinnhaftigkeit des Amiga / ATARI- Krieges nicht verstanden. Daran hat sich bis Heute auch nichts geändert. :rolleyes:



    Ich konnte mir damals jedenfalls beides nicht leisten...... ;)

  • ich war damals 10 als der C64 rauskam, und ca 14 als der amiga 500 den 64er bei meinem bekannten "ablöste". selber hatte ich nie einen rechner obwohl mein grösster traum war.
    zum 64er brotkasten, C64II und A500 bin ich erst vor 2 jahren gekommen. die zeit dazwischen war es halt nur vergangenheit. einen atari hatten auch viele, jedoch "nur" die konsole VCS2600.
    einen ST oder XL kannte ich nur von fotos aus dem quelle oder otto katalog.
    finde die ataris vom design her auch sehr sehr geil. jeder rechner hat halt seinen eigenen "Charm"

  • Eben. Ich habe den Atari bei einem damaligen Schulkameraden entdeckt. Der hatte damals schon alles was man zu der damaligen Zeit so alles bekommen konnte. Der besaß den Atari Panther und ein Neo Geo und was was ich noch alles. Von seinem Atari ST hatte ich immer nur Bomben zu Gesicht bekommen. ;)


    Der Schulkamerad wurde von uns Gleichalterigen nicht ernst genommen. Wir sahen den wie so eine Art Freak. Der war uns ein wenig suspekt. ( Heute sagen das Andere mit Sicherheit über mich )
    Wir waren damals alle im C64 Sektor unterwegs.




    Erst als Erwachsener kam ich in den Besitz von meinen Amigas. Da lag es natürlich Nahe, dass früher oder später auch ein Atari 1040STE dazu kommen musste.

  • Für mich war der AMIGA gefühlt "Spass".
    Der ATARI ST hingegen "Arbeit".


    Das lag aber ganz klar daran, dass die ersten ATARI ST, die ich je gesehen habe, alle den s/w Monitor hatten, weswegen da nur "ernsthafte" Dinge wie Textverarbeitung und so benutzt wurden, während auf allen AMIGA, die ich damals sah, pausenlos Spiele und Demos liefen. So hat sich dieser Eindruck festgesetzt.

  • In meinem heutigen Kollegenkreis gilt der Amiga allgemein nur als "Spielekiste". Da galten auch keine Argumente, dass es ja auch die Big-Box Amigas gab, mit dem man auch etwas mehr als Spielen kann.


    In dem Zusammenhang wird der ATARI immer als seriöserer Computer dargestellt. Meisstens wurde dann die integrierte MIDI-Fähigkeit besonders hervorgehoben.



    ( Im Übrigen ist die MIDI-Fähigkeit für mich auch mit ein Argument gewesen, einen ATARI anzuschaffen )

  • ( Im Übrigen ist die MIDI-Fähigkeit für mich auch mit ein Argument gewesen, einen ATARI anzuschaffen )

    MIDI Interfaces gab es auch für den Amiga, bzw. waren die leicht selbst zu bauen. Hab ich aber ehrlich gesagt nur mal Aegis Sonix und eine andere Software ein wenig ausprobiert, die Tracker waren da weitaus interessanter.

    Arcade & Pinballs: F14 Tomcat, TOTAN, Visual Pinball, MAME Arcade Cab, Münzschieber Glückskarussel
    Musikproduktion: Korg Kronos 61 (2nd 256GB SSD 4GB), Korg M50 61, Akai MPD32, Alesis IO4, KORG Nanopad 2
    Retro: In liebevolle Hände abgegeben.
    Heimkino: Epson TW6000, Xbox 360 Kinect mit Amazon Prime, Nintendo Wii


    "Weise eine kluge Person auf einen Fehler hin und sie wird sich bedanken. Weise eine dumme Person darauf hin und sie wird dich beleidigen"


    Wenn man den Leuten erzählen würde, dass das Gehirn eine App ist, fangen sie vielleicht an, es zu gebrauchen.

  • 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 :sleeping: ) :

    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.

  • Virus? Also das Zarch?
    Archimedes:


    Atari:


    Amiga:


    Es ist schon bezeichnend dass das am Amiga/Atari so gespielt wird, dass man die Landschaft quasi nie sieht aus performance Gruenden.
    Dabei schrieb Braben das auf einer ihm unbekannten CPU.

  • 4.) Das so entstandene gefüllte Polygon wird aus der Malbitplane viermal umkopiert auf die eigentliche Anzeigebitplane.

    Ja - Muss man denn wirklich immer 4x kopieren? Ich denke, dass muss man nur für den Palette Wert 1111 binär also 15.
    Es gbt also mMn 4 Farben die sich mit nur einer Bitplane darstellen lassen 7 mit 2 Bitplanes usw...


    Wenn man also die Oft benutzen Farben auf die Pallete Werte 1,2,4,8 legt sollte das auch Zeit sparen.

  • Also zum Thema Design möchte ich auch noch was sagen.
    Ich hatte bisher leider noch nie das Vergnügen einen Atari ST in Natura zu sehen.
    Aber wenn ich mir Fotos ansehe finde ich das Haptik und Verarbeitung des Atari ST billig wirken im Vergleich zum 500er.
    Alleine die F-Tasten wirken auf den Fotos wackelig klapperig und mit viel zu großen Spaltmaßen.


    Der 500er ist aber auch genauso wie der 128er viel zu groß.
    Das stört mich an der Kiste heute noch mehr wie früher.
    Ebenso hätten die Kisten einen extra Mouseport verdient.
    Ich spiele gerne früher wie heute 2 Spieler Games und das hin und hergestecke nervt.

  • Nochwas wegen der Polygonprüfung:
    Es gibt doch Amiga diese Viewport Sache. Man könnte also einfach den Zeichenbereich vergrössern aber nur die Mitte anzeigen. Objekte die dann ausserhalb dieser Grenzen gezeichnet würden, werden garnicht gezeichent.


    Beim Original Boing Ball wird doch der Ball so "bewegt" (Mit Viewport meine ich).

  • Virus? Also das Zarch?

    Ja, genau! ^^

    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. :schande:

    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.


    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. :whistling:

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

  • -> Kennt noch jemand die Second Reality Demo von 1993 auf dem PC, was haben wir damals gestaunt... Hier die 20 Jahre jüngere ST-Umsetzung davon...

    Da sieht, finde ich, die C64er Version doch besser aus als die fuern Atari ST ....
    (TON hatte ich gerade aus beim schauen)


    Früher empfand ich den Amiga dem Atari ST hin überlegen - was Grafik und Spiele anbelangt - aber es ist doch sehr ausgeglichen.