Ist wirklich schwer vergleichbar.

Beim Amiga haben die Custom-Chips eben viel rausgerissen, ähnlich wie bei Konsolen. Die nackte Amiga-500-CPU war in der Tat nicht so rattenschnell. In der Praxis leistete der A500 als Multimedia-Maschine trotzdem eben deutlich mehr als ein typischer 286-PC. Auch bei Spielen mit 3D-Grafik, für die die Amiga-Custom-Chips ungeeignet sind, hängen diese Chips eben nicht komplett tatenlos in der Ecke rum, sondern leisten im Rahmen der Möglichkeiten noch einiges.

> weil ein 80286 mit 12MHz deutlich schneller war als ein 68000 mit 7Mhz

laut https://en.wikipedia.org/wiki/Instructions_per_second#Millions_of_instructions_per_second_(MIPS) stimmt das nicht, höchstens gleichschnell.

Motorola war schon gute Tech damals, aber IBM hatte sich aus betriebswirtschaftlichen, nicht technischen Gründen für die Intel-Reihe entschieden (second sources, und die verlangten Massenstückzahlen konnte Motorola nicht versprechen zu liefern).

Sorry, aber Übertaktung hat für mich schon etwas von "ich schiebe die Welt zurecht, damit das Argument passt".


Meine Ausgangsaussage war, dass die Grafik auf dem NeoGeo (wie auch auf dem Lynx) sprite-basiert strukturiert ist. Dass es einen festen Modus für statische Hintergründe gibt, kommt noch oben drauf. Ein großer Level ist nicht unbedingt die Grundlage, dass das auch komplett im Vorfeld komplett im Speicher liegen muss. Zumindest wäre mir neu, wenn das Spiele aus der Ära so machen. Kann ich mir bei Neo Drift Out auch nicht vorstellen.


AFAIK kann man auf dem NeoGeo durchaus Sprites multiplexen.


Wie man das bei Levelmaps seit 8bit-Zeiten halt so macht. Nur wenn die NeoGeo-Hardware angenommen/nachweislich nicht schnell genug bei Richtungswechsel die Daten bereitstellen kann (was ich mir nicht so recht vorstellen kann), würden da nicht versetzte Leveldaten bei Bedarf aus ner anderen Bank gezogen bei dem Scrollverhalten helfen? Ich sehe keinen Grund dafür, wenn man fest definierte Tiles hat, man nicht die Levelarchitektur unabhängig davon manipulieren können soll.


Ich mag mich jetzt täuschen, ohne jetzt das in Frage stellen zu wollen. Das unterstreicht doch noch, warum sich Entwickler irgendwann nicht mehr mit solchen Umständen auseinander setzen wollen.

Was den Chunky-Mode anbelangt - wird hier ganz gut erklärt anhand des Akiko-Chips im Amiga CD32:

Link

LOL. Das mit dem Alleinstellungsmerkmal merke ich mir... Es ist ein Fluff-Argument, denn an den Stellen wurden die Systemressourcen überschritten, welche durch die Videoausgabe gesetzt ist. Wenn Entwickler mehr wollen, als geht, halte ich das für eine streitbare Schlussfolgerung, das auf die Leistungsfähigkeit des Systems zu beziehen.

Bzw die Sprites des NeoGeo reichen dennoch aus, dass man damit die Arena von Fighting Games fullscreen in Echtzeit schrumpfen kann, nicht wahr? Was wohl in der Tat so ist - die mögliche Fläche übersteigt den Screen ja bei Weitem. 96x16 Pixel horizontal - 1536 Pixel.
Deinen Punkt mit dem nicht sichtbaren Areal bei Sonic verstehe ich schon. Nur wieso soll das nicht funktionieren, wenn man Areale auf anderen Speicherbänken ausgelagert hätte? Bzw würde das den Spieler überhaupt auffallen, wenn dieses Blindareal quasi statisch wäre und einfach in der Form gezogen?

Der CPC hat keine höhere Farbtiefe als der C64. Der CPC hat eine 27-Farbpalette mit 2-bit oder 3-bit Farbtiefe im RGB-Farbraum (ob 2 oder 3bit weiß ich gerade nicht genau). C64-Palette läuft abseits des RGB-Farbmodells und lässt sich auch nicht ohne Abweichungen in 8-Bit Farbtiefe abbilden.


Das widerspricht jetzt meiner Aussage bei was?

Unterschiedliche Prozessor Architekturen wird man grundsätzlich nie endgültig und eindeutig vergleichen können. Erst wenn eine CPU eine andere bis auf Taktzyklen genau in voller Geschwindigkeit emulieren kann, weiß man wirklich, dass diese auch wirklich schneller ist

Du hast selber schon Sprites und Scrolling erwähnt. Wenn es darum geht nur zwei CPUs zu vergleichen brauchst Du einen Benchmark, der nur auf der CPU rechnet. Ein reiner CPU Benchmark hat aber keine Aussagekraft, wie schnell "normale" Anwendungen bzw. Spiele auf diesen CPUs sind. Heutzutage ist noch die Geschwindigkeit des RAM ein Faktor. Den kannst Du auf unseren guten alten Homecomputer-CPUs aber vernachlässigen.

Heutzutage programmiert man nicht mehr in Assembler. Wenn man also zwei moderne CPUs unterschiedlicher Architekturen vergleicht, zum Beispiel eine ARM und eine X86 CPU, dann hast Du zum Beispiel den in C,C++ und Fortran geschriebenen SPEC CPU Benchmark, der sehr verbreitet ist. Der besteht zwar aus vielen Einzelbenchmarks, die aber natürlich bei weitem nicht alle "normalen" Anwendungen und Spiele abdecken. Selbst wenn man für beide CPUs die C,C++ und Fortran Compiler der selben Firma nimmt, weiß man noch nicht, ob der Compiler eine der CPU Architekturen besser unterstützt als die andere. Darum benutzt man den SPEC CPU Benchmark auf exakt identischer Hardware auch um zu vergleichen, welcher Compiler für eine bestimmte CPU Architektur nun den schnelleren Code erzeugt.

Für unsere Homecomputer CPUs gibt es zwar auch Compiler für diverse Hochsprachen. Aber um sie Auszureizen braucht man Assembler. Die 6502 und Z80 CPUs sind dermaßen unterschiedlich in der Art wie man sie in Assembler programmiert, dass Du hier gar nicht ein und das selbe Programm laufen lassen kannst um die Ausführungsgeschwindigkeit zu vergleichen. Du kannst auf beiden Programme schreiben, die exakt das selbe tun und das vergleichen. Aber da geht es schon los, dass jeder Programmierer so ein Programm anders schreiben würde. Alleine das macht Dir schon jegliche Vergleichbarkeit kaputt. Du könntest einzelne Programmfragmente vergleichen, deren Programmierung recht eindeutig ist. Das gibt Dir aber wiederum wenig bis keine Rückschlüsse auf "normale" Programme und Spiele. Und wir reden nur von CPU Benchmarks.

Beim Vergleich 6052 und Z80 darf man den Takt und die Taktzyklen nicht außer acht lassen. Der 6502 ist ein 8 Bitter der nur 8 Bit Befehle kann. Die aber in sehr wenigen Taktzyklen, nämlich 1 bis maximal 7. Beim Z80 sind das 4 bis maximal 23. Darum wäre ein Z80 bei gleichem Takt wie ein 6502 langsamer, weil er pro Befehl immer länger braucht. Auf unseren geliebten Homecomputern der 80er war der 6502 aber immer nur mit 1 bis 1,7 MHz getaktet und der Z80 immer mit 3 bis 4 MHz.

Der Z80 ist auch ein 8 Bitter, der aber 16 Bit Befehle hat. Die werden sehr langsam ausgeführt, weil er intern mehrere 8 Bit Befehle ausführt um zum Ergebnis zu kommen. Aber das erlaubt dann wieder schlanken Code. Für eine 16 Bit Addition, z.B eine Scoreanzeige, die nicht nur bis 255 (8 Bit), sondern bis 65535 geht, brauchst Du beim 6502 mehrere Befehle und beim Z80 nur einen. Der Z80 hat deutlich mehr Befehle als der 6502. Davon aber viele identische, je einen für eine 8 oder 16 Bit Operation.

Auch wenn ich jetzt erst anfange, mein Wissen aus dem Informatikstudium auf dem zweiten Bildungsweg auf mein Retrocomputing Hobby anzuwenden, so weiß ich bezüglich solcher Systemvergleiche mittlerweile eines:
Du kannst diese alten Homecomputer nur als Gesamtsystem betrachten!

Anders ausgedrückt: Sie sind mehr als die Summe ihrer (Bestand-) Teile!

Darum gibt es innerhalb der Homecomputer auch keine wirklichen 1:1 Portierungen - die Eigenheiten des Gesamtsystems verraten sie immer!

Heute ist man von den CPUs entkoppelt, da in Hochsprachen programmiert wird bzw. man nur noch in einem Framework oder einer Engine scripted!

Heute ist man von den GPUs entkoppelt, da man eine Grafikbibliothek wie OpenGL, Vulkan oder Direct3D benutzt oder gar nicht mehr programmiert und in einem Framework oder einer Engine nur noch 2D/3D-modelliert!

Heute ist man von den Soundchips entkoppelt, da eh nur OGG oder MP3 Dateien abgespielt werden und die Musiker völlig frei sind, ob sie ein ganzes Orchester aufnehmen oder nur auf ihrem Synthesizern spielen!

Glaube ich auch nicht.

@Christian Keichel:

Das mit den Slowdowns hast du als Systemvergleich in den Raum geworfen. Es ist nur so, dass codeseitig beim Bildaufbau geprüft wird, ob da noch Routinen am Start sind und wenn ja, wird der Frame übersprungen. Das hat nichts, aber auch gar nichts mit der Systemleistung zu tun. Bzw wenn die Gamedesigner oder Grafiker oder werauchimmer sich die Vorgaben des Coders oder wenigstens die Systemleistung berücksichtigen würden, bräuchte man das nicht

Das Neo Geo konnte Tiles schrumpfen, man mann sie auch beliebig animieren, austauschen, wieauchimmer. Mir ist immer noch nicht klar, wieso ein Sonic nicht auf dem NeoGeo möglich sein soll. Ich würde mal behaupten, die Speicheranbindung ist bei dem System schnell genug, dass man im Zweifel sich die Daten anderwärts zieht.

Für deine Einordnung der CPC-Farbpalette hat man immer den Kompromiss vor Augen, dass man alleine durch die stark gesättigten Farben motivseitig eingeschränkt wird (behaupte ich als Pixelartist einfach mal) und durch den Speicher- und Rechenzeitbedarf vom Vorteil der freien Farbwahl nicht so viel bleibt. Ich ziele dabei auf die Gesamtleistung des Systems ab, denn genau das war ja deine Argumentation bezogen auf 16-Bit-Systeme.

Nochmal zum Chunkie-Mode. Das ist keine Behauptung meinerseits, sondern ich gebe hier wieder, wie mir das Coder gesagt haben. Der Speicherbedarf für Bitplanes ist das eine, nur man muss die Bitplanes einzeln anpacken, vorbereiten, die Farbzuordnungen ebenfalls, wo auf dem PC die Daten schon in einem Abwasch geschrieben wurden.


Ich würde das aber nicht als Beispiel für Systemvergleiche heranziehen, da es die Ausgangsbasis verwässert.
Kommentar wurde am 06.01.2021, 17:47 von v3to editiert.

Also SNES und Neo Geo sind da rein technisch nicht in der gleiche Liga. Da hat v3to schon recht. Das NG ist ein riesige Spriteschleuder, und kann da viel mehr machen als ein SNES. Allein schon die hohe Anzahl der Animationen auf einmal sind auf dem SNES nicht machbar.

Die NG Hintergründe (mit fertigen Animationen) können sogar vorgerendert direkt aus dem Modul gestreamt werden. So das Sprite/Tile mäßig im Vordergrund noch mehr machbar ist. Wahrscheinlich übertreiben die Macher da manchmal, so das auch die 12,5 MHz CPU überfordert ist. Glaube auch nicht, das die Metal Slug Spiele überhaupt in vollen 60fps programmiert sind.
Kommentar wurde am 06.01.2021, 17:45 von Retro-Nerd editiert.

Slowdowns sind nur keine Systemeigenschaft. Framedrops werden in der Regel über den Programmcode ausgelöst und nicht durch die Hardware.

Das stimmt nicht, dass das Tilemapping des Mega Drive oder SNES weiter war als das NeoGeo. Bzw da müsste ich an sich ausholen, weil ich es beim Amiga für eine Fehlentscheidung halte auf einen Grafik-Charmode (was ja an sich ja Tiles sind) zu verzichten, weil im Vergleich zu reiner Bitmap-Grafik viel mehr möglich ist.
Nur wenn man es so will, hat das NeoGeo Tiles ohne besondere Restriktionen. Man hat ein Vielfaches an Objekten gegenüber anderen Systemen zur Verfügung. Ein Sprite kann zwar auch nur 15 Farben wie zb beim SNES verwenden, allerdings kann man das beliebig definieren, bis man alle 4096 Farben auf dem Screen hat.

Wieso soll ein Sonic nicht auf dem Neo Geo möglich sein? F-Zero stimmt. Das kommt aber auch durch Mode-7, wofür btw das SNES auch einen Zusatzchip brauchte, weil die Konsole alleine nicht so große Objekte verarbeitet bekommt.

Was deine Einwände mit den Hardware-Eigenschaften des C64 angeht: Genau das meine ich. Du hast über zig Kommentare hier Eigenschaften bei 16-Bit-Systemen bei deiner Argumentation nicht berücksichtigt, bzw dass die Einfluss darauf haben, was man mit der jeweiligen Hardware anstellen kann und sozusagen im gleichen Satz das Thema auf CPU und MHz vereinfacht. Bzw zwischendurch Titel gegenübergestellt, wo auf einer Seite hardwareseitig nachgeholfen wurde und auf anderer Seite nicht.

Bei meinem C64-CPC-Vergleich, den ich dagegengestellt habe, differenzierst du ja auch, was die Hardware an besonderen Eigenschaften mitbringt. Das ist bei 16-Bit-Systemen aber nicht groß anders.

Der CPC hat nebenbei bemerkt keine höhere Farbtiefe als der C64, aber mehr Farben als Basis. Denke mal, dass du die festen 16 Farben meinst. Die Palette des C64 übersteigt streng genommen den RGB-Farbraum.

Was den Chunkie-Mode angeht: Man ändert pro Pixel ein Byte und nicht wie wie je nach Amiga-Modell 5 bis 8 Bitplanes.
Kommentar wurde am 06.01.2021, 16:26 von v3to editiert.