Neue Spielimpulse durch Turbo-CPU-Modus möglich?

Zitat von ZeHa

Was ist eigentlich der wesentliche Unterschied zwischen Metal Dust und Enforcer 2?

Verwendet Metal Dust für die Hintergrundgraphik eigentlich Zeichensatz oder Bitmap?

Zitat von Retrofan

Schon an anderer Stelle habe ich mal behauptet (mehr kann ich als heutiger Programmier-Laie nicht tun), dass man die potentiellen Möglichkeiten moderner C64-Software nicht an dem bemessen darf, was z.B. 1986 gemacht wurde. Selbst bei identischer Hardware kann man teils erheblich höhere Performance erzielen, indem man effizientere Routinen und neuere Konzepte verwendet.

Das sehe ich auch so.

Zitat von Retrofan

Wichtig dabei ist, dass man nur die Framerate erhöht (also die Feinheit in der zeitlichen Abfolge) und nicht, wie bei nachträglicher Beschleunigung, das ganze Spiel schneller und damit (zumindest bei einigen Games) die ganze Sache (z.B. wegen zu schneller Gegner oder Hindernisse oder zu hektischer Steuerung) unspielbar macht.

Das wäre ideal.

Zitat von C=Mac

Wenn dies Möglich ist und auch funktioniert, wäre es sicherlich am Besten.
Wobei die Beschleunigung schon recht unterschiedlich ist.
C128 max. 2 MHZ, SCPU 20 MHZ.

Ein paar Seiten früher hatte ich schon mal was zu den verschiedenen Beschleunigern geschrieben. Kurz gefaßt: Ein Programm sollte alle bekannten Beschleuniger unterstützen (eingeschlossen keine) und niemals ein bestimmtes Timing voraussetzen, sondern sich flexibel an die jeweilige Geschwindigkeit anpassen z. B. in Form einer höheren Bildrate.

Zitat von Retrofan

Nach wie vor wäre Descent aus meiner Sicht der lohnenste Kandidat für eine Vorlage zu einem gelungenen C64-3D-Spiel

Ein Spiel in der Art könnte interessant werden. Wie so oft steckt der Teufel aber hier im Detail. Was müßte ein Programm leisten, um annähernd eine Tunnelgraphik zu erstellen, wie bei "Decent"?
1.) Die Polygone umgeben den Spieler. Das macht es notwendig, die Polygone gegen die Z-Ebene (den Bildschirm) zu clippen. Erst dann kann ein Test auf Sichtbarkeit durchgeführt werden. Bei einem Spiel wie Elite reicht in dieser Hinsicht für befriedigende Ergebnisse ein Test der Objektkoordinate, um das Zeichnen durchzuführen oder von vornherein zu verwerfen.
2.) Bei "Elite" und vergleichbaren Spielen sind die Polygone eher sehr klein, weil sich die Objekte in Abstand zum Spieler befinden. Nur beim Anflug an die Raumstation, füllen Polygone den ganzen sichtbaren Bereich. Das ist dann auch der Moment, wo die Programme in die Knie gehen (einschließlich der langsamen Amiga-Version). Da für mich die Voraussetzung für ein Programm ist, daß es eben auch noch auf einem Vanilla-C64 laufen soll, muß man hier schon sehr viel Programmieraufwand und Abstriche in der Umsetzung in kauf nehmen.
3.) Die größte Schwierigkeit dürfte aber sein, daß die sehr großen Polygone der Wände kleinere Objekte, die sich dahinter befinden, verdecken müssen. Selbst mit 100Mhz könnte man auf dem C64 nicht wirklich einen Pixel-Z-Puffer generieren. Das heißt, man muß auf den klassischen Painter-Algorithmus zurückgreifen (hinten liegende Polygone werden zuerst gemalt), der aber bei Polygonen mit sehr starker unterschiedlicher Größe schnell zu Fehlern in der Darstellung führen kann. Bei "Elite" waren die Objekte so angelegt, daß keine Fläche eine andere verdecken konnte. Daher reichte es aus, allein die Objekte anhand ihrer Z-Koordinate zu sortieren, um die richtige Malreihenfolge zu ermitteln. Bei einer Graphik wie "Decent" wird das nicht funktionieren, da Wände, die eigentlich Hintergrund sein und dabei stets zuerst gemalt werden müssen, nicht immer Hintergrund sind.
Nebenbei: Dies mag auch ein Grund gewesen sein, warum "Mercenary" Räume stets mit Türen verbindet, durch die man hindurchgehen muß. Die Unterschiede im Rechenaufwand kann man sich verdeutlichen, wenn man sich "Driller" anschaut (, das zu allem Überdruß noch über schnarchlangsame Rechenroutinen verfügt).
Aber das sind alles Sachen, die man mal austesten könnte. Probieren geht über Studieren.

Zitat von Retrofan

Warum eigentlich kein Modul nehmen?

Ein Modul als reiner Datenträger wie die Diskette nur zum schnellen Nachladen kann ich mir durchaus vorstellen, aber die Verwendung eines Moduls im laufenden Programm ist nicht trivial und stellt einen Programmierer auch vor große Probleme. Kurz gesagt: Ein Spiel, bei dem das Programm und/oder Daten verteilt auf mehrere Banks liegen, ist nicht gerade angenehm zu entwickeln. Von daher würde ich persönlich darauf, zumindest solange es geht, eher verzichten.

Zitat von katarakt

Das ist es einfach was auf dem cevi am meisten spaß macht. 3D games auf dem cevi waren für mich nie wirklich interessant

Nun, das ist wohl Geschmackssache. Persönlich konnte ich mit den ganzen Jump'n'Runs (mit der Ausnahme "Impossible Mission") nie richtig was angefangen, auch nicht mit solchen Shootern wie "Katakis", "Turrican" usw. Auch das neue "Sam's Journey" ist trotz allem Respekts vor den Programmieren für ihre Leistung als Spiel für mich einfach nicht interessant genug, als daß ich mich mehr als ein paar Stunden damit beschäftigen würde. Dagegen habe ich mich mit "Elite", "Mercenary", "Space Rogue", "Koronis Rift" tage-, wochen-, wenn nicht sogar jahrelang beschäftigt.

Zitat von ogd

Auch der Rahmen um das Blickfeld liesse sich nutzen, wenn die Farbattribute auf schwarz (= unsichtbar) gesetzt werden

Nette Idee. Auf dem CPC (beim Orginal-Bitmap-Modus) wurde das so gemacht, und auch AppleII-ProDos speichert die slotspezifischen Variablen in den Screenholes des Textbildschirms. Praktisch gesehen gibt es hier jedoch Grenzen. Solch ein Block wäre lediglich $40 Bytes groß. Nun ist die Anzahl der Variablen, die das Spiel benötigt gar nicht so hoch. Die meisten finden sich auf der Zeropage. Dann gibt es noch größere (> $40) Arrays z. B. zum Zeichnen der Sonne und die jeweils gebündelt in einem Struct abgelegten Objektangaben wie Koordinate, Rotationsmatrix usw. Selbige könnte man vielleicht in diesen Bereich auslagern, doch sonderlich viel Platz wird man dadurch nicht gewinnen können. Zusätzlich könnte man noch die gesicherte Zeropage (für einen Kernalload/-save) gesplittet dort ablegen, aber Programme und Objektmaldaten sowie Strings lassen sich hier nur sehr schwer hin verlagern. Der größte Teil dürfte daher leider wohl unbenutzt bleiben.

Bedauerlicherweise hat der Programmierer der C128-Version seinen Code nicht hinterlegt, so daß man darauf zurückgreifen könnte. Er hatte nämlich bereits sehr sinnvolle Maßnahmen ergriffen wie das Packen der Cockpitgraphik oder der Strings, um Platz für seine Erweiterungen zu schaffen. Aber er scheint nicht mehr aktiv zu sein, sonst hätte er sich vielleicht hier im Forum schon mal gemeldet.

Zitat von Retro-Nerd

Reine 3D Spiele am C64 sind auch nicht so mein Ding.

Gibt aber einige die doch gelungen sind.

Ich fand Gunship klasse für ein 8Bit System, eine Hubschrauber Simulation muss ja auch kein Rennauto sein.

Micha

Zitat von peiselulli

Genau das macht den Reiz, irgendwas auf dem C64 zu programmieren, kaputt ! Alle neueren, coolen Effekte beruhen genau darauf, dass man genau auf solche Erweiterungen keine Rücksicht nimmt.

Nun, Du hast sicherlich die Posts vorher gründlich gelesen und mitbekommen, daß hier von der Entwicklung eines 3d-Spiels die Rede ist, nicht wahr? Nun denn, dann sag mal, wieso ein neues 3d-Spiel den Reiz kaputt macht, irgendwas auf dem C64 zu programmieren. Vielleicht ist mir da was entgangen. Und klär mich ruhig auf, welche 3d-Spiele der letzten 10-20 Jahre auf "neueren, coolen Effekten" beruhen. Ich bin gespannt.

Zitat von ogd

Schreib ihn doch mal per Email an.

Danke. Werde ich vielleicht mal machen, aber nicht vor Ende April (dem Ende der diesjährigen Competition).

Zitat von Hoogo

Ich frag mich, ob es dazu einen einfachen Algorithmus gibt?

Das Prinzip des "Maleralgorithmus" wird hier kurz beschrieben. Die dort erwähnte "Tiefensuche" wird meistens so durchgeführt, daß bei einem Polygon der Mittelwert aller Z-Werte berechnet wird. Bei einem Rechteck heißt dies, daß man von allen 4 Punkten den Z-Wert nimmt, diese aufaddiert und anschließend durch 4 teilt. Das ergibt dann eine Annäherung an die ungefähre Tiefe des Polygons. Die Polygone werden dann in der Reihenfolge gemalt "höchster Tiefenwert zuerst". In vielen Fällen reicht das aus, aber es kann in Einzelfällen zu Fehlern kommen, d. h. ein eigentlich nicht sichtbares Polygon wird über ein anderes eigentlich sichtbares gemalt. Um solche Fälle zu vermeiden, sollte man darauf achten, daß die Polygone möglichst gleich groß sind und sich (wie in dem verlinkten Wikipedia-Artikel gezeigt) nicht überschneiden.

Zitat von Hoogo

Die Omega-Blast-Engine sieht echt super aus!

Danke.

Zitat von Hoogo

Hast Du da schon irgendwann mal was technisches beschrieben?

Nein. Es hat aber auch noch nie jemand danach gefragt.

Zitat von Hoogo

scheint mir mit einem EOR-Filler nicht ganz einfach

Ich weiß auch nicht, ob das mit einem EOR-FIller wirklich möglich wäre. (Es werden alle vier Farben und deren Mischmuster verwendet.) Daher haut die Malroutine die Bytes einfach nacheinander in die Bitmap.

Zitat von Hoogo

Feeling Retro fand ich damals auch sehr gelungen.

Danke für den Link. Schau ich mir mal an.

Zitat von ogd

Zeichensatzmodus

Ja, daran habe ich auch schon gedacht. Das Spiel "Fighter Bomber" arbeitet nach diesem Prinzip. (Daher die eingeschränkte Breite und auch die erkennbaren Graphikfehler bei Verwendung einer SCPU, da der Rasterinterrupt, der in der Mitte der 3d-Darstellung auf den nächsten Zeichensatz umschaltet, im Timing gestört wird.)

Zitat von ogd

Ein weiterer Nachteil ist die eingeschränktere Farbauswahl als im echten Bitmapmodus.

Das wäre durchaus zu verkraften, da nur im Multicolourmodus davon eine Farbe betroffen wäre (%11, also $d800).

Zitat von ogd

per Rasterinterrupt auf einen zweiten, dritten ... Zeichensatz umgeschaltet werden.

Hierin sehe ich das einzige Problem. In einen Zeichensatz passen 256 Zeichen. Pro Zeile werden 256 Pixel pro Zeile / 8 = 32 Zeichen verwendet. (Den schwarzen Rand erzeugt man wie von Dir vorher beschrieben mit einem beliebigen Zeichen und der Hintergrundfarbe 0 im $d800-Farbram.) Damit kommt man bei einem Zeichensatz auf 256 Zeichen insgesamt / 32 Zeichen pro Zeile = 8 Zeilen pro Zeichensatz. Elite verwendet für die 3d-Sicht (ich glaube) 18 Zeilen, d. h. man benötigt 2 Zeichensätze sowie noch 64 Zeichen aus einem 3. Zeichensatz. Insgesamt kommt man damit auf $800 + $800 + (64 * 8 ) = $1200 Bytes. Da die Cockpitgraphik jedoch aus Multicolourbitmap besteht, würde diese bei 18 * 320 = $1680 beginnen. Es entsteht daher eine Lücke von $480 Bytes, die aufgrund ihrer krummen Lage leider nicht für das Multicolour-Farbram bzw. den Textschirm verwendet werden kann, sondern nur für andere Daten. Immerhin könnte man so 2 * $480 Bytes herausholen.
Jetzt gibt es aber zwei Nachteile:
1.) Man benötigt mindestens 2 Rasterinterrupts mehr. Nimmt man die Cockpitgraphik hinzu, wären es sogar 5 insgesamt. Die Interrupts sind bei Elite leider recht langsam programmiert. Selbst bei einer Optimierung wird hier dem Programm laufend Rechenzeit geklaut. Wie weit sich das ernsthaft auswirkt, kann ich nicht sagen.
2.) Das Spiel schaltet für die Menüs die Cockpitgraphik ab und blendet stattdessen unten auch Hires ein. Will man also nicht, daß z. B. für die Zeichenausgabe zwei getrennte Bereiche verwaltet werden müssen (oberhalb und unterhalb), so müßte man das System mit den Zeichensätzen bei abgeschalteter Cockpitgraphik weiterführen, also auch die unteren Zeilen damit ausstatten. Technisch durchaus möglich, erfordert aber noch mehr Interrupts (4), denn man benötigt 3 volle Zeichensätze (3 * 8 = 24) und für die letzte Zeile noch 32 Zeichen aus einem 4. Zeichensatz. Nachteil: Die vorher erzielte Lücke geht wieder verloren.
Um dies zu verhindern, könnte man überlegen, ob es möglich wäre, die gesamte Cockpitgraphik ebenso als Zeichensatzgraphik darzustellen. (Man könnte hierfür auch vielleicht die üblichen Verdächtigen im Forum freundlich fragen, ob sie eventuell bereit wären, dafür eine überarbeitete Cockpitgraphik im Zeichensatzmodus zu entwerfen.)
Abschließend muß man bei zwei Dingen noch aufpassen:
1.) Das genaue Timing der Rasterinterrupts, damit das wandelnde Trumblesprite keine Störungen verursacht.
2.) Die Cockpitanzeige sollte nicht ins Double-Buffering einbezogen werden, da man ansonsten arge Probleme mit dem Programm bekommt. Zwar wäre es prinzipiell möglich, das Double-Buffering auf die Anzeige auszudehnen, doch muß man dann jede Menge Code (u. a. auch den Radarcode) ändern. Daher noch weiterhin der Interrupt nach Zeile 18, um immer auf eine feste Seite umzuschalten.

Das Georam war doch bekannt recht langsam zu sein.

Zitat von enthusi

Vom GEOram sind Daten schneller im Speicher als mit der REU

Interessant. Hatte das anders in Erinnerung. Zumal die REU ja immer wg. ihrem DMA angepriesen wurde, was
das Georam ja nicht hat.

Zitat von enthusi

GEOram blendet von den 512KB immer 256 Byte RAM in die IO Register ein. Das ist wenig, aber sofort da.
Lesen, Schreiben, Code ausführen geht.

Easyflash/Module blenden 8 oder 16 KB ein.
Nur Lesen, Code ausführen geht.

REU blendet gar nichts ein. Es liest/schreibt RAM aber schnell.
Code ausführen in der REU geht nicht.

Daher nutzt zB Prince of Persia das Easyflash, kann mit REU aber konkret nix anfangen.

Alles anzeigen

Besten Dank für die Erklärung.