Auch die ganze Physik-Engine läuft doch heute auf der GPU.
Das ist mir aber neu. 
Hallo Besucher, der Thread wurde 50k mal aufgerufen und enthält 423 Antworten
letzter Beitrag von Retrofan am
Neue Spielimpulse durch Turbo-CPU-Modus möglich?
- DJ SID
- Erledigt
-
-
Und da geht es schon los. Für Weltraumspiele á la "Elite" oder "Space Rogue" verwendet man keine Winkel, sondern Rotationsmatrizen.
Naja, nur bedingt. Wenn dann eher Quaternionen, in den meisten Fällen.
Aber genau darum geht's ja, damit und mit den Matrizen willst du ja am 6502 nicht rechnen. Daher Positionen und Winkel, damit stösst man aber irgendwann an Grenzen. Drum bräuchte man eine Mathematikhilfe, so wie beim SNES auch. Sonst geht nicht viel in 3D. -
@M. J.
Ich finde, du denkst da zu schwarz/weiß: entweder ist dir der 6510 zu langsam oder er hat gleich gar nichts zu tun. Ich denke schon, dass man es bei der Konzeption so "balancen" kann, dass die CPU genug zu tun hat, um es ein C64-Spiel nennen zu können – und ihn gleichzeitig nicht zu überlasten mit Dingen, die er ohnehin nicht stemmen kann. Niemand will dir eine 3D-Karte vor die Nase setzen – es geht doch gerade darum, zu eruieren, was man darauf auslagern kann – und was besser nicht. Ich denke schon, dass man da zu einem ausgewogenen System kommen kann – wie es ja auch bei aktuellen PCs der Fall ist (auch da langweilen sich die CPU-Cores nicht – aber sie tun nichts, was sie eh nicht schaffen könnten, weil in vielen Dingen eine GPU halt tausendmal schneller ist.Die Frage des Threadtitels lautet doch, ob neue Spielimpulse durch Beschleunigung möglich wären. Und ich sehe bei reiner CPU-Beschleunigung nur sehr dezente Verbesserungen und schon gar keine "neuen" Impulse (zumindest im bisherigen Thread-Verlauf). Ob Elite etwas weniger flackert oder sogar gefüllte Flächen bekommt – das ist ja noch nicht wirklich was anderes. Aber wenn man auf einmal statt 50 Vektoren 5.000 Vektoren berechnen (und in MC-Bitmap darstellen) könnte, dann wären schon ganz andere Sachen drin. Ein Super-Mario-Kart-Clone in echtem 3D auf dem C64 – warum nicht?
Edit: und wenn es an der Mathematik scheitern sollte, dann wird die 3D-Karte eben gleichzeitig eine FPU – das können doch die entscheiden, die die Sache angehen wollen. Wie gesagt, die Lastverteilung kann man doch so planen, dass es für die gewünschten Anwendungsfälle passt.
-
Das ist mir aber neu.
Ich kenne mich nur ganz allgemein mit der Materie aus und habe das mal so gehört. Wikipedia sagt im Physics-Engine Artikel dazu:
"Hardware acceleration for physics processing is now usually provided by graphics processing units that support more general computation, a concept known as General Purpose processing on Graphics Processing Unit. AMD and NVIDIA provide support for rigid body dynamics computations on their latest graphics cards.
NVIDIA's GeForce 8 Series supports a GPU-based Newtonian physics acceleration technology named Quantum Effects Technology. NVIDIA provides an SDK Toolkit for CUDA (Compute Unified Device Architecture) technology that offers both a low and high-level API to the GPU. For their GPUs, AMD offers a similar SDK, called Close to Metal (CTM), which provides a thin hardware interface.
PhysX is an example of a physics engine that can use GPGPU based hardware acceleration when it is available."
-
Und war mir wieder einfiel: auf der Fujiama 2017 gab es einem C64 der von einem Raspi zero mit grafik versorgt wird, ähnliche taktik wie meine aber das Programm läuft komplett auf dem raspi und der C64 macht nix.
-
Und mittlerweile läuft der Transfer mit 100% Bus Geschwindigkeit und auf dem Raspi läuft kein Linux mehr sonder nen eigenes Bare-Metal OS was sofort startbereit ist
-
auf der Fujiama 2017 gab es einem C64 der von einem Raspi zero mit grafik versorgt wird, ähnliche taktik wie meine aber das Programm läuft komplett auf dem raspi und der C64 macht nix.
Das soll natürlich hier nicht das Ziel sein aber es geht ja auch nicht um Demos, sondern um (interaktive) Games. Aber man könnte natürlich darüber nachdenken, neben 3D-Grafik auch FMV/NUVI-Sequenzen unterzumischen – und schon kommt Wing Commander 64 in greifbare Nähe.
Das mit der 3D-Karte war nur ein Vorschlag – den ich nach wie vor sinnvoller finde, als den 6510 für 3D-Grafik zu beschleunigen. Man muss dafür wenigstens nicht den halben C64 nachbilden, damit das alles rund läuft. Aber wenn die Thread-Beteigten nicht wollen, dann eben nicht. Zwingen kann man ja keinen. Vielleicht findet ja ein stiller Mitleser die Idee interessant und macht was in der Richtung. Und wenn nicht, dann stirbt deswegen auch niemand.
-
Aber dann verstehe ich net warum man das dann, auf Teufel komm raus, an einen C64 dranndübeln muss. Das ist nunmal Hardware die explizit genutzt werden muss weil sonst sinnlos. Mehr als die 2 Demospiele und 4 Demos kommen da nicht bei heraus weil Entwickler sowas in breiter Masse nicht anpacken. Guck dir die zerklüftete Amiga Scene an.
Den C64 könnte man ja quasi weglassen und nur noch den RasPi nehmen. Man hätte dann auch vernünftige IDE zum Spielecoden...Sad but true.Bestes Beispiel Turbo Chameleon 64 (das Gelbe Modul vom Jens das in nen C64 passt mit VGA Anschluss). Zeig mir doch mal ein Programm was die Cooper Engine darauf wirklich nutzt. Diese Hardware gibt es bereits in zählbaren Einheiten.
-
Aber dann verstehe ich net warum man das dann, auf Teufel komm raus, an einen C64 dranndübeln muss.
Weil man es kann!
Mehr als die 2 Demospiele und 4 Demos kommen da nicht bei heraus weil Entwickler sowas in breiter Masse nicht anpacken
Von mehr hat hier auch niemand gesprochen. Ich ging sogar von insgesamt 3 Programmen aus – du bist mir also zu optimistisch.
Und das ist gerade der Grund, warum ich die Sache gut finde. Denn ich möchte keine Zersplitterung der Hardware-Basis. Just for Fun mal ein Spiel für eine besondere Hardware machen – gut und schön. Aber die Mehrheit der kommenden Programme soll natürlich weiterhin auch auf Vanilla-C64 laufen.Abgesehen davon hätte man bei der 3D-Karten-Lösung die Option, sie im Spielmodul unterzubringen, sodass selbst ein 3D-beschleunigtes Spiel auf einem Vanilla-C64 liefe.
Zeig mir doch mal ein Programm was die Cooper Engine darauf wirklich nutzt.
Wahrscheinlich gibt es keines. Was kann die denn?
-
Abgesehen davon hätte man bei der 3D-Karten-Lösung die Option, sie im Spielmodul unterzubringen, sodass selbst ein 3D-beschleunigtes Spiel auf einem Vanilla-C64 liefe.
Was dann aber wiederum keiner (im Sinne von "wenige") spielt weil man das Modul für 50 Euro + kaufen müsste...
Oder du lässt Games coden die "Spielmodulhardware" wegen der 3D Beschleunigung verlangt.
Wo stopft man dann die Ultimate drann? -
Was dann aber wiederum keiner spielt weil man das Modul für 50 Euro + kaufen müsste...
Oder du lässt Games coden die "Spielmodulhardware" wegen der 3D Beschleunigung verlangt.
Wo stopft man dann die Ultimate drann?Andere Module kosten auch über 50€. Wenn man dafür etwas besonderes geboten bekommt, dann wird das auch gezahlt. Ich lasse hingegen gar nichts coden – die 3D-Karte war mein Vorschlag zur Unterstützung der hier im Thread genannten Spielideen, die vorwiegend auf 3D-Darstellung setzten. Und es gibt anscheinend Leute ohne Ultimate oder TC64 – oder die Besitzer ziehen die auch mal ab – zumindest verkaufen sich Modulspiele bisher recht gut.
-
Die Idee, das ins Modul zu integrieren, finde ich insofern "legitim", als dass es dann ein bisschen wie bei NES- oder SNES-Spielen ist, da gab es ja teilweise ebenfalls Module mit Extra-Hardware. Wenn das vom Preis her realistisch ist, dann waere das gar nicht mal so ne schlechte Idee - und das sage ich als einer, der bislang auch eher Vanilla-Fan ist.
-
Ich sehe da eher den Anfang vom Ende.
Beim Atari2600 ist das aktuell der Fall. ARM CPU auf Cart und der Atari ist nur das Interface zur Ausgabe.
Das hat teils mittelmaessige Projekte zur Folge deren Erscheinungsbild das bisher dagewesene natuerlich mit wenig(er) Aufwand in den Schatten stellt.
Nach aussen hin werden die aber als Atari2600 Module wie andere auch wahrgenommen. Folglich schwindet das Interesse 'einfache Module' zu kaufen/spielen.
Damit auch das Interesse daran, fuer den Standard zu entwickeln.
Ich bin davon ueberzeugt, dass das Abweichen vom Standard das Ende einlaeutet auf jeder Plattform. -
Beim Atari2600 ist das aktuell der Fall.
Siehst du die Sache nicht zu schwarz? Wie viele dutzend VCS-Spiele gibt es denn jetzt auf ARM-Basis?
-
@enthusi berechtigter Einwand, allerdings kann ich mir auch vorstellen, dass die C64-Szene anders "funktioniert" als die Atari-2600-Szene. Ich koennte mir sehr gut vorstellen, dass C64-User nach wie vor an Spielen interessiert sind, die sie auch von SD-Karte spielen koennen (hat man ja sogar bei Sam's Journey gesehen, dass das vielen wichtig war), und auch dass die Leute, die den Rechner nutzen, generell auch mehr Wissen ueber Technik haben und folglich auch wissen, was der C64 kann und ob ein Modul eine CPU beinhaltet oder nicht. Insofern also auch sich ein bisschen mehr mit der Materie auskennen und die Unterschiede verstehen. Bei einer reinen Konsole sind sicherlich auch viele Retro-Fans dabei, die einfach nur Interesse am Sammeln und Spielen haben, aber von der Technik nicht so viel wissen. Zudem gibt es bei Konsolen ja auch "nur" Original-Spiele bzw. Modul-Spiele. Auf dem C64 ist die Situation ja ganz anders, den hat man damals mit Disketten betrieben und mit gecrackter Software und mit selbstprogrammiertem Zeugs, da ist die gesamte Software-Bibliothek schon ganz anders aufgebaut.
Also auch wenn ich wie gesagt selbst nicht unbedingt ein Fan bin von Non-Vanilla, koennte ich mir vorstellen dass die C64-Welt das etwas anders verkraften wird als eine reine Konsolen-Welt.
-
Das soll natürlich hier nicht das Ziel sein aber es geht ja auch nicht um Demos, sondern um (interaktive) Games. Aber man könnte natürlich darüber nachdenken, neben 3D-Grafik auch FMV/NUVI-Sequenzen unterzumischen – und schon kommt Wing Commander 64 in greifbare Nähe.
Ein Dragon's Lair-Modul wäre doch mal was. Eine Alpah-Version mit den kompletten Videos gibt es bereits, allerdings auf zig REU-Images verteilt. Auf einem echten C64 also kaum zu gebrauchen. Da wäre ein Modul, welches Zugriff auf ein richtig großes ROM hat, möglicherweise eine Lösung.
Den C64 könnte man ja quasi weglassen und nur noch den RasPi nehmen.
Der RasPi hat aber keinen SID und keinen VIC, welche wir hier aber selbstverständlich nutzen wollen. Und die Eingabe sollte natürlich auch über den C64 erfolgen.
Solange man alles wie üblich am C64 anschließt und einfach nur ein Modul reinsteckt, ist das ein C64-Spiel. Muß man einen anderen Rechner einschalten, ist es kein C64-Spiel. So wird das ein Anwender doch wohl wahrnehmen.
Zeig mir doch mal ein Programm was die Cooper Engine darauf wirklich nutzt.
Cooper Engine? Was ist das? In der Dokumentation steht davon nichts. Quelle?
-
Naja, nur bedingt. Wenn dann eher Quaternionen, in den meisten Fällen.
Natürlich verwenden "Elite" und "Space Rogue" Rotationsmatrizen, ansonsten wäre ein freies Manövrieren im Raum gar nicht möglich. Und auch "Mercenary", "Flightsimulator II" und andere benutzen Rotationsmatrizen spätestens beim Zeichnen.
mit den Matrizen willst du ja am 6502 nicht rechnen
Mit Matrizen rechne ich auf dem 6502 schon seit damals[tm], weil es am einfachsten ist.
es geht doch gerade darum, zu eruieren, was man darauf auslagern kann – und was besser nicht.
Ja, und genau das habe ich verzweifelt versucht.
entweder ist dir der 6510 zu langsam oder er hat gleich gar nichts zu tun.
Da habe ich mich wohl falsch ausgedrückt. Es geht mir nicht um die Geschwindigkeit, sondern darum, daß man die Graphikausgabe nicht einfach vom Rest des Programms abspalten kann. Diese Trennung existiert so einfach nicht. Selbst wenn die ganze Graphikausgabe auf die Karte ausgelagert wird, braucht man trotzdem weiterhin jede Menge Multiplikations-, Wurzel- und sonstwas-Routinen, mit denen man die Bewegungen der Objekte im Raum berechnet. Multiplikationen sind aber eine Schwachstelle des 6502, die man nur einigermaßen ausgleichen kann, indem man sehr, sehr viel Speicherplatz dafür verbraucht. All das wird man durch eine beschleunigte Graphikausgabe nicht beseitigen können.
Der nächste Gedankenschritt war daher, auch die Raumbewegungen auf die Karte auszulagern. Dafür habe ich das Beispiel der Rakete genannt um zu veranschaulichen, warum das nicht so einfach geht. Ein 3d-Objekt besteht nicht nur aus dem Polygon Mesh, sondern zahlreichen weiteren Attributen. Für eine Steuerung brauchst Du z. B. die aktuelle Drehgeschwindigkeit, die maximale Drehgeschwindigkeit, die gewünschte Drehgeschwindigkeit, die Stärke des Zuwachses der Drehgeschwindigkeit, die Fluggeschwindigkeit, die maximale Fluggeschwindigkeit, die gewünschte Fluggeschwindigkeit, der Energieverbrauch bei einer Beschleunigung, der aktuelle Energiestand, der maximale Energiestand blablablablabla...
Damit eine Physikengine ein Objekt bearbeiten kann, benötigt es nahezu alle Attribute eines Objekts. Das aber bedeutet, daß die Objekte sich auf der Karte selbst befinden müssen und nicht mehr im C64-Speicher, denn ansonsten müßte man pro Bild einen Riesenhaufen an Daten auf die Karte schaufeln. Der Endeffekt dabei ist notgedrungen, daß dann sämtliche Berechnung nur noch auf der Karte stattfindet in ARM-Assembler oder sonstwas, aber nicht mehr auf dem 6502. Das ist zwangsläufig, und die einzige Möglichkeit, das zu unterbinden, wäre eine bechleunigte CPU wie bei der SCPU, d. h. Speicherspiegelung auf der Karte und 6502-Code, der entweder schneller läuft als sonst und/oder neue Befehle wie z. B. Multiplikation aufweist, die das Programm beschleunigen. Wenn man sowieso für die Karte ein neues Programm schreiben muß, warum dann nicht in einer Assemblersprache, die den 6502 unterstützt?
Ein Super-Mario-Kart-Clone in echtem 3D auf dem C64 – warum nicht?
Aus zwei Gründen:
1.) Die Datenmengen, die dabei verarbeitet werden, das Programm, das man dazu auf einem ARM (oder sonstwas) schreiben muß, all das hat mit C64 nichts, aber auch rein gar nichts mehr zu tun. Das ist nur noch ein Modul, das man in den C64 steckt, damit die Ausgabe sinnloserweise über den VIC läuft. Wer sowas haben will, darf es gerne mal auf dem PC versuchen. Man schreibt das Spiel brav in einer Hochsprache, und am Ende rechnet man die Ausgabe um in eine VIC-Darstellung. Super. Interessant. Toll.
2.) Schau Dir mal das folgende Bild aus "Mercenary" an:
Man kann irgendwie erahnen, was hier dargestellt werden soll: eine T-Kreuzung und ein Gebäudekomplex im Halbkreis. Das Bild hat drei Farben. (Die vierte Farbe ist Blau für den Himmel.) Die Auflösung beträgt 160x152 Pixel, was schöne dicke Linien erzeugt. Und jetzt stell Dir mal vor, da wären nicht nur die paar Linien zu sehen, sondern 1000. Was könnte man dann in dieser Auflösung noch erkennen?
wenn es an der Mathematik scheitern sollte, dann wird die 3D-Karte eben gleichzeitig eine FPU
Das Zahlenformat hat doch gar nichts damit zu tun. Du kannst mit Fixpunktdarstellung jedwede Graphik erzeugen, wie Du willst. Und an der Mathematik ist auch noch keiner gescheitert.
-
Ich kenne mich nur ganz allgemein mit der Materie aus und habe das mal so gehört. Wikipedia sagt im Physics-Engine Artikel dazu:
"Hardware acceleration for physics processing is now usually provided by graphics processing units that support more general computation, a concept known as General Purpose processing on Graphics Processing Unit. AMD and NVIDIA provide support for rigid body dynamics computations on their latest graphics cards.NVIDIA's GeForce 8 Series supports a GPU-based Newtonian physics acceleration technology named Quantum Effects Technology. NVIDIA provides an SDK Toolkit for CUDA (Compute Unified Device Architecture) technology that offers both a low and high-level API to the GPU. For their GPUs, AMD offers a similar SDK, called Close to Metal (CTM), which provides a thin hardware interface.
PhysX is an example of a physics engine that can use GPGPU based hardware acceleration when it is available."
Naja, natürlich ist einiges davon möglich, und Demos dafür gibts immer wieder.
In der Praxis macht aber die meiste Arbeit schon immer noch die CPU. Und welches Spiel will schon eine NVIDIA Karte vorraussetzen?
Meistens ist es aber ganz einfach so das die GPU komplett ausgelastet ist mir rendern, und evtl. der einen oder anderen physikalischen Simulation z.b. von Haaren. Aber komplette Physiksimulation einer Spielwelt macht man nicht auf einer GPU, weil sie dafür auch gar nicht geeignet ist.
Und ja, ich kenn mich da schon aus, von Berufswegen. -
Die 2D Lösung ist mir da viel sympathischer.
Mir auch. Bei Hardware-unterstütztem 3D habe ich immer den Eindruck, dass einem beim Programmieren die Kontrolle entgleitet. Im Gegensatz zu Software-gerendertem 3D. Ganz grosses Kino, was M.J. da noch so alles rausholt. Pseudo-3D wie in Arcade-Racern ist aber auch sehr interessant. -
Ein Dragon's Lair-Modul wäre doch mal was. Eine Alpah-Version mit den kompletten Videos gibt es bereits, allerdings auf zig REU-Images verteilt.
Ich persönlich bin ja kein besonders großer Dragon's Lair Fan (obwohl es mich damals in der Spielhalle natürlich optisch beeindruckt hat). Für mich ist das kein Spiel, sondern ein Interaktiver Film. Dafür braucht man nur einen Bildplattenspieler und ein bisschen Elektronik. Das Abspielen von Video wäre ohnehin nicht die Hauptkompetenz eines 3D-Beschleunigers.
Meistens ist es aber ganz einfach so das die GPU komplett ausgelastet ist mir rendern, und evtl. der einen oder anderen physikalischen Simulation z.b. von Haaren. Aber komplette Physiksimulation einer Spielwelt macht man nicht auf einer GPU, weil sie dafür auch gar nicht geeignet ist.
OK, ich als Laie verlasse mich natürlich bei Themen, mit denen ich mich nur am Rande befasse, durchaus auf Wikipedia. Aber ich werde mich ab jetzt auf deine Expertise verlassen und immer behaupten, dass Physik-Engines Aufgabe der CPU sind und nicht der GPU. Das ist jetzt für dieses Thema aber ohnehin nicht ganz so zentral.
Mit Matrizen rechne ich auf dem 6502 schon seit damals[tm], weil es am einfachsten ist.
Das sind natürlich die Sachen, die bei Nutzung der Karte für dich wegfallen würden. Vielleicht ist es auch das, was dir Unbehagen bereitet. Gerade der 3D-Kram wäre dann komplett anders. Aber Elite ist ja z.B. auch eine Wirtschaftssimulation – der ganze Kram bliebe natürlich auf dem 6510.
Es geht mir nicht um die Geschwindigkeit, sondern darum, daß man die Graphikausgabe nicht einfach vom Rest des Programms abspalten kann. Diese Trennung existiert so einfach nicht. Selbst wenn die ganze Graphikausgabe auf die Karte ausgelagert wird, braucht man trotzdem weiterhin jede Menge Multiplikations-, Wurzel- und sonstwas-Routinen, mit denen man die Bewegungen der Objekte im Raum berechnet.
Vielleicht entspricht meine Vorstellung, von dem, was eine 3D-Karte tut, ja einfach nicht der Realität oder halt deiner Vorstellung. Aber genau diese ganzen Raum-Berechnung würde ich doch auf der 3D-Karte tun. Es ist eine 3D-Unterstützungs-Karte, keine Grafikkarte zur Darstellung. Letzteres macht immer noch der VIC.
Der nächste Gedankenschritt war daher, auch die Raumbewegungen auf die Karte auszulagern. [...] Ein 3d-Objekt besteht nicht nur aus dem Polygon Mesh, sondern zahlreichen weiteren Attributen. Für eine Steuerung brauchst Du z. B. die aktuelle Drehgeschwindigkeit, die maximale Drehgeschwindigkeit, die gewünschte Drehgeschwindigkeit, die Stärke des Zuwachses der Drehgeschwindigkeit, die Fluggeschwindigkeit, die maximale Fluggeschwindigkeit, die gewünschte Fluggeschwindigkeit, der Energieverbrauch bei einer Beschleunigung, der aktuelle Energiestand, der maximale Energiestand blablablablabla...
Damit eine Physikengine ein Objekt bearbeiten kann, benötigt es nahezu alle Attribute eines Objekts. Das aber bedeutet, daß die Objekte sich auf der Karte selbst befinden müssen und nicht mehr im C64-Speicher, denn ansonsten müßte man pro Bild einen Riesenhaufen an Daten auf die Karte schaufeln. Der Endeffekt dabei ist notgedrungen, daß dann sämtliche Berechnung nur noch auf der Karte stattfindet in ARM-Assembler oder sonstwas, aber nicht mehr auf dem 6502.Genau das ist meine Vorstellung. Jetzt kommen wir auf eine Linie. Ich will ja gerade dem 6510 unter die Arme greifen, wo er seine Schwachstellen hat. Und das scheint ja bei den 3D-Raumberechnungen (u.a. wegen Multiplikationen) zu sein.
Es gibt aber auch 3D-Darstellung abseits von Elite. Z.B. ist bei einem Autorennen das Gewicht eines heran rauschenden Baumes oder Hauses komplett egal. Wer es auf die Spitze treiben will, könnte ein paar Physikberechnungen für Gegner-Autos machen aber es ginge wahrscheinlich auch ohne. In den meisten 3D-Rennen fahren die Gegner brav in ihrer Spur und die Neuberechnung betrifft eigentlich nur die aktuelle Position des eigenen Autos auf der Rennbahn.
Übrigens ist meine Vorstellung nicht, dass der werte Spiele-Programmierer dann ARM-Code für die 3D-Berechnungen schreiben müsste. Ich habe von Anfang an gesagt, dass jemand eine Software-3D-Karte auf dem ARM schreiben müsste. Diese würde dann natürlich komfortabel (und kompakt) vom C64-Programmierer angesprochen werden. Stell dir also vor, es gäbe so eine Art OpenGL/ES (aber mit ganz knappen Befehlen/Beschreibungen). Du schickst die Objektdaten zur Karte und sagst: jetzt das Raumschiff ein bisschen weiter nach links – rendern, ab zum VIC.
Die Datenmengen, die dabei verarbeitet werden, das Programm, das man dazu auf einem ARM (oder sonstwas) schreiben muß, all das hat mit C64 nichts, aber auch rein gar nichts mehr zu tun. Das ist nur noch ein Modul, das man in den C64 steckt, damit die Ausgabe sinnloserweise über den VIC läuft.
Das sehe ich anders. Das ganze drumherum läuft doch immer noch auf dem C64 – nur die 3D-Berechnungen werden ausgelagert. Da könntest du auch sagen, heutige Spiele würden nicht auf Intel laufen, sondern halt auf AMD/Nvidia. Auch wenn das so sein sollte, so interessiert das den Spieler doch nicht. Das Spiel läuft auf seinem PC, egal welcher Chip die Hauptarbeit macht.
Ich finde es viel "unfairer", wenn ein Spiel von einem Turbo Chameleon profitiert, dass einen kompletten C64 (optional in schnell) nachbildet und auch wunderbar ohne ihn (autark) funktioniert (was bei der angedachten 3D-Karte nicht der Fall ist, da sie den 6510 nur unterstützen soll).
Irgendwie muss ich damals im Urlaub gewesen sein, als die ersten 3D-Karten (Voodoo... ) auf den Markt kamen und alle stöhnten: Das ist doch kein PC mehr und überhaupt, viel zu viele Polygone, da weiß man ja gar nicht mehr, wo man hingucken soll.
Schau Dir mal das folgende Bild aus "Mercenary" an: [...] Und jetzt stell Dir mal vor, da wären nicht nur die paar Linien zu sehen, sondern 1000. Was könnte man dann in dieser Auflösung noch erkennen?
Wahrscheinlich nicht viel. Aber wer würde schon mit einer 3D-Karte Wireframes inkl. eigentlich verdeckter Linien rendern? Ich dachte (etwas übertrieben) eigentlich eher an sowas:
Edit: Ich habe die Bilder nochmal mit weniger Raster (jetzt im eigenen Converter) heruntergerechnet. Auch das wird einem nicht wirklich zeigen, wie ein C64-3D-Spiel mit 3D-Karten-Unterstützung aussehen würde – aber es sollte klar werden, dass wir nicht mehr über einzelne Linien reden.
Edit2: Bei den beiden Beispielen würde die 3D-Karte nicht alles selber berechnen. Den unteren Teil des Cockpits z.B. würde der C64 alleine "malen" und nur der obere Teil käme aus der 3D-Karte. Dabei würden die Fernster-Umrahmungen als handgepixeltes Overlay darübergelegt werden, bevor die Daten zum VIC geschickt würden. Ähnliches könnte man sich bei "Croc" vorstellen. Die 3D-Karte bekäme eine Maske für den Protagonisten mitgeliefert, sodass er nicht von ihr gerendert würde. Der C64 stellt die Spielfigur mit Sprites dar und später würde die 3D-Karte beim rein-rendern in den VIC die Figur aussparen.
