Willkommen bei
 Kult-Magazine
 Kultboy.com-Inhalte
 Interaktiv
Neues Mitglied: RM05
 Sonstiges




Spiele-Datenbank

Bild
21241 Tests/Vorschauen und 13163 Zeitschriften
Titel
Entwickler
nach was?
Magazine
Datenträger
Spieltype
Alphabet
System
Sortierung
Jahr
Treffer
 Genre Suche (aufklappen)
zufälliger Test/Vorschau anzeigen           



Super R-Type
Gib Deine Bewertung ab!
Bisher 18 Stimmen bei einer Gesamtwertung von 6.66

Entwickler: Irem   Publisher: Irem   Genre: Action, 2D, Sci-Fi / Futuristisch, Shooter   
Ausgabe Test/Vorschau (3) Grafik Sound Wertung System Datenträger Hits Autor
ASM 11/91
Testbericht
8/12
9/12
7/12
Super Nintendo
8 MBit Modul
59Hans-Joachim Amann
Play Time 10/92
Testbericht
75%
50%
69%
Super Nintendo
8 MBit Modul
1095Oliver Menne
Video Games 3/91
Testbericht
70%
72%
62%
Super Nintendo
8 MBit Modul
420Martin Gaksch
Partnerseiten:

Lieblingsspiel der Mitglieder: (2)
Dein Lieblingsspiel?

Willst du das Spiel noch spielen? Dann setze es auf deine Liste!

Mitglieder die das Spiel durchgespielt haben: (1)
Spiel markieren?

Videos: 2 zufällige von 1
Kategorie: Longplay, SNES
User-Kommentare: (82)Seiten: [1] 2 3 4 5   »
07.01.2021, 18:40 DaBBa (2111 
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.
07.01.2021, 16:42 Christian Keichel (116 
Grumbler schrieb am 07.01.2021, 12:49:
> 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).


MiPS sind leider ein sehr schlechter Vergleichsparameter, weil Prozessoren eine unterschiedliche Anzahl von Befehlen benötigen um bestimmte Dinge auszuführen. Ein standardisierter Benchmark wie Dhrystone gibt Dir da bessere Ergebnisse:

Ein Amiga hat nach allem was ich finde je nach RAM am Ende zwischen 500 und 700 Dhrystones

Ergebnis zum Beispiel von hier:
http://eab.abime.net/showthread.php?t=74045
https://en.wikipedia.org/wiki/Sysinfo

Ein 80286 DOS Rechner mit 7,5 MHz kam dagegen schon auf 1159 Dhrystones:
https://tech-insider.org/unix/research/1986/0331.html

Du kannst ungefähr abschätzen, das ein 12 MHz 80286 dann auf rund 1700 Dhrystones kommen müsste, was mehr als doppelt so schnell ist wie ein Amiga mit sehr schnellem Ram und ungefähr drei mal so schnell wie ein Stock Amiga.

Dhrystone ist auch kein exakter Vergleichsparameter, dazu hängt es zu stark von der Umgebung ab, auf der es läuft, aber die ungefähre Richtung ist schon mal ein guter Hinweis.
Kommentar wurde am 07.01.2021, 16:46 von Christian Keichel editiert.
07.01.2021, 12:49 Grumbler (948 
> 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).
06.01.2021, 19:51 v3to (1602 
Christian Keichel schrieb am 06.01.2021, 19:14:
Nein, es wurden Systemressourcen überschritten, welche durch die CPU gesetzt wurden, denn eine übertaktete CPU lässt die Slowdowns verschwinden. Die Videoausgabe erfolgt beim Neo Geo durch den Videochip, nicht durch den Prozessor.

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

Christian Keichel schrieb am 06.01.2021, 19:14:
Die Background-Arenen beim Neo Geo sind aus Sprites zusammengesetzt, die sind 16x512 Pixel (wie ich ja unten schon schrieb). Die 96 war die Anzahl der Sprites pro Scanline (96 oder 98, musst Du nachschauen). Für einen Scroll Layer die jeweils 512 Pixel umfassen sollen brauchst Du ungefähr 32 Sprites (ihre Breite ist ja 16 Pixel), für die 2 Layer die das Mega Drive biete also schon 64 Sprites. Dazu kommt aber noch das Window Plane und das Sprite Plane.

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.

Christian Keichel schrieb am 06.01.2021, 19:14:
Die 2 Scroll Layer sind aus Sprites zusammengesetzt die jeweils bildschirmhoch sind, ansonsten bräuchtest Du noch mehr als 64 Sprites.

AFAIK kann man auf dem NeoGeo durchaus Sprites multiplexen.

Christian Keichel schrieb am 06.01.2021, 19:14:
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?


Die Areale sind ja keine vorberechneten Bitmaps, die werden vom Spiel dynamisch konstruiert bevor sie dargestellt werden können.

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.

Christian Keichel schrieb am 06.01.2021, 18:19:
Wenn Du mir sagst, wie Du es auf einem Amiga 500 schaffst 1,6 Daten MB/s vom Prozessor berechnen zu lassen, die an den Videospeicher zu senden und nebenher noch eine Spielengine laufen zu lassen mit Sound und allem drum und dran, dann glaube ich Dir, dass ein 1-Byte-pro-Pixel Modus auf einem Stock Amiga geholfen hätte Wing Commander flüssiger zu machen.

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.
06.01.2021, 19:14 Christian Keichel (116 
v3to schrieb am 06.01.2021, 18:55:
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.


Nein, es wurden Systemressourcen überschritten, welche durch die CPU gesetzt wurden, denn eine übertaktete CPU lässt die Slowdowns verschwinden. Die Videoausgabe erfolgt beim Neo Geo durch den Videochip, nicht durch den Prozessor.

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.


Die Background-Arenen beim Neo Geo sind aus Sprites zusammengesetzt, die sind 16x512 Pixel (wie ich ja unten schon schrieb). Die 96 war die Anzahl der Sprites pro Scanline (96 oder 98, musst Du nachschauen). Für einen Scroll Layer die jeweils 512 Pixel umfassen sollen brauchst Du ungefähr 32 Sprites (ihre Breite ist ja 16 Pixel), für die 2 Layer die das Mega Drive biete also schon 64 Sprites. Dazu kommt aber noch das Window Plane und das Sprite Plane.

Die 2 Scroll Layer sind aus Sprites zusammengesetzt die jeweils bildschirmhoch sind, ansonsten bräuchtest Du noch mehr als 64 Sprites. Also hast Du schon 2/3 der verfügbaren Sprites verballert. da bildschirmgroße Sprites prinzipbedingt alle Scanlines abdecken und Du nur nur 96 pro Scanline darstellen kannst. Sonic ist recht groß, der allein dürfte schon 3 Sprites in der Breite sein, die Feinde (es sind viele) sind schätze ich knapp 32 Pixel breit, alsp pro Feind 2 Sprites). Aber dann hast Du da noch die Ringe und es sind viele Ringe und jeder müsste per Sprite dargestellt werden. Die Ringe liegen oft in einer Linie hintereinander. Du würdest in kürzester Zeit ins Spritlimit pro Scanline laufen.

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?


Die Areale sind ja keine vorberechneten Bitmaps, die werden vom Spiel dynamisch konstruiert bevor sie dargestellt werden können.



Christian Keichel schrieb am 06.01.2021, 18:19:
Noch einmal, pro Frame 80 KB, das bedeutet wenn dein Spiel mit 20 FPS laufen soll musst Du allein 1,6 MB/s an Daten berechnen und in den Grafikspeicher schieben. Damit ist ein Amiga überfordert.

Das widerspricht jetzt meiner Aussage bei was?


Wenn Du mir sagst, wie Du es auf einem Amiga 500 schaffst 1,6 Daten MB/s vom Prozessor berechnen zu lassen, die an den Videospeicher zu senden und nebenher noch eine Spielengine laufen zu lassen mit Sound und allem drum und dran, dann glaube ich Dir, dass ein 1-Byte-pro-Pixel Modus auf einem Stock Amiga geholfen hätte Wing Commander flüssiger zu machen.
Kommentar wurde am 06.01.2021, 19:17 von Christian Keichel editiert.
06.01.2021, 18:55 Petersilientroll (514 
Was den Chunky-Mode anbelangt - wird hier ganz gut erklärt anhand des Akiko-Chips im Amiga CD32:

Link
06.01.2021, 18:55 v3to (1602 
Christian Keichel schrieb am 06.01.2021, 18:19:
[zitat]v3to schrieb am 06.01.2021, 17:32:
@Christian Keichel:

Ich habe keinen Systemvergleich gemacht, ich habe - und das war der Ausgangspunkt - einzig gesagt, dass Slowdowns kein Alleinstellungsmerkmal des SNES waren.

Und natürlich haben Slowdowns etwas mit der Systemleistung zu tun, der Code verlangt nach mehr Leistung als das System in der Lage ist bereitzustellen. Das siehst Du daran, dass NeoGeo Systeme mit übertakteter CPU an besagten Stellen keine Slowdowns haben. Es gibt also schon einen Zusammenhang zwischen Slowdown und Hardware.

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.

Christian Keichel schrieb am 06.01.2021, 18:19:
Noch einmal, pro Frame 80 KB, das bedeutet wenn dein Spiel mit 20 FPS laufen soll musst Du allein 1,6 MB/s an Daten berechnen und in den Grafikspeicher schieben. Damit ist ein Amiga überfordert.

Das widerspricht jetzt meiner Aussage bei was?
06.01.2021, 18:19 Christian Keichel (116 
v3to schrieb am 06.01.2021, 17:32:
@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

Ich habe keinen Systemvergleich gemacht, ich habe - und das war der Ausgangspunkt - einzig gesagt, dass Slowdowns kein Alleinstellungsmerkmal des SNES waren.

Und natürlich haben Slowdowns etwas mit der Systemleistung zu tun, der Code verlangt nach mehr Leistung als das System in der Lage ist bereitzustellen. Das siehst Du daran, dass NeoGeo Systeme mit übertakteter CPU an besagten Stellen keine Slowdowns haben. Es gibt also schon einen Zusammenhang zwischen Slowdown und Hardware.

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.


Das Neo Geo konnte keine Tiles schrumpfen, sondern nur Sprites, Du wirfst hier zwei unterschiedliche Dinge zusammen. Die Planemap (so wurden die zusammengesetzen Tilemaps auf dem Mega Drive genannt) für Sonic ist 512*256 pixel groß so dass das Spiel schon "weiß" was sich außerhalb des Bildschirms befindet. Hinzu kommt, dass das Mega Drive mehrere Ebenen an Tile Maps gleichzeitig darstellen kann, unabhängig von den Sprites. Für das Neogeo hätte das geheißen Schon allein 80 Sprites für Vorder- und Hintergrund permanent im Einsatz zu haben, was die Grenze von 96 Sprites pro Scanline schon fast gesprengt hätte.

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.


Ich sagte nur, dass Du beim CPC eine höhere Farbtiefe hast, alles andere interpretierst Du nun in meine Aussage hinein.

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.


Noch einmal, pro Frame 80 KB, das bedeutet wenn dein Spiel mit 20 FPS laufen soll musst Du allein 1,6 MB/s an Daten berechnen und in den Grafikspeicher schieben. Damit ist ein Amiga überfordert.
Kommentar wurde am 06.01.2021, 18:20 von Christian Keichel editiert.
06.01.2021, 18:15 nudge (1136 
Edgar Allens Po schrieb am 06.01.2021, 15:41:
Wobei wir heute wissen, dass der Z80 zwar schon schneller war als die C64-CPU, aber bei weitem nicht viermal so schnell, wie man vielleicht meinen könnte. Dennoch überlegen genug, um ausgefüllte 3D-Grafik wie in "Starstrike 2" darstellen zu können, jedoch nicht schnell genug, um fehlende Hardware-Unterstützung von Scrolling und Sprites mal eben zu kompensieren.

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!
06.01.2021, 17:42 v3to (1602 
Retro-Nerd schrieb am 06.01.2021, 17:10:
Glaube auch nicht, das die Metal Slug Spiele überhaupt in vollen 60fps programmiert sind.

Glaube ich auch nicht.
06.01.2021, 17:32 v3to (1602 
@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.

Christian Keichel schrieb am 06.01.2021, 17:05:
Nein, habe ich nicht, schnelleres ROM in das Cartridge zu packen ist kein Nachhelfen.

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.
06.01.2021, 17:10 Retro-Nerd (12164 
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.
06.01.2021, 17:05 Christian Keichel (116 
v3to schrieb am 06.01.2021, 16:13:

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


Ähm, das war das was ich die ganze Zeit sagte.

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.


Mit der Möglichkeit von Tiles kam auch noch die Möglichkeit die zu manipulieren und zu kombinieren das konnte das Neo Geo nicht.

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.


Weil Sonic nicht nur den aktuellen Spielbildschirm als Tile immer griffbereit gehalten hat, sondern auch ein Stück weit links und rechts, was das schnelle wenden und hin und herscrollen ermöglichte ohne dass dadurch große Last angefallen ist.

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.


Nein, habe ich nicht, schnelleres ROM in das Cartridge zu packen ist kein Nachhelfen. Alles was ich sagte war, dass Neo Geo Spiele, genau wie SNES Spiele Slowdowns haben. In beiden Fällen sind es Fragen der Programmierung die dafür der Grund sind und in beiden Fällen führt die Programmierung dazu, dass die CPU am Limit ist. Das führt zu den Slowdowns, nichts anderes habe ich geschrieben.

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.


Der CPC hatte eine 27 Farben Palette aus der er 16 gleichzeitig darstellen konnte. Das ist deutlich mehr als der C64. Ich weiß dann immer noch nicht, worauf Du ursprünglich mit deinem CPC Argument abgezielt hast wenn nicht auf den Prozessor und nicht auf die Grafik?

Was den Chunkie-Mode angeht: Man ändert pro Pixel ein Byte und nicht wie wie je nach Amiga-Modell 5 bis 8 Bitplanes.


Gut und schön, aber der Speicherbedarf für 8 Bit Farbtiefe ist dann schnell so hoch, dass Du damit das Megabyte, dass der Standard Amiga hat, aufgebraucht ist, ohne dass Du viel machen kannst damit. Mit 8 Bit Farbtiefe musst Du für jedes 320*240 Frame knapp 80 KB Daten produzieren.
Kommentar wurde am 06.01.2021, 17:05 von Christian Keichel editiert.
06.01.2021, 16:13 v3to (1602 
Christian Keichel schrieb am 06.01.2021, 15:36:
Ich glaube wir missverstehen uns, ich spreche keinem System irgend etwas zu oder ab, außer der Tatsache, dass mir kein System aus dieser zeit bekannt ist, auf dem es keine Slowdowns gab.

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.
06.01.2021, 15:42 v3to (1602 
Edgar Allens Po schrieb am 06.01.2021, 15:32:
Liegt das an der abgespeckten Farbpalette?

Das ist eine gute Frage. Wenn man sich bei den Bitplanes einschränkt, geht natürlich auch die Performance hoch. Ich weiß nur nicht, wie aussagekräftig Wing Commander als Benchmark ist. Rotzooming war damals neu und Chris Roberts war schon bekannt dafür, die Rechner-Mittelklasse zu ignorieren.
Seiten: [1] 2 3 4 5   »


Du willst einen Kommentar schreiben?

Dann musst du dich nur kostenlos und unverbindlich registrieren und schon kann es losgehen!