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

  • ZeHa schrieb:

    Wie das jetzt genau bei Monster Buster ist, kein Plan. Aber wenn es jetzt einfach nur um sehr grosse Spielwelten geht, wo halt immer wieder portionsweise nachgeladen werden muss oder nach jedem Level usw, da waere das ja vermutlich kein allzu grosses Problem
    Bei Monster Buster XXL wird vom Bankswitching viel Gebrauch gemacht und nicht nur zwischen den Leveln. Daher wäre ein magnetischer Datenträger keine wirkliche Alternative. Und ohne den zusätzlichen ROM-Speicher hätte man aus Monster Buster keine XXL-Version (wie wir sie und vorgestellt haben) machen können.

    ZeroZero schrieb:

    Ich hätte keinerlei Vorbehalte gegen ein Spiel mit beliebiger Hardwareerweiterung, wenn diese Bestandteil des Lieferumfangs ist.
    So sehe ich das auch. Wenn in einem Modul mehr ROM-Speicher als üblich verbaut ist – wen kümmert's? Es zählt ja auch niemand bei einer Diskette den darauf erhältlichen Speicher zum RAM dazu. Das ist einfach der Datenträger, ob nun in Modul- oder Magentscheiben-Form.

    Bei Atari 2600 Modulen hat es auch keinen Käufer interessiert, ob da nun 2, 4, 8, 16 oder 32 KB ROM drin waren – Hauptsache das Spiel ist gut. Wenn aber auf den Spiel-Verpackungen gestanden hätte: Läuft nur mit Atari-VCS-Modell soundso mit optional erhältlicher RAM-Erweiterung soundso, dann wäre das eine ganz andere Nummer gewesen.

    MGR3SA schrieb:

    Also hätte man Metal Dust auf Modul mit einer Mini SCPU veröffentlichen sollen
    Es wäre sicherlich öfter verkauft worden – wenn man es einigermaßen preisneutral hinbekommen hätte. ;) Atari 2600 Games mit SARA Chip oder das SNES-Game Star Fox sind doch im Prinzip ganz ähnliche Sachen: Die Original-Hardware schafft es nicht, also bringt man mit, was zusätzlich gebraucht wird.

    ALeX hat ja mal über einen Grafik-Booster für den C64 nachgedacht, der hätte dem C64 einige "neue" Grafikmodi beigebracht. Da das als Modul zu realisieren gewesen wäre, war auch eine Überlegung von uns, die Grafikerweiterung einfach in Spiele zu integrieren und mitzuliefern, wenn sie benötigt wird. Damit hätte man z.B. ein superschnelles (und gleichzeitig buntes) Sonic oder Zool auf dem C64 realisieren können.

    enthusi schrieb:

    statt besser geht auch anders. Ist Sam Turrican2 wirklich uberlegen? Oder cor allem anders und neu?
    In die Richtung muss man denken, wenn auch vielleicht nicht immer ganz so extrem (Genre-Sprung). Ich hätte auch keinen Bock auf ein weiteres Enforcer/Katakis/MetalDust mit nur noch mehr Gegner gleichzeitig und einer größeren Bullet-Hell und noch größeren Endgegern. Man muss halt neue Ideen reinbringen und nicht nur immer "mehr" und "weiter" und "größer". Und das geht eben auch oftmals ohne Turbo oder zusätzliches RAM. Gute Ideen schlagen Turbos meines Erachtens um Längen.

    Aber wenn nunmal ein Programmierer gerne ein (gutes) 3D-Spiel (mit gefüllten Flächen) auf dem C64 realisieren möchte, kommt er wohl um einen Turbo o.ä. nicht herum. Wenn das eine Ausnahme bleibt, finde ich das auch durchaus legitim. Notfalls könnte ich das Game auf VICE spielen, denn eine entsprechende Hardware werde ich mir wohl nicht zulegen.
  • ZeHa schrieb:

    Was ist eigentlich der wesentliche Unterschied zwischen Metal Dust und Enforcer 2?
    Im wesentlichen größere Sprites bzw. Sprite-Formationen, sehr große und viel-frame-ig animierte Endgegner, und der von Welle: Erdball geschaffene Digi-Soundtrack.

    Achso, und der wichtigste Unterschied: das eine ist fertig geworden, das andere nicht. :D
  • Naja, Trenz hat wohl damals gleichzeitig an der Super Turrican Version für das NES und Enforcer gearbeitet. Sowas macht man ja auch nicht. Deshalb sind beide nur suboptimal geworden. Einige SCPU Fixes sind schon nett, der schnelle Bildaufbau bei Leaderboard oder Last Ninja hat was für sich. Reine 3D Spiele am C64 sind auch nicht so mein Ding.
  • ZeHa schrieb:

    Was ist eigentlich der wesentliche Unterschied zwischen Metal Dust und Enforcer 2?
    Verwendet Metal Dust für die Hintergrundgraphik eigentlich Zeichensatz oder Bitmap?

    Retrofan schrieb:

    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.

    Retrofan schrieb:

    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.

    C=Mac schrieb:

    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.

    Retrofan schrieb:

    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.

    Retrofan schrieb:

    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.

    katarakt schrieb:

    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.

    ogd schrieb:

    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.
  • 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.
    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.
  • M. J. schrieb:

    Bedauerlicherweise hat der Programmierer der C128-Version seinen Code nicht hinterlegt, so daß man darauf zurückgreifen könnte.... Aber er scheint nicht mehr aktiv zu sein, sonst hätte er sich vielleicht hier im Forum schon mal gemeldet.

    Weiß gar nicht, ob er hier schon mal aktiv war. Schreib ihn doch mal per Email an. (Er hat übrigens auch lange Zeit die cc65-Toolchain gepflegt.).
  • peiselulli schrieb:

    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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von M. J. ()

  • M. J. schrieb:

    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.
    Sowas macht mir auch grad Kopfzerbrechen. "Mal eben" ein bisschen 3D mit gefüllten Flächen in VB6+GDI. Man muss ja nur die Flächen von hinten nach vorne zeichnen, nur Rechtecke, nichts schneidet sich... Am Arsch!!
    Ich frag mich, ob es dazu einen einfachen Algorithmus gibt? Einfach nur irgendwelche Z-Werte der Flächen miteinander zu vergleichen bringt es nicht.

    Die Omega-Blast-Engine sieht echt super aus! Hast Du da schon irgendwann mal was technisches beschrieben? Körper können sich offenbar ordentlich gegenseitig verdecken, scheint mir mit einem EOR-Filler nicht ganz einfach.

    BTW: Feeling Retro fand ich damals auch sehr gelungen. Zeilenweise das Bild im Tausch gegen eine höhere Framerate zu zerreissen fand ich optisch schön. Hatte Tau Ceti glaub ich auch gemacht.
    Vollmond war gestern!
  • ogd schrieb:

    Schreib ihn doch mal per Email an.
    Danke. Werde ich vielleicht mal machen, aber nicht vor Ende April (dem Ende der diesjährigen Competition).

    Hoogo schrieb:

    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.

    Hoogo schrieb:

    Die Omega-Blast-Engine sieht echt super aus!
    Danke. :schande:

    Hoogo schrieb:

    Hast Du da schon irgendwann mal was technisches beschrieben?
    Nein. Es hat aber auch noch nie jemand danach gefragt.

    Hoogo schrieb:

    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.

    Hoogo schrieb:

    Feeling Retro fand ich damals auch sehr gelungen.
    Danke für den Link. Schau ich mir mal an.
  • M. J. schrieb:

    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.

    Wie schätzt du dann folgenden Vorschlag ein? In Demos wird ja gerne der Zeichensatzmodus eingesetzt, auch wenn es nach Bitmap aussieht. Die Screencodes bleiben konstant und die Linien, Polygone etc. werden dann in die eigentliche Zeichensatzdefinition gemalt. Das hat bei Programmen, die wie Elite nicht die volle Bildschirmbreite nutzen, den Vorteil, dass weniger oder keine Memoryholes entstehen und insgesammt der Speicheverbrauch kleiner ist.

    Wenn 256 8-mal-8-Pixel-große Kacheln nicht ausreichen, muss dann natürlich per Rasterinterrupt auf einen zweiten, dritten ... Zeichensatz umgeschaltet werden. Ein weiterer Nachteil ist die eingeschränktere Farbauswahl als im echten Bitmapmodus.

    Wäre das hier auch praktikabel?
  • Neu

    ogd schrieb:

    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.)

    ogd schrieb:

    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).

    ogd schrieb:

    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.
  • Neu

    Wenn man tatsächlich eine Beschleunigung benötigt, sollte man das erstmal mit dem, was bereits existiert versuchen. Da gibt es eine Menge Geräte, die bereits genannt wurden.

    Die größte Verbreitung davon haben bei der CPU der C128 und beim Speicher die REU und die GeoRAM.

    Wenn man die konsequent nutzen würde, könnte man mit Optionen in der Software bereits viel erreichen.

    Vorteil: C128, REU, GeoRAM haben bereits viele. -> Akzeptanz hoch, keine Geldausgabe notwendig.

    Weiterer Vorteil GeoRAM: Lässt sich sogar mit Standard-Bauteilen preiswert nachbauen.

    Alles andere ist nicht besonders verbreitet, wird es voraussichtlich auch nicht mehr und wird an sich auch nicht benötigt, da man bei viel umfangreicheren Modifikationen ohnehin auf eine andere Plattform ausweichen kann. Gibt ja auch genügend Retro-PCs, Amigas, Atari ST's, die auch toll sind. Irgendetwas neues inkompatibles, was es ja schon gibt, wird keine großartige Verbreitung finden.
    Der Effekt könnte, wie bereits erwähnt sogar zu einer kleinen Zersplitterung der Fans führen. Was zusammenhält ist doch in der Regel, dass man mit den vorhandenen Geräten in der Gemeinde das gleiche machen kann. Das ist die Stärke der Gemeinde und darauf sollte man sich "besinnen" und die vorhandenen Sachen nutzen.

    Alles andere was rein technisch nicht machbar ist und andere Hardware als breit verfügbar erfordert, macht man dann auch auf dem PC, der in der Regel in verschiedenen Ausbaustufen vorhanden ist.
  • Neu

    M. J. schrieb:

    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.

    Hast du zufällig die Interruptroutine disassembliert vorliegen oder kannst zumindest die Adresse nennen?

    M. J. schrieb:

    Das Spiel schaltet für die Menüs die Cockpitgraphik ab und blendet stattdessen unten auch Hires ein.

    Es musste natürlich einen weiteren Haken geben :)

    M. J. schrieb:

    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.

    Ja, die Cockpitanzeige würde ich auch nicht doublebuffern. Die ist ja im Vergleich zur Weltraumsicht auch eher statisch. Auch hier die Frage: Kannst du vieleicht sagen, wo der Radarcode liegt und/oder wie umfangreich/rechenintensiv die ist?

    Und ganz generell: Ha(tte)st du schon eine Memorymap vom originalen C 64-Elite erstellt?
  • Neu

    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.
  • Neu

    enthusi schrieb:

    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.
    Besten Dank für die Erklärung.
    :winke: Wie C64 an TFT? :winke:
    :king: Ace for President! :king:
  • Neu

    enthusi schrieb:

    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.
    Finde ich jetzt sehr interessant.

    Hatte es auch so in Erinnerung:

    REU schneller, da DMA-Chip.
    GeoRam langsamer, da kein DMA-Chip vorhanden.
    O.K. die 64'er hatte nicht immer recht. ;)

    Intressant finde ich auch das in der GeoRam Code (Programme, Berechnungen?) ausgeführt werden können.
    Bis jetzt war ich immer der Überzeugung, dass die RAM-Erweiterungen nur als RAM-Laufwerk benutzt werden können und nicht als "Arbeitsspeicher".
    Dies würde ja schon wieder neue Möglichkeiten eröffnen.
    Aber auch eine weitere Anpassung bedeuten. :S

    Gruss C=Mac.
  • Benutzer online 1

    1 Besucher