letzter Beitrag von Retrofan am
Bei lemon gibt es ein Projekt für ein Modul zur Grafikbeschleunigung:
http://www.lemon64.com/forum/viewtopic.php?t=60664
Vermutlich wäre die billigste Lösung so ein Bluepill ARM Board anzuschließen. Kann man ja ggf bisserl hochtakten, dann sollte das schon flott Linien malen können und so.
Bei lemon gibt es ein Projekt für ein Modul zur Grafikbeschleunigung
Da geht es zwar "nur" um eine 2D-Scrolling-Beschleunigung (und nicht um eine 3D-Erweiterung) aber hardwaretechnisch könnte es in eine ähnliche Richtung gehen. Wobei ich nicht weiß, ob für eine 3D-Karte ein FPGA das richtige wäre oder ob man nicht eher auf Software und einen schnell getakteten ARM-SOC setzen sollte. So ein Raspi Zero taktet mit 1 GHz und kostet 5 bis 10€.
Ui, und die Grafikausgabe läuft dann immer noch (parallel) über den VIC-II oder nur über den VGA-Port des TC64?
Natürlich. Der VIC-II bekommt seine Daten aus dem Modul. Der C64-interne RAM wird nicht genutzt.
Hier ist das Teil ganz gut dokumentiert: http://wiki.icomp.de/wiki/Chameleon#Developer_Information
das Bild zuerst (horizontal) auf die doppelte Auflösung (Hires, 320 x 200) gerendert und dann erst das Bild auf 160 x 200 Pixel reduziert.
Witzigerweise habe ich bei O.O.B. bereits einen HiRes-Renderer (max 320x200) eingebaut. Erst beim Malen werden die Pixel mittels Masken auf 160x200 reduziert. Es gibt in dem Spiel sogar die (bei der Demo nicht freigeschaltete) Option, die 3d-Ausgabe in Monochrome-HiRes anzeigen zu lassen anstelle von Multicolour. Als einziges Problem sehe ich die beschränkte Anzahl von 4 Farben im Multicolourmodus. Setzt man eine Farbe als Hintergrundfarbe, eine Farbe als Vordergrundfarbe, so verbleibt eine Mischfarbe aus Hintergrund und Vordergrund für das Anti-Aliasing sowie eine weitere Farbe, für die aber keine Mischfarbe mehr existiert. Anti-Aliasing würde sich dann nur auf das Malen von einer Farbe direkt vor einem Hintergrund auswirken können. Da man aber aus Farbmangel alle 4 Farben für ein Dithering benötigt, wüßte ich nicht, wie man zwischen all den Kanten ein vernünftiges Anti-Aliasing erzeugen könnte. 
Wenn man also wirklich 3D auf dem C64 machen will, wäre es dann nicht eine Überlegung wert, einen 3D-Booster zu konzipieren, eine art Voodoo64?
Da bin ich ein wenig skeptisch, was die Machbarkeit anbelangt. Ein 3d-Spiel besteht ja aus vielen Teilen, als da wären:
1.) Bewegung und Animation von Objekten in der Welt. (sehr aufwendig)
2.) Festlegen einer Kameraposition und Umrechnung aller Weltkoordinaten und -matrizen auf Kamerakoordinaten bzw. -matrizen. (ebenfalls sehr rechenintensiv)
3.) Berechnung der Kamerasicht.
Welche Teile sollte solch eine 3d-Karte jetzt erfassen? Nur den letzten Schritt (Rendering) oder auch den zweiten, da der ja irgendwie zum Rendering dazugehört? Warum dann nicht auch die Bewegung im Raum? Schließlich kommen auch hier Rotationen und Matrizenmultiplikationen vor.
Selbst wenn man sich jetzt darauf einigen sollte, ab welchem Schritt die Karte unterstützend wirken soll, gibt es das nächste Problem: Welchen Standard verwendet man überhaupt? Die 3d-Spiele, die man so vom C64 kennt, verwenden alle eine vollständig andere Herangehensweise und haben intern allesamt verschiedene Zahlenformate zur Repräsentation von Koordinaten und Matrizen. Worauf soll man sich einigen? 16 Bit ("Driller"), 24 Bit ("Elite", "Mercenary") oder gar Fließkommazahlen? Und in welcher Form? 8:8, 16:8, 24:0, float, 5-Byte-Basicformat oder double? Und was ist mit der Matrix? Nimmt man die klassische Homecomputer 3x3-Matrix oder doch die moderne 4x4? Welcher Wert repräsentiert 1? $c000? $4000? $ffff? 1.0 float? Welche Graphikdaten sollen am Ende ausgespuckt werden? Nur Bitmap oder auch verkleinerte Sprites ("Test Drive", "Koronis Rift")? Zeichensatzgraphik oder Hires-Bitmap oder Multicolour-Bitmap?
Meine Befürchtung ist, daß auf dem C64 aufgrund der Bandbreite der verschiedensten Rechenverfahren eine für alle Ansprüche normierte Schnittstelle nicht möglich ist, zumal einige Spiele auch eher so eine Art Mischung aus 3d und Pseudo-3d sind (z. B. "Test Drive"). Ein Art verbindlicher OpenGL-Standard rückt damit in weite Ferne. Um der Flexibilität der C64-Software weiter gerecht zu werden, würde ich daher eine allgemeine vom Programmierer kontrollierte Beschleunigung vorziehen.
Interessant in dieser Hinsicht finde ich, was Daybyter ein paar Seiten früher vorgeschlagen hat: Ein Steckmodul mit FPGA, welches mit verschiedenen Cores gefüttert werden kann. Das könnte man wahlweise als Z80-CP/M-Modul einsetzen, als 6502-Beschleuniger, als 65816 (= SCPU) oder was einem auch immer so einfällt. Es würde meiner Ansicht nach auch nicht das C64-Feeling zerstören, da es sowohl ein CP/M-Modul als auch eine SCPU bereits früher schon mal gab. (Und keines von denen hat den C64 zerstört.) Desweiteren hatte ich mich in einem anderen Thread mal über die (meiner persönlichen Meinung nach) unzureichenden neuen Befehle des 65CE02 vom C65 beklagt. Solch ein Modul gäbe mal die Möglichkeit andere Formen der Befehlserweiterung (z. B. ein Befehl zur Multiplikation) auszutesten. Sowas bliebe eine individuelle Bastelei und damit ohne die so oft beschworene Gefahr, die C64-Szene zu spalten. Und als Modul hat es den Vorteil, wie ZeroZero meinte, daß man dafür seinen C64 nicht öffnen muß.
Weißt du vieleicht auch, wieviel Speicherplatz die Musik belegt?
Leider nein. Ich hatte mich in der Vergangenheit vornehmlich mit der AppleII-Version beschäftigt, die aufgrund der überragenden Soundfähigkeiten des AppleIIs über keine Melodie verfügt.
Nur als Ergänzung:
$700..$9ff = Zeichensatz (von CHR(32) bis CHR(255))
$d000 = Liste der Anfangsadressen der Objektmaldaten gefolgt von den Daten selbst
Und noch was Anderes. Mit Hilfe der vorher beschriebenen Lücke in der Speicheraufteilung der C64-Eliteversion habe ich die deutsche Version so abgeändert, daß die Objekte (nicht Planeten, da diese anders berechnet werden) nicht immer zuerst komplett gelöscht und dann neu gezeichnet werden, sondern dieser Prozeß alternierend stattfindet, was das Flimmern unterdrückt. Das kann u. U. dazu führen, daß die Bewegungen etwas ruckelig erscheinen, aber das soll jeder für sich selbst beurteilen. Als weitere Patches habe ich zur Erhöhung der Rechengenauigkeit die erweiterte Logarithmentabelle aus der ersten englischen C64-Version wieder ergänzt und die zentralen Multiplikations- und Divisionsroutinen daran angepaßt, sowie für die Division der Rotationsmatrix vor dem Malen (fragt nicht...) eine genauere Tabelle integriert. Achtung: Es handelt sich hierbei um eine erste Probeversion. Ich kann keine Garantie übernehmen, daß es aufgrund der Patches nicht irgendwo zu Nebeneffekten kommt. Wer mag, kann diese Version also austesten und dann bitte kommentieren. Danke.
M.J. : das z80 Modul hat deshalb nix kaputt gemacht, weil es ja fast keiner gekauft hat!
Ich war einer der wenigen dummen... 
Guck Dir mal meinen Mini-Thread zum Upduino an. Da findest paar Infos zu dem Lattice billig-FPGA. Das könnte meiner Meinung nach ein Start für sowas sein. Nur die Levelshifter halt...
Mit Hilfe der vorher beschriebenen Lücke in der Speicheraufteilung der C64-Eliteversion habe ich die deutsche Version so abgeändert, daß die Objekte (nicht Planeten, da diese anders berechnet werden) nicht immer zuerst komplett gelöscht und dann neu gezeichnet werden, sondern dieser Prozeß alternierend stattfindet, was das Flimmern unterdrückt. Das kann u. U. dazu führen, daß die Bewegungen etwas ruckelig erscheinen, aber das soll jeder für sich selbst beurteilen.
Klasse, gefällt mir. Haben die Planette eigentlich neben der Optik noch andere Funktionen? Und falls es nicht zu aufwendig ist, könntest du zu Testzwecken auch eine Version erstellen, wo Planeten gar nicht berechnet und/oder gezeichnet werden?
Nur die Levelshifter halt...
Was genau ist denn da das Problem? So wie ich das mitbekommen haben, passen die Spannungen nicht. Oder ist es noch komplizierter?
Als einziges Problem sehe ich die beschränkte Anzahl von 4 Farben im Multicolourmodus.
Natürlich ist das eine Einschränkung. Aber Kantenglättung benötigt man vor allem bei hohen Kontrasten, weil dann die Jaggies besonders unangenehm auffallen. Angenommen, man würde schwarz als Hintergrund nehmen und weiß, Hellblau und Blau als weitere Farben (wobei ich das je Objekt definieren würde und nicht global. Solange es keine Überschneidungen gibt, gibt es keine Probleme). Blau ist eine der beiden dunkelsten Farben (wenn man von Schwarz absieht), daher kann man natürlich zum Kantenglätten nicht dunkler werden – außer ein Blau-Schwarz-Raster wäre per Definition eine "dunklere Farbe". Immer wenn es eine Farbe (Helligkeit) zwischen 2 anderen gibt, kann man auch kantenglätten. Und ein Raster wäre immer noch besser als gar keine Glättung. Also, zu schwarz kann jede Farbe (außer der von der Helligkeit am nächsten liegenden) kantengeglättet werden, und genauso zu weiß. Das Ergebnis ist auf jeden Fall immer besser als ohne Kantenglättung. Nut kostet es halt Rechenzeit. Bei weiteren Recherchen ist mir aber aufgefallen, dass es heutzutage schnellere Kantenglättungs-Verfahren gibt als FSAA, vor allem MSAA. Sollte das aber die "Grafikkarte" machen, kann es dem Spiele-Entwickler egal sein, wie die Kanten geglättet werden.
Edit: Ich habe deinen Beitrag nochmal gelesen: Nein, die Kantenglättungs-Farben wären doch nicht exklusiv zum Glätten da, sondern das sind die Farben, die auch für die Objekte verwendet werden! Du hättest deswegen nicht weniger Farben zur Verfügung.
Selbst wenn man sich jetzt darauf einigen sollte, ab welchem Schritt die Karte unterstützend wirken soll, gibt es das nächste Problem: Welchen Standard verwendet man überhaupt?
Naja, den, den der erste Programmierer eines Spiels für die 3D-Karte halt definiert und den er vielleicht mit anderen – vor allem dem, der die Grafikkarte entwickelt – bespricht.
Interessant in dieser Hinsicht finde ich, was Daybyter ein paar Seiten früher vorgeschlagen hat: Ein Steckmodul mit FPGA, welches mit verschiedenen Cores gefüttert werden kann. Das könnte man wahlweise als Z80-CP/M-Modul einsetzen, als 6502-Beschleuniger, als 65816 (= SCPU) oder was einem auch immer so einfällt.
Klingt auch gut. Die Frage ist nur, wie oft man wirklich im Endeffekt den Core wechseln mag. Das Turbo Chameleon kennt auch ein halbes Dutzend Cores – und wie oft wechseln die User diesen? Soll man vor jeder 2. App erst einen anderen Core in das Modul einspielen? Oder soll man einen Mechanismus entwickeln, der das transparent im Hintergrund tut?
M.J. : das z80 Modul hat deshalb nix kaputt gemacht, weil es ja fast keiner gekauft hat!
Da ist viel Wahres dran. Der C64-Modus des C128 war so überzeugend, dass es nur wenig dedizierte C128-Software gab. Wenn ein alternativer Modus erfolgreich ist, wirkt sich das zwangsläufig auf die Attraktivität des Haupt-Modus aus. Wäre der C64 ein guter Z80/CPM-Rechner gewesen, wäre er kein so guter C64 gewesen.
-----
Ich sehe , dass der einzige Entwickler, der z.Z. ein 3D-Spiel für einen Hardware-beschleunigten C64 entwickeln will, die Idee einer C64-3D-Karte eher skeptisch sieht. Daher sollte man die Idee als gestorben ansehen – ich will nicht ein weiteres mal irgendwelche hochtrabenden Ideen, die ich selbst nicht realisieren kann, gegen Widerstände verteidigen müssen. Seht den 3D-Booster nur als lustige Anekdote am Rande des Hauptstrangs an – auf den wir uns jetzt wieder konzentrieren können.
Was genau ist denn da das Problem? So wie ich das mitbekommen haben, passen die Spannungen nicht. Oder ist es noch komplizierter?
Nö, es sind nur die Spannungen. Es gibt ja anscheinend keine FPGAs die 5V vertragen. Also muss mal alle Adress- und Datenleitungen (und die paar Statusleitungen) von 5V runterbringen auf die Spannung, die das FPGA mag. Und natürlich die andere Richtung.
Das sind 16 Adress-, 8 Daten- und paar Statusleitungen. Also so 30 birektionale Levelshifter. Und die sollten auf so ne kleine Prototypenplatine...
Als einziges Problem sehe ich die beschränkte Anzahl von 4 Farben im Multicolourmodus. Setzt man eine Farbe als Hintergrundfarbe, eine Farbe als Vordergrundfarbe, so verbleibt eine Mischfarbe aus Hintergrund und Vordergrund für das Anti-Aliasing sowie eine weitere Farbe, für die aber keine Mischfarbe mehr existiert.
Ergänzend zu meinem Edit oben: Du missverstehst meinen Ansatz. Du kannst weiterhin jede (oder meinetwegen jede der vier) Farbe(n) verwenden. Die Kantenglättungs-Farben sind nicht exklusiv reserviert sondern ergeben sich aus der Verrechnung von 2 Kanten-Farben, die bei der Reduktion auf eine verschmelzen. Man könnte (wenn man alle 16 Farben nimmt) 16x16/2=128 Reduktions-Kombinationen definieren (bei 4 Farben wären es nur 4x4/2=8 Kombinationen). Wenn also bei der Halbierung der Auflösung die beiden jeweils zusammengelegten Pixel eine identische Farbe hatten, bleibt die erhalten, hatten sie unterschiedliche Farben, musst du nur in der Tabelle nachgucken, welche Farbe sich daraus ergibt. In meinem neuen Beispiel ergibt sich z.B. aus Hellblau/Schwarz das dunkle Blau, aus Grün/Schwarz Dunkelgrau, aus Weiß/Hellblau ergibt sich Cyan und aus Hellblau/Cyan auch Cyan (da es keinen passenden Zwischenton gibt).
Bild 1 zeigt die Szene in Multicolor ohne FSAA. Bild 2 zeigt die Szene in Hires-Auflösung, die so nicht darstellbar wäre (wegen zu vieler Farben) aber als Zwischenschritt benötigt wird. Bild 3 zeigt das kantengeglättete Ergebnis, wenn man aus dem hochauflösenden Bild per Oversampling das Multicolor-Bild erzeugt.
Da ich im Gegensatz zum klassischen FSAA-Oversampling das Bild nur verdoppele und nicht vervierfache, haben wir kein 2x FSAA, sondern quasi nur 1.5x FSAA, denn in der Vertikalen werden keine Kanten geglättet (da dort weniger nötig).
(Das letzte Bild habe ich in den Anhang als PRG gepackt)
---
Obwohl ich den 3D-Booster (der nichts mit der Kantenglättung zu tun hat) ja schon aufgeben habe, hier trotzdem noch ein paar Antworten, um meine ursprüngliche Idee besser zu verdeutlichen:
Welche Graphikdaten sollen am Ende ausgespuckt werden? Nur Bitmap oder auch verkleinerte Sprites ("Test Drive", "Koronis Rift")? Zeichensatzgraphik oder Hires-Bitmap oder Multicolour-Bitmap?
Wenn man es sehr komfortabel halten möchte, könnte man das der 3D-Karte doch vorher mitteilen. Man muss ohnehin sagen, wo die Szene auf dem Screen beginnen soll und wie groß sie sein soll. Man könnte auch maskierende Grafiken mitgeben, um z.B. Cockpit-Fensterrahmen etc. gleich mit in das Ergebnis rechnen zu lassen. Sprites würde ich erst einmal ausschließen wollen – das sollte der C64 alleine machen.
Meine Befürchtung ist, daß auf dem C64 aufgrund der Bandbreite der verschiedensten Rechenverfahren eine für alle Ansprüche normierte Schnittstelle nicht möglich ist, zumal einige Spiele auch eher so eine Art Mischung aus 3d und Pseudo-3d sind (z. B. "Test Drive").
Ich wollte nie einen 3D-Booster für existierende Spiele "erfinden", sondern natürlich nur für neue Spiele. Und da definiert man halt eine möglichst flexible Schnittstelle mit allen Optionen, die man sich als Entwickler wünscht und lebt danach damit, was man sich ausgedacht hat. Im 8Bit-Homecomputer-Bereich wäre so eine 3D-Karte meines Wissens ein Novum – da muss man sich an keinen existierenden Standard halten. Und wie weit man das ganze treiben will, muss man sich halt überlegen. Im Prinzip wären Textur-Transformationen etc. durchaus denkbar (bei einem 1GHz-Raspi) und dann würde einem Doom oder Wolfenstein auf dem C64 nichts mehr im Wege stehen. Es ist halt nur die Frage, wie weit man gehen möchte – weniger ist manchmal auch mehr.
Elite:
Ich fände es jetzt kein Sakrileg, auf den gezeichneten Rahmen zu verzichten. 32*24 Zeichen würden auch Hires im Cockpit erlauben, bestimmt kein Schaden. Andererseits wäre das aber vermutlich viel Aufwand im Umbau und somit wäre die Frage, ob es nicht gleich ein neues Spiel werden sollte.
Unter Adreßumrechnungen kann ich mir nichts vorstellen. Falls Du damit Adreßtabellen meinst wie z. B. für die Anfangsadressen einer Bildschirmzeile, so wäre die Handhabung viel zu langsam, denn Adressen bestehen aus 2 Bytes.
Ich hatte nichts bestimmtes im Auge, sondern generell Umrechnungen von 2 8Bit-Werten, für die man sich sonst den Speicher nicht gönnt, egal ob das nun Multiplikation (*8 =16 Bit wäre oder sowas wie YPos+8*XPos.
Ja, so ungefähr, jedoch würde ich die Linienberechnung gleichzeitig beim Füllen des Polygons vornehmen. Das Speichern der linken und rechten Grenze in ein Array und nachträgliches Wiederhervorkramen dürfte langsamer sein als eine Berechnung on-the-fly.
Das wiederum klingt für mich, als ob man viele Register retten und wiederherstellen müsste. Vielleicht reicht ja meine Motivation, mal wieder was zu programmieren, im Moment bin ich jedenfalls gefesselt 
Das Ziehen zweier Linien gleichzeitig wäre aufgrund der möglichen großen Differenzen in der Länge mit zuviel Overhead verbunden, als daß es sich lohnen könnte.
Ich meinte linke und rechte Linie zur Begrenzung des Dreiecks.
2 Linien zeichnen könnte vielleicht beim 65816 nützlich sein. Andererseits müsste sich die SCPU für solche Speicherzugriffe glaub ich eh mit 1 MHz synchronisieren...
Aber bei sehr großen Flächen könnte man mit halber Auflösung rechnen, da könnte man dann auch 2 Linien ziehen.
Die Methode, nur die ausgesuchten Bereiche des Bildschirms zu löschen, die vorher gemalt worden sind, sieht zu Beginn recht praktisch und vor allen Dingen schnell aus. Tatsächlich ist sie aber zu kompliziert und im Mittel auch zu langsam.Der Nachteil hierbei ist, daß in zwei Listen jeweils für beide Bitmaps des Double-Bufferings die Rechtecke festgehalten werden müssen. Diese Rechtecke könnten sich z. B. ergeben aus den Grenzwerten aller Polygone eines Objekts. Dafür müssen also erst einmal diese Grenzwerte ermittelt werden.
Ein Minmax über die paar Punkte eines Objekts dürfte jetzt keinen Umbringen.
Beim Löschen der Rechtecke sieht man sich wieder mit dem ungünstigen Speicheraufbau der Bitmap konfrontiert.
Entfällt bei Zeichensatz von 32 Chars breite.
Als weiterer Nachteil kommt noch hinzu, daß unter Umständen Bildschirmbereiche doppelt gelöscht werden, weil zwei Objekte hintereinander stehen...
Von daher wäre es wahrscheinlich einfacher, man würde sich nicht die linken und rechten Grenzen merken, sondern allein die obere und untere und die dann auch nur für alle 8 Zeilen (also blockweise). Dann hätte man eine Löschschleife, die mittels "STA abs, y" den Bildschirm direkt löschen kann, ohne das Y-Register stets neu setzen zu müssen. Der Einsprungspunkt und der Endpunkt mittels RTS würden dabei gepatcht werden, also...
Ja, so eine Art von Patch hatte ich mal für schnelle waagerechte Linien gemacht. Ist aber ewig her.
Evtl. lohnt sich auch eine Löschroutine, die mehrere Objekte im Auge behält und je Charzeile linken und rechten Rand neu festlegt.
Ob das aber am Ende wirklich viel bringt, glaube ich nicht, besonders dann nicht, wenn sehr viele verteilte Objekte auf dem Bildschirm zu sehen sind (nicht zu vergessen auch die Sterne bei einem Weltraumspiel)
Hier fehlt mir einfach ein Gefühl, wie viele Sterne und Objekte man erwarten muss. Die Sterne könnten dem aber das Genick brechen.
Witzigerweise habe ich bei O.O.B. bereits einen HiRes-Renderer (max 320x200) eingebaut. Erst beim Malen werden die Pixel mittels Masken auf 160x200 reduziert.
Dann reicht es doch, bei Anfang und Endpunkt auf ungerade Koordinaten zu prüfen? Im einfachsten Fall setzt man dann einfach einen Punkt in dunkelster Farbe, Alternativ prüft man, ob an der Stelle schon ein Pixel ist.
...Worauf soll man sich einigen? 16 Bit ("Driller"), 24 Bit ("Elite", "Mercenary") oder gar Fließkommazahlen? Und in welcher Form? 8:8, 16:8, 24:0, float, 5-Byte-Basicformat oder double? Und was ist mit der Matrix?
Ist das bei Festkomma-Formaten nicht eh egal? 24Bit, und wem das zu genau ist, der benutzt halt nur 16? Und für den Rest gilt: Es wird gegessen, was auf den Tisch kommt 
Wenn das Gerät die Matrix-Multiplikationen und ein Mappen in sinnvolle Bildschirmkoordinaten übernimmt, dann wird man sich an dessen Format anpassen.
Andererseits: Wenn es eh auf einen ARM mit 1GHz am Export hinausläuft und alles in dessen Sprache programmieren kann, dann kann man eh alles vergessen, worüber man sich am C64 den Kopf zerbrechen musste.
Das wiederum klingt für mich, als ob man viele Register retten und wiederherstellen müsste.
Ja, sicherlich, aber das muß man während des Malens sowieso und fällt von daher nicht weiter ins Gewicht. Wichtiger ist, daß eine Tabelle für den linken und rechten Rand mittels "abs, x/y" adressiert werden müßte, wohingegen man beim on-the-fly-Ansatz mit einer Variablen auf der Zeropage auskommt. Beim AppleII konnte ich den Teil zur Linienberechnung sogar so umbauen, daß nicht allein der X-Wert, sondern gleich die Bitmaske für den Rand sowie der Offset auf die Zeile berechnet werden. Das spart dann reichlich Rechenzeit.
Entfällt bei Zeichensatz von 32 Chars breite.
Sofern man die 3d-Ansicht wirklich nur auf 256 Pixel beschränken will. Mir persönlich hat die breitere Darstellung (160/320 X-Pixel) von "Mercenary", "Koronis Rift" oder "Flugsimulator II" da besser gefallen.
Ein Minmax über die paar Punkte eines Objekts dürfte jetzt keinen Umbringen.
Unterschätze den Aufwand nicht, denn auch ein Minimax kostet. Dazu benötigst Du eine Schleife über die Punkte und - da die Punkte als 16-Bit-Werte vorliegen - einen 16-Bit-Vergleich, also sowas wie (ungetestet):
Das sieht harmlos aus, aber bei einem komplexen Modell wie die "Cobra MkIII" mit 28 Punkten summiert sich da einiges auf. (Günstigster Fall = 979 Taktzyken = 195 * STA abs, y) Dumm ist nur, daß es nicht einmal so einfach funktioniert, sobald man Z-Clipping mit hinzunehmen möchte. Welcher Wert dann entsteht hängt ganz vom Ergebnis des Clippings ab. Am besten wäre es, wenn man die Überprüfung erst beim Polygonmalen selbst vornimmt, aber auch da entsteht immer noch ein kleiner Overhead.
Hier fehlt mir einfach ein Gefühl, wie viele Sterne und Objekte man erwarten muss. Die Sterne könnten dem aber das Genick brechen.
Ich habe mal "Space Rogue" gestartet und willkürlich einen Screenshot gemacht.
Wie man sieht, gibt es sechs Sterne verschiedener Größe, die als Rechteck gedacht bereits einen großen Teil des Bildschirms bedecken. Fliegt man in ein Asteroidenfeld (oder einen Ionensturm etc), werden die Sterne ersetzt durch noch größere Gebilde:
Bei Elite sind die Sterne recht klein, dafür aber im Mittel zahlreicher:
Nun könnte man vielleicht denken, daß die Sterne auch per Hand gelöscht werden können außerhalb der allgemeinen Löschroutine. Das jedoch wäre bei einem Double-Buffering nicht trivial und würde jede Menge zusätzlichen Code erfordern.
Am Ende muß man immer die Rechnung aufstellen: Wie gut ist das Preis-Leistungsverhältnis? Eine "Brute-Force"-Löschroutine, die immer die gesamte Anzeige löscht, mag zwar oft zuviel löschen, ist aber sehr kurz und sehr effektiv. Alle anderen Methoden verbrauchen teils wesentlich mehr Code, sind komplexer und erzeugen in den Fällen, wo die Objekte recht groß sind, einen zusätzlichen, erkennbaren Aufwand, mehr als sie in anderen Fällen an Ersparnis einbringen. Wenn man die Regel zugrunde liegt, daß die Fälle, in denen die Objekte klein sind, keine Beschleunigung gebrauchen, weil sie schon schnell genug sind, hingegen aber die Fälle, bei denen die Objekte groß sind, Beschleunigung benötigen, um nicht zu sehr aus dem Rahmen zu fallen, so spricht vieles für den Brute-Force-Ansatz. Aber auch hier gilt: Ob es wirklich spürbar was bringt, was den zusätzlichen Aufwand rechtfertigen würde, wird man wohl nur durch reichliches Austesten feststellen können.
Ist das bei Festkomma-Formaten nicht eh egal?
Mitnichten. Die Genauigkeit von Festkomma-Formaten wird häufig überschätzt. Der Standard Float ist mit seinen 4 Bytes nicht sonderlich genau, da die Mantisse für den eigentlichen Wert nur 24 Bit (inklusive Vorzeichen) erfaßt. Alle Zahlen darüber können schon nicht mehr genau erfaßt werden. Das mag für den Renderer nicht relevant sein, aber für allgemeine Bewegung im Raum schon. Weltkoordinaten sollte man (eigentlich) nie als Float speichern, da ansonsten die Gefahr besteht, daß man aufgrund der Granulation wie
bei "Star Trek" plötzlich von einer mysteriösen Kraft gefangen gehalten wird und das Raumschiff sich nicht mehr weiterbewegt.
Wenn es eh auf einen ARM mit 1GHz am Export hinausläuft und alles in dessen Sprache programmieren kann, dann kann man eh alles vergessen, worüber man sich am C64 den Kopf zerbrechen musste.
Ja, mag sein, aber das wäre für mich dann auch kein C64-Feeling mehr. Der ARM an sich ist ein schöner Prozessor, aber ich kann ihn nicht mit dem 6502 in Verbindung bringen. Am Ende läuft das dann darauf hinaus, daß das komplette Programm auf dem ARM läuft und einfach nur ein C64-ähnliches Bild erzeugt. Sowas kann man auf dem PC jetzt schon einfacher haben, würde mir aber keinen Spaß bereiten. Persönlich hätte ich daher lieber einen programmierbaren FPGA, für den man dann vielleicht einen 6502-kompatiblen Core mit Sonderbehlen erstellen kann. Damit läßt sich auch schön untersuchen, wie die Entwicklung des C64 vielleicht weitergegangen wäre, und feststellen, daß z. B. der C65 wie auch viele andere Wege schlichtweg eine Sackgasse bedeuten.
Die Frage ist nur, wie oft man wirklich im Endeffekt den Core wechseln mag.
Gute Frage. Bei einem TC64 sind die Cores ja völlig unterschiedlich, d. h. man erhält einen komplett anderen Computer. Daher dachte ich für den Dauerzustand eher an einen 6502-kompatiblen Core, mit dem man ohne Unterschiede zu bemerken jedes Programm auf dem C64 ausführen kann. Dieser Core hätte als einzige Ausnahme der Kompatibilität einen Sonderbefehl (z. B. $02), der die zusätzlichen Fähigkeiten aktiviert. (Solch ein Prozessormodell habe ich bereits in meinem AppleII-Emulator eingebaut und an dem Spiel "Elite" ausprobiert.) Ein Core-Wechsel wäre nur dann fällig, wenn man einen komplett anderen Prozessor wie den Z80 haben möchte, aber das richtet sich halt danach, was der Benutzer hauptsächlich möchte. Und zur Not könnte man sich auch zwei Module zulegen. 
Leider weiß ich selber von den Möglichkeiten eines Moduls zu wenig. Gäbe es überhaupt die Möglichkeit, daß ein Modul sofort beim Einschalten den internen 6502 abschaltet und die volle Kontrolle übernimmt (Ich nehme an, bei der SCPU wird sowas gemacht)? Wie aufwendig wäre das?
Naja, den, den der erste Programmierer eines Spiels für die 3D-Karte halt definiert
Ich wollte nie einen 3D-Booster für existierende Spiele "erfinden", sondern natürlich nur für neue Spiele. Und da definiert man halt eine möglichst flexible Schnittstelle mit allen Optionen, die man sich als Entwickler wünscht und lebt danach damit, was man sich ausgedacht hat.
So einfach ist das mMn leider nicht. Die Crux liegt darin, daß es keine allgemein verbindliche Engine für alle Spiele geben kann, Wenn der erste Programmierer sagt: Ich will eine Beschleunigung für "Wolfenstein", dann kann man nachher nur Spiele im Stil von "Wolfenstein" darauf schreiben, aber kein Weltraumspiel wie "Elite", keinen Flugsimulator usw. Dafür sind diese Programme intern in ihrer Vorgehensweise zu unterschiedlich. Ein Beschleuniger müßte hinsichtlich Input, Rechenverfahren und Output dermaßen vielen Bedingungen genügen, daß ich bezweifle, daß man dies über eine verbindliche Schnittstelle regeln kann. Daher wäre ich für die flexiblere Lösung, daß die Beschleunigung über ein eigenes Programm erreicht wird. Bei den PC-Graphikkarten konnte man übrigens ähnliches beobachten. Auch hier hat man die Grafikkarten so konstruiert, daß sie intern eigenständige Programme ablaufen lassen.
Sprites würde ich erst einmal ausschließen wollen – das sollte der C64 alleine machen.
Leider ist die automatische Verkleinerung von Sprites on-the-fly etwas, was sehr viel Rechenzeit kostet und daher bisher in Spielen kaum zum Einsatz kommt. Spiele wie "Test Drive" haben in der Regel die Sprites in ein paar Verkleinerungsstufen vorliegen, was zum einen Platz kostet, zum anderen ungenau ist.
FSAA-Oversampling
Wenn ich das richtig verstehe, bestände das Verfahren darin, zuerst alles Malen in einer großen künstlichen Bitmap vorzunehmen mit einer Auflösung von 320x200x16, dann in einem zweiten Schritt die Kanten mit Zwischenfarben zu berechnen und als letztes das so entstandene 320x200x16-Bild runterzurechenn auf 160x200x4 pro Block. Ich befürchte, damit wäre ein Turbo wie die SCPU oder ein TC64 hoffnungslos überfordert. Schwierig wird zunächst der zusätzliche Ram-Verbrauch für die Hintergrundbitmap (320x200x16 ~ 32KB), Tabellen noch gar nicht mitgerechnet. Dann müßten alle Malroutinen wegen der höheren Auflösung viermal so viel malen, d. h. Bytes setzen. Das Kantenglätten wäre schon nicht ohne, da die Bitmap zeilenweise Pixel für Pixel durchgearbeitet werden muß. Aber das Runterrechnen auf 4 Farben ist algorithmisch eine schwere Aufgabe, für die man auch auf dem PC noch lange rechnen muß. Dazu muß man z. B. die 3 häufigsten (sinnvollen) Pixelfarben pro Block ermitteln (eine Farbe ist vorgegeben) und die anderen durch diese Farben ersetzen, wobei man auch noch Fehlerverschiebungen miteinbeziehen kann usw. Mit einer 6502-Beschleunigung allein dürfte das nicht machbar sein. Dafür braucht man schon erheblich mehr Power.
Textur-Transformationen
Was ich bislang so in Demos an Texturen gesehen habe, hat mich nicht überzeugen können. Meistens wurden nur die Grautöne verwendet, und ich mußte erraten, was hier dargestellt werden soll. Ich glaube nicht, daß sich aufgrund der Farbrestriktionen des C64 hier brauchbare Ergebnisse erzielen lassen, egal wie schnell ein Beschleuniger wäre. Selbst wenn es gelingt, ein Bild auf die 4 Farben pro Block ansehnlich herunterzurechnen, bleibt das Problem, daß sich die Farbverteilung im nächsten Frame ganz anders auswirkt und die Pixel im Vergleich zum Vorbild erkennbar unterschiedlich einfärbt. Der Effekt könnte dann eine ziemlich flimmernde Animation sein.
ich will nicht ein weiteres mal irgendwelche hochtrabenden Ideen, die ich selbst nicht realisieren kann, gegen Widerstände verteidigen müssen.
Keine Sorge. Die Überlegungen zu einer Graphikkarte sind durchaus berechtigt und gehören hierher. Selbst wenn das Konzept verworfen wird, heißt es nicht, daß man durch das Nachdenken darüber nicht auch Wichtiges lernen könnte, z. B. was man wirklich haben will, wie man es umsetzen will usw.
Haben die Planette eigentlich neben der Optik noch andere Funktionen?
Ja, haben sie.
1.) Man kann auf Planeten abstürzen.
2.) Man kann sich bei Sonnen verbrennen.
3.) Man kann bei Sonnen mittels Fuel Scoop Treibstoff auftanken.
4.) Man kann angeblich bei einer Sonne die Trumbles verbrennen (ist mir aber noch nie gelungen).
5.) Der allerwichtigte Grund:
Das Sonnensystem wird nicht stets komplett berechnet. Die Raumstation existiert zu Beginn nicht, wenn man per Hyperspace in ein neues System springt. Erst wenn der Spieler sich unterhalb eines bestimmten Abstands zum Planeten befindet, wird die Station zufällig erzeugt. Dabei wird die Sonne jedoch aus der Objektliste herausgenommen und durch die Station ersetzt. Dadurch befindet sich die Station (wie auch der Planet) immer an einer bestimmten Stelle in der Objektliste, die entweder von der Sonne oder eben von der Station besetzt wird. Gibt es in einem System keinen Planeten, wird auch niemals eine Station erzeugt. Nebenbei: In der deutschen C64-Version von "Elite" verfügt die Objektliste über 10 Plätze, d. h. neben Planet und Sonne/Station können noch 8 weitere Objekte auftauchen, bevor zum Beispiel beim Abschuß einer Rakete die Meldung "Missile jammed" erscheint.
Ein Grund, die Station erst spät erscheinen zu lassen, mag sein, daß sich aufgrund vieler vorher vorgenommener Rotationen (z. B. im Kampf mit Piraten) wegen der damit verbundenen Rechenungenauigkeiten eine Verschiebung der Station ergeben könnte. Doch entscheidend ist wohl, daß bei Elite Objekte (inklusive Planeten und Sonnen) stets nur eine relative Position zum Spielerraumschiff haben. Koordinaten von Raumschiffen werden mit nur 16 Bit gespeichert und Planeten/Sonnen mit 24 Bit.
Bei O.O.B. bin ich absichtlich anders vorgegangen und lasse das ganze System in Abhängigkeit vom Weltraumsektor zu Beginn komplett generieren, d. h. mit allen Planeten, Sonnen sowie Raumstationen, die dann eine absolute Position (32 Bit) bekommen. Das ist dann allerdings auch viel rechenaufwendiger.
Weil nun bei "Elite" Planeten essentiell sind zur Simulation des Systems, läßt sich das Berechnen der Planeten auch nicht unterdrücken, nur das Malen. Dieses kann man einfach dadurch erreichen, indem man im VICE-Monitor an die Adresse $9a6a ein RTS ($60) schreibt.
@ M.J. : meine erste Idee zu Deinem 6502 kompatiblen Core wäre eher so ne Art 'Koprozessor' zum 6502 gewesen. Beim 8088 z.B. gibt es ja so 'illegale' Befehle, die dann halt der 8087 z.B. ausführt, bzw. einen Interrupt auslösen, der dann die FPU Emulation auslöst.
Hätte man am Expansion Port ein FPGA hängen, könnte es ja am Bus 'mitlauschen'. Der 6502 hat diverse NOP Befehle, von denen man ja eigentlich nur einen Einzigen braucht.
http://www.oxyron.de/html/opcodes02.html
(z.B. 0xDA, 0xEA , 0xFA usw)
Ähnlich wie beim z80 Modul könnte das FPGA dann die CPU in nen Tristate zwingen und das Programm ausführen, was danach kommt?
Problem: die 6502 würde danach an dieser Stelle weiterlaufen und ebenfalls versuchen, den Koprozessor Code auszuführen? Und das FPGA müsste erkennen, ob der Code wirklich ein Opcode ist, und nicht z.B. gerade diese Bitmap-Muster ins Videoram geschrieben wird?
Alles nicht so einfach...
Beim 8088 z.B. gibt es ja so 'illegale' Befehle, die dann halt der 8087 z.B. ausführt, bzw. einen Interrupt auslösen, der dann die FPU Emulation auslöst.
Sowas kenne ich auch vom 68000, der bei Befehlen, die mit $Fxxx beginnen (bzw. $Axxx), eine Exception auslöst. Bei meinem im AppleII-Emulator ausgetesteten Modell handelt es sich aber tatsächlich um einen vollständigen 6502-kompatiblen Core. Genauer gesagt sind sowohl die Befehle des 6502 als auch die Register eine Untermenge eines umfangreicheren Befehls- und Registersatzes. Dabei gibt der Standardmodus sogar vor, daß 6502-Befehle stets mit 1Mhz ausgeführt werden und sich eine Beschleunigung nur bei Verwendung der neuen Befehle ergibt. Dies bewirkt, daß nicht nur normale C64-Spiele, sondern auch besonders zeitkritische Routinen wie Rasterinterrupts mit der gleichen Geschwindigkeit ausgeführt werden wie üblich. Ein Umschalten in einen Extramodus wird dadurch überflüssig. Auch beim Lesen und Schreiben von Speicherinhalten ergeben sich Unterschiede. 6502-Befehle verwenden die EInstellungen von $01 und können den IO-Bereich verwenden, wohingegen die neuen Befehle sich stets nur auf das RAM beziehen. Das erleichtert die Anbindung der Chips und bewirkt gleichzeitig, daß man auf den 6502 an sich nicht verzichten kann.
Gedacht war dieses Modell, um mittels Patchen einen eher behutsamen Einfluß auf bestehende 6502-Programme auszuüben, um so das AppleII- bzw. C64-Feeling zu erhalten und die Anpassung von Programmen zu erleichtern. Bei der SCPU oder beim TC64 sieht man ja, was eine zu starke Beschleunigung bewirken kann: Viele Spiele werden unbrauchbar, und das Timing geht kaputt. Wenn man also schon patchen muß, damit ein Programm mit Beschleunigung spielbar bleibt, sollte man es gezielt vornehmen können. Die Programmierung dafür sieht dann bei diesem Modell so aus, daß zu Beginn im externen Ram (d. h. nicht in den 64kb des C64) eine Sprungtabelle erzeugt wird und das Programm an bestimmten Stellen mit einem Sprung über diese Sprungtabelle in die Routinen zur Beschleunigung versehen wird. Da dieser Sprung aus Sicht des 6502 nur ein Byte benötigt, läßt sich dies auch leicht bewerkstelligen, ohne daß man Codeteile großartig umschreiben müßte, und liegt dieser neue Core nicht vor, bräuchte man gar nichts verändern, und das Programm läuft weiter wie bisher.
Selbstverständlich kann man bei neuen Spielen durch vermehrten Einsatz der neuen Befehle auch eine stärkere Beschleunigung erzielen, aber mit dem Vorteil, daß man sich als Programmierer nicht um das Timing kümmern muß wie bei der SCPU oder dem TC64 (kein Ein- und Ausschalten bei Interrupts oder z. B. beim Nachladen von Diskette).
Aber leider wird sich das nicht umsetzen lassen, da ich von Elektronikbastelein einfach zu wenig Ahnung habe.
Hmmh...also in einem FPGA den Takt mitzulesen und im richtigen Moment die Busdaten zu übernehmen ist ja theoretisch nicht sooo schwer?
http://www.asic-world.com/verilog/verilog_one_day3.html
module c64buslistener ( input rst,
input clk,
input [15:0] adrbus,
input [7:0] databus);
reg [7:0] data;
always @ (posedge clk ) begin
if(~rst) begin // Init module
end else begin
data <= databus; // Copy the data from the bus
end
end
endmodule;
So in die Richtung irgendwie...
Die Crux liegt darin, daß es keine allgemein verbindliche Engine für alle Spiele geben kann, Wenn der erste Programmierer sagt: Ich will eine Beschleunigung für "Wolfenstein", dann kann man nachher nur Spiele im Stil von "Wolfenstein" darauf schreiben, aber kein Weltraumspiel wie "Elite", keinen Flugsimulator usw. Dafür sind diese Programme intern in ihrer Vorgehensweise zu unterschiedlich.
Das sehe ich nicht so. Auf einer Voodoo-Karte konnte man auch nicht nur Doom o.ä., sondern wahrscheinlich auch den Microsoft Flight Simulator spielen. Ich fand nicht, dass alle frühen 3D-Spiele auf dem PC (bei mir war es ein Mac) gleich aussahen. Es blieb immer noch dem Spiel-Designer überlassen, ob er Texturen verwenden will (und wie die aussehen) oder lieber saubere Flächen bevorzugt. Eine 3D-Karte bekommt Koordinaten (Objekte, Kamera, Licht und einiges an Zusatzinfos) und wirft flächige Bilder zurück – sie schränkt nichts ein – sie ist nur unglaublich schnell.
Leider ist die automatische Verkleinerung von Sprites on-the-fly etwas, was sehr viel Rechenzeit kostet und daher bisher in Spielen kaum zum Einsatz kommt.
Klar, es wäre toll, wenn die 3D-Karte das auch könnte, hat aber eigentlich mit 3D recht wenig zu tun, sondern das wäre ein 2D-Skalierer. Kann aber auch mal sinnvoll sein, wobei man bei den C64-Spritebeschränkungen keine Wunder erwarten sollte. Man kann dem Grafik-Booster natürlich zusätzliche Aufgaben geben, wenn man will.
dann in einem zweiten Schritt die Kanten mit Zwischenfarben zu berechnen und als letztes das so entstandene 320x200x16-Bild runterzurechenn auf 160x200x4 pro Block.
Ne, ich glaube, das hast du noch nicht ganz erfasst. Die Zwischenfarben an den Kanten (und nicht nur dort) entstehen BEIM Reduzieren auf die halbe Auflösung (durch das Zusammenführen von je 2 Pixeln zu einem einzelnen), das ist kein zusätzlicher Schritt. Und wie gesagt, trotzdem muss da selbst bei meinem schmalen 1.5x FSAA eine Menge gerechnet werden und das ginge nur, wenn man einiges an Performance übrig hat (hatte ich eingangs ja auch erwähnt). Ich kann halt nicht genau abschätzen, was eine ca. 10 mal schnellere 6510-kompatible CPU (aka Chameleon) so schafft.
Ein Problem meines angedachten FSAA-Oversamplings will ich nicht verschweigen: Mit Rastern kann es nicht gut umgehen – ein Schachbrettmuster wäre nach der Skalierung verschwunden (halt auch geglättet). Wenn man Raster erhalten wollte, müsste man bis zur hochauflösenden Bitmap mit echten Zwischenfarben arbeiten und erst beim Downsampling in Raster umrechnen. Bei einer 4-Farben-Bitmap würdest du also als Zwischenlösung z.B. auf 320x200x7 kommen (7 wegen 4 Farben und 3 virtuellen Zwischenfarben, die später zu 50%-Rastern werden). Insgesamt wäre wahrscheinlich eine Speichererweiterung zum Auslagern durchaus hilfreich (die eine GPU natürlich für die 3D-Berechnungen intern hätte).
Aber das Runterrechnen auf 4 Farben ist algorithmisch eine schwere Aufgabe, für die man auch auf dem PC noch lange rechnen muß.
Edit: Wenn du von Anfang an nur 4 Farben verwendest, entstehen durch die Kantenglättung nicht mehr Farben – die Arbeit kannst du dir also sparen. Und wenn du mit allen 16 Farben arbeitest (was ja in MC möglich wäre), dann könntest du ganz plump in einer ausgereizten Zelle entweder Farben überschreiben oder unter den Tisch fallen lassen (je nach Strategie). Man wundert sich, was das Auge bei einer schnellen Animation alles ignoriert. Ich würde es einfach drauf ankommen lassen oder aber bei 4 Farben (plus Rasterungen) bleiben – dann gibt es keine Color-Clashes.
Keine Sorge. Die Überlegungen zu einer Graphikkarte sind durchaus berechtigt und gehören hierher.
OK, danke. Die Grundüberlegung ist halt folgende: Du möchtest die CPU-Turbos, die es für den C64 gibt, für 3D-Grafik verwenden. Aber eigentlich sind die dafür gar nicht gemacht – 3D macht man mit GPUs. Eigentlich quälst du die CPUs mit Tätigkeiten, in denen sie (trotz höherer Megahertzen) nicht besonders gut sind. Eine 3D-Karte (egal wie die nun konstruiert ist) wäre nun mal genau für den Zweck konzipiert, für den du sie haben möchtest: Schnell 3D-Daten in Bilder umrechnen, die man nur noch auf den Screen bringen muss. Die Spiel-Logic bliebe hingegen dem internen 6510 vorbehalten – und dafür ist der ja auch gemacht.
Daher dachte ich für den Dauerzustand eher an einen 6502-kompatiblen Core, mit dem man ohne Unterschiede zu bemerken jedes Programm auf dem C64 ausführen kann. Dieser Core hätte als einzige Ausnahme der Kompatibilität einen Sonderbefehl (z. B. $02), der die zusätzlichen Fähigkeiten aktiviert.
Ich finde meine Idee des Grafikboosters eigentlich "fairer" – zumindest läuft das Hauptprogramm auf dem echten C64-Prozessor und nur die 3D-Berechnung würde an die 3D-Karte abgegeben werden – du willst anscheinend gleich den "ganzen" C64 (zumindest sein Herzstück) auslagern – wie beim Chameleon.
Gäbe es überhaupt die Möglichkeit, daß ein Modul sofort beim Einschalten den internen 6502 abschaltet und die volle Kontrolle übernimmt (Ich nehme an, bei der SCPU wird sowas gemacht)? Wie aufwendig wäre das?
Das Chameleon ist schon recht aufwändig – und eigentlich braucht man nicht noch einen weiteren Clone davon. Wie gesagt, warum die CPU-Ausführung beschleunigen, wenn du eigentlich eine GPU benötigst? Du kannst es doch heutzutage sehen: was nützt dir bei einem grafiklastigen 3D-Game eine schnelle CPU? – die GPU ist der wichtigste Baustein für den Gamer.
Und noch als Ergänzung zu der Idee, die Graphik mittels Zeichensatz darstellen zu können: Nope, funktioniert nicht. Bei der Berechnung wurden nicht der linke und der rechte Rahmen berücksichtigt. Um diesen zu gestalten, braucht es mindestens 2 Zeichen mehr. Dadurch reduziert sich die Anzahl der Zeilen, die man mittels Zeichensatz darstellen kann von 8 auf 7, was zum einen die Anzahl der Interrupts erhöht, aber auch eine gewaltige Lücke am Ende des Zeichensatzes zurückläßt, so daß die Frage entsteht, ob sich der ganze Aufwand überhaupt lohnt.
Elite:Ich fände es jetzt kein Sakrileg, auf den gezeichneten Rahmen zu verzichten.
Vieleicht bräuchte man nicht mal auf den Rahmen verzichten. Was wäre denn, wenn der linke und rechte Rahmen nach innen rückt, um jeweils zwei Hirespixel oben bzw. ein Multicolorpixel unten? Dann werden natürlich Objekte teilweise in die seitlichen Rahmenlinier gezeichnet/XORt, was nicht so sauber aussieht. Aber wenn man ganz genau hinschaut, sieht man, dass ja Elite jetzt auch in die obere Rahmenlinie zeichnet. Ob das an der Seiten mehr stören würde, könnte man vieleicht ausstesten.
Zur Veranschaulichung habe ich mal ein bisschen in Spielgrafik reingemalt Die Cockpitbeschriftungen stossen jetzt an die Seitenlinien an. Aber das lässt sich durch ein wenig Umpixeln leicht beheben, glaube ich.
forum64.de/wcf/index.php?attachment/139390/
Wäre damit die Idee wieder im Spiel oder habe ich etwas übersehen?
Zur Veranschaulichung habe ich mal ein bisschen in Spielgrafik reingemalt [...]:
Clipboard09.png
Bei mir funktioniert der Link zu dem Bild nicht. Allgemeines Problem oder nur bei mir?
Sieht man jetzt was?
Ja, danke.
hat aber eigentlich mit 3D recht wenig zu tun, sondern das wäre ein 2D-Skalierer.
Naja, viele klassische 8-Bit-Spiele wie Rennspiele mit (Pseudo)3d-Darstellung basieren auf Spriteverkleinerung bzw. Vergrößerung.
Das Chameleon ist schon recht aufwändig – und eigentlich braucht man nicht noch einen weiteren Clone davon.
Nein, ein neues TC64 will ich auch gar nicht. Davon war nie die Rede. TC64 würde ja bedeuten, daß alle C64-Chips (CIA, SID, VICII) und sogar das Laufwerk irgendwie emuliert werden müßten. Das wäre aber völlig am Ziel vorbei. Wenn man es vergleichen will, dann eher mit einer SCPU oder dem CP/M-Modul, halt in der Art, wie es Daybyter beschrieben hat. Auf keinen Fall sollte man damit auch noch weitere Hardware des C64 nachahmen wollen wie beim TC64.
3D macht man mit GPU
Die Spiel-Logic bliebe hingegen dem internen 6510 vorbehalten – und dafür ist der ja auch gemacht.
warum die CPU-Ausführung beschleunigen, wenn du eigentlich eine GPU benötigst?
Verzeih bitte, aber ich befürchte, Du hast eine falsche Vorstellung vom Aufbau von 3d-Spielen. Der Renderer stellt nur einen Teil des Gesamtprogramms dar. Ein großer Teil, oftmals sogar der größte, befaßt sich mit der Spiellogik, in der es von 3d-Operationen nur so wimmelt. Da werden für solche Aufgaben wie Kollisionserkennung oder Ansteuerung einer Station Matrizen multipliziert und rotiert. Da werden Winkel berechnet und Abstandsmessungen durchgeführt. Nur mal so als Beispiel: Ein Abstand im 3d-Raum berechnet sich bekanntlich nach Pythagoras durch wurzel(dx * dx + dy * dy + dz * dz). Das ist auf dem 6502 harte Knochenarbeit. Selbst wenn Du den Renderer komplett auf eine GPU auslagerst, wirst Du keine Framerate bekommen > 10 fps, da die CPU die Werte überhaupt nicht so schnell liefern kann. Deswegen meine Frage schon ganz zu Beginn: Was alles soll die Zusatzkarte berechnen? Ein Renderer allein wird für eine flüssige Framerate schlicht nicht reichen, aber eine allgemein verbindliche Schnittstelle für die Spiellogik aller Spiele zu definieren, wird ein Ding der Unmöglichkeit sein. Wie gesagt: 3d-Spiel ist nicht gleich 3d-Spiel. Die internen Arbeitsvorgänge und Datenstrukturen unterscheiden sich von Spiel zu Spiel komplett.
Daher meine Idee einer allgemeinen, flexiblen Beschleunigung, die eben auch die Spiellogik beschleunigen kann. Diese kann man verwenden, um neue Spiele zu schreiben, aber auch, um alte Spiele vergleichsweise leicht (d. h. leichter als bei der SCPU) zu patchen. Als Retroprogrammierer hätte ich auch an sowas durchaus Interesse (siehe meine Patches zu "Test Drive II" oder jetzt "Elite"), denn der Vorteil dabei ist, daß das Retrofeeling nicht verloren geht. Wie bereits erwähnt, habe ich das Verfahren am Apple//e-Emulator ausgetestet. Mir fehlt nur leider das Know-How, daraus eine Hardware zu machen.
du willst anscheinend gleich den "ganzen" C64 (zumindest sein Herzstück) auslagern
Wenn Du mit "Herzstück" den Prozessor meinst, ja, logisch, wie halt bei der SCPU, mehr aber auch nicht. Und der Prozessor soll (anders als die SCPU) auch kompatibel zum 6502 sein. Es geht mitnichten darum, den 6502 komplett zu ersetzen, sondern mit zusätzlichen Befehlen auszustatten, die z. B. ein schnelles Umkopieren von Daten ermöglichen. Wie man an den externen Speichermodulen wie REU, Easyflash und GeoRAM sehen kann, haben diese alle ihre Nachteile, doch der größte Nachteil für den Programmierer ist, daß die Daten nicht direkt an die Stelle gelangen, wo sie hin sollen, sondern entweder in einem kleinen 256-Byte-Fenster oder fest im Bereich ab $8000 erscheinen oder per DMA kopiert werden müssen, was aber das Timing stört. Hingegen kann mit einer programmierbaren Erweiterung jeder Programmierer schnell und einfach eigene Kopierroutinen zusammenstellen, was wesentlich komfortabler ist. Mit anderen Worten: Solch ein Modul könnte gleichzeitig als modernes Speichermodul fungieren.
Wäre damit die Idee wieder im Spiel oder habe ich etwas übersehen?
Ja, übersehen was Du hast. Die Routine zum Malen der Zeichen auf dem Bildschirm ab $b157 holt sich die Bildschirmadressen nicht aus der leicht anpaßbaren Adresstabelle, sondern berechnet sie direkt mittels Shiftoperationen!!!11!!111 
Nee, kann man natürlich umschreiben. Was den Rahmen anbelangt, könnte man auch gucken, ob man die Clipping-Routine so neugestalten kann, daß bei X <= 1 und X >= 254 abgeschnitten wird. Blöd bleiben nur die vielen Interrupts, die man dann schneller abwickeln sollte als im Original.
Wie gut läßt sich eigentlich die Cockpitgraphik an eine MC-Zeichensatzgraphik anpassen? Kommt man da überhaupt mit den Farben hin? Z. B. das hellblaue 'S'-Zeichen (für Station) bzw. das 'E'-Zeichen (für ECM) könnte man wahrscheinlich nicht in Hellblau übernehmen, sondern müßte dafür eine andere Farbe nehmen, oder? (Ich hatte ja schon früher vorgeschlagen, die Cockpitgraphik generell zu überholen. Eigentlich muß man dabei nur aufpassen, daß die Anzeigebalken an gleicher Stelle liegen und die Multicolourfarben sich mit der Radaranzeige vertragen.)
