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?

    Zitat von M. J.

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


    Mal sehen, was bei mir rauskommt. Wenn (falls ich jemals) ich das erste Dreieck auf dem Schirm hab, dann mach ich nen Thread auf.

    Zitat von M. J.

    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...Am besten wäre es, wenn man die Überprüfung erst beim Polygonmalen selbst vornimmt...


    Eben. Min/Max von Y fallen ja eh beim Zeichnen des Dreiecks je Fläche an, und die X-Koordinaten der Punkte hat man bestimmt auch irgendwann mal in den Fingern.

    Zitat von M. J.

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


    Ich weiß nicht recht. Ich würde eher auf Geschwindigkeit in übliche Spielszenen zielen. Beim Anflug auf die Raumstation war mir Framerate nicht so wichtig, wenn ich durch 2 Thargoiden abgefangen wurde, dann schon. Und wenn sich eine Linienroutine ab 8 Zeichen Breite lohnt, dann lohnt sie sich praktisch nie.

    Zitat von M. J.

    ...Die Genauigkeit von Festkomma-Formaten wird häufig überschätzt .... 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 wiebei "Star Trek" plötzlich von einer mysteriösen Kraft gefangen gehalten wird und das Raumschiff sich nicht mehr weiterbewegt.


    Ist erstmal Böhmische Dörfer für mich. Erstmal Dreiecke, dann Körper, dann schauen wir mal.

    Zitat von M. J.

    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.

    Was heißt "müßten"?
    Diese Chips laufen im Chameleon halt parallel zu den echten, damit man prinzipiell sämtliche Signale doppelt vorfindet. Man muß es aber nicht nutzen. Will man eine Software für den Chameleon-Turbo schreiben, kann man diese Eigenschaft erstmal außer Acht lassen, denn die Software wird nach wie vor auch mit echten Laufwerken sowie mit Bild, Ton und Eingaben von den Originalchips im C64 funktionieren, wenn man es so möchte. Das ist ja gerade das Geniale an diesem Modul.

    Zitat von M. J.

    Verzeih bitte, aber ich befürchte, Du hast eine falsche Vorstellung vom Aufbau von 3d-Spielen.

    Kann sein – ich habe noch keines gemacht. Wie gesagt, seht meine Idee von der 3D-Karte als kleine Anekdote an. Ich kann sie weder bauen noch programmieren oder anderweitig bei einer Realisierung helfen. Du möchtest lieber etwas anderes statt einer GPU haben – das ist vollkommen legitim, denn du wirst selbst am Besten wissen, was du für deine Ziele benötigst.

    @'LogicDeLuxe: Es ging mir nie um das TC64. Das Einzige, was ich sagen wollte, war, daß das Modul, von dem ich sprach, nichts mit dem TC64 gemein hat.


    Retrofan: Da geht es Dir genauso wie mir. Meine Idee von einem externen CPU-Modul ist auch nur eine kleine Anekdote, denn ich kann es weder bauen noch programmieren (in Verilog) oder anderweitig bei einer Realisierung helfen. Hier geht es auch nicht danach, was ich haben möchte, denn dann hätten wir solch ein Modul schon längst. Es sind bislang halt nur Gedankenspiele. Praktisch werde ich weiterhin mit den üblichen Beschleunigern arbeiten müssen, denn was anderes haben wir nun mal nicht.

    Zitat von ogd

    Ha(tte)st du schon eine Memorymap vom originalen C 64-Elite erstellt?

    Eine kleine Ergänzung:
    Die Objektdaten (Typ, Status, Koordinate, Matrix usw.) werden ab $f900 abgelegt. Im Anschluß daran folgen bis $ffc0 die Linienpuffer, in denen fürs spätere Löschen die Koordinaten der gemalten Linien gespeichert werden. Bei einem Doublebuffering würden sie nicht mehr benötigt, so daß der Bereich von $fa97 bis $ffc0 frei wird, immerhin $529 Bytes.
    Ich muß an dieser Stelle aber nochmal darauf hinweisen, daß es für schwerwiegende Patches absolut notwendig ist, einen relokatiblen Code zur Verfügung zu haben. Bisher liegt mir ein solcher für den C64 leider noch nicht vor.
    Ein weiter Aspekt, den man beim Double-Buffering beachten sollte, ist die Malroutine für die Sonne. Bislang wird die Sonne nur gemalt, wenn sich ihr Radius ändert oder sie ihre Position in der Anzeige verändert, denn das Neumalen der Sonne ist recht aufwendig und dauert sehr lange. Für ein Double-Buffering wäre es aber erforderlich, die Sonne jedes Mal komplett neu zu zeichnen. Da müßte man also auch sehen, ob sich der Malprozeß beschleunigen läßt.
    Und noch ein Nachtrag zu der Idee, Platz zu schaffen, indem man Modelldaten auslagert: Da insgesamt 10 Objekte gleichzeitig berechnet werden können, müßte man einen Cache von ca. 9 * 512 = $1200 Bytes reservieren. 9 anstelle von 10, da im Sonnensystem ein Objekt stets der Planet ist, und im Witchspace nur zwei Modelle (Thargoid und Thargon) gebraucht werden. Die Modelle belegen über $1c00 Bytes, so daß man per Nachladen $a00 Bytes gewinnen könnte. Jetzt muß man mal durchrechnen, ob das insgesamt reicht, um einen Double-Buffer (mit Zeichensatz) einzurichten, oder ob noch mehr ausgelagert werden müßte.

    Zitat von M. J.

    Ein weiter Aspekt, den man beim Double-Buffering beachten sollte, ist die Malroutine für die Sonne. Bislang wird die Sonne nur gemalt, wenn sich ihr Radius ändert oder sie ihre Position in der Anzeige verändert, denn das Neumalen der Sonne ist recht aufwendig und dauert sehr lange.


    Ich schätze mal, das liegt daran, dass die Sonne gefüllt wird.


    Zitat von M. J.

    Für ein Double-Buffering wäre es aber erforderlich, die Sonne jedes Mal komplett neu zu zeichnen. Da müßte man also auch sehen, ob sich der Malprozeß beschleunigen läßt.


    Ohne dass ich jetzt eine genaue Vorstellung habe: Wie wäre es, wenn man die Sonne auch als Wireframe darstellt, so wie die Planeten? Aber in der jetzigen, ausgefüllten Form ist es natürlich stimmungsvoller, wenn man in die gleißende Sonne hineinfliegt.


    Zitat von M. J.

    Und noch ein Nachtrag zu der Idee, Platz zu schaffen, indem man Modelldaten auslagert:


    Bringt es denn was, die Modelldaten vorgepackt im Speicher vorzuhalten? Zum Beispiel per Exomizer und zur Laufzeit nur die jeweils benötigten auszupacken. Wäre wohl schneller als nachzuladen. Oder frisst der Overhead unterm Strich die Speicherersparnis wieder auf?

    Zitat von ogd

    ber in der jetzigen, ausgefüllten Form ist es natürlich stimmungsvoller, wenn man in die gleißende Sonne hineinfliegt.

    Das ist es sicherlich, zumal der linke und rechte Rand der Sonne schön zufällig ausgefranst werden. Für O.O.B. hatte ich zwar eine schnelle, allgemeine Routine zum Kreisefüllen erstellt, aber die ist leider recht lang. :(

    Zitat von ogd

    Bringt es denn was, die Modelldaten vorgepackt im Speicher vorzuhalten?

    Interessante Frage. Da ich nicht weiß, nach welchem Verfahren der Exomizer packt, kann ich über die Ersparnis nicht urteilen. DIe Daten sind von Modell zu Modell sehr unterschiedlich lang. Auch sind die Werte sehr gemischt, so daß ich nicht weiß, wo hier ein Packer ansetzen könnte.
    Hier mal ein Beispiel:

    Gesamtlänge ungepackt: $c4 Bytes. Mit Exomizer gepackt: ?? Bytes.
    Blöd ist, daß zwei Modelle, CobraMkIII und Python, zweimal in der Objektliste auftauchen (einmal als Frachter, einmal als Pirat), aber die Meshes nur einmal abgelegt werden und bei der zweiten Objektdefinition die Zeiger (s. o.) auf das erste Modell zeigen. Bei einem Packer müßte man daher die Objektdaten an diesen Stellen verdoppeln.


    Generell könnte aber die Verwendung eines Packers Vorteile bringen, z. B. auch bei der Kopie der Cockpitgraphik. IIRC liegt diese ungepackt im Speicher vor. Weitere Möglichkeiten fürs Packen wären dann die bereits erwähnten Routinen für Ankauf, Verkauf, Equipmentkauf, sowie Titel und Game Over. Da diese Routinen jede für sich genommen nicht sonderlich lang sind, würde ein Entpacken wahrscheinlich gar nicht auffallen.


    Ach ja, einen ganz extrem wichtigen Grund gibt es aber noch, warum ein Doublebuffering von "Elite" grundsätzlich nicht gelingen kann: Bei der Titelgraphik werden die Texte "--- Elite ---", "Neuen Commander laden (J/N)?" und "(C) D.Braben & I.Bell 1985" eingeblendet. Bei einem Doublebuffering würde stets die gesamte Anzeige gelöscht werden und damit auch die Schrift. Ein andauernd wiederholtes Neumalen des ganzen Textes für jeden Frame wäre jedoch viel zu langsam. Konsequenz: "Elite" mit Doublebuffering funktioniert prinzipiell nicht.

    Zitat von M. J.

    Ach ja, einen ganz extrem wichtigen Grund gibt es aber noch, warum ein Doublebuffering von "Elite" grundsätzlich nicht gelingen kann: Bei der Titelgraphik werden die Texte "--- Elite ---", "Neuen Commander laden (J/N)?" und "(C) D.Braben & I.Bell 1985" eingeblendet. Bei einem Doublebuffering würde stets die gesamte Anzeige gelöscht werden und damit auch die Schrift. Ein andauernd wiederholtes Neumalen des ganzen Textes für jeden Frame wäre jedoch viel zu langsam. Konsequenz: "Elite" mit Doublebuffering funktioniert prinzipiell nicht.


    Und wenn man den Text per Spriteoverlay darstellt?


    Apropos Sprites: Wozu werden die benutzt? Für die Trebbles oder wie die nervigen Dinger heissen. Auch wenn ich was abschiesse, sieht die Explosion nach Multicolorsprite aus. Was noch?

    Zitat von M. J.

    Da ich nicht weiß, nach welchem Verfahren der Exomizer packt, kann ich über die Ersparnis nicht urteilen.

    Soweit ich mich erinnere verwendet Exomzier eine Kombination aus Lempel-Ziv und Huffmancodierung, garniert mit einem Brute-Force-Ansatz um noch das letzte Byte rauszuquetschen.

    Danke für deine Arbeit an Elite M.J.


    Es gibt zwei kleine Grafikfehler nachdem Elite gestartet wurde. Die Routine ab $B093 schreibt auf Adresse $5769 - $576A.
    Und in der Bitmap ab Adresse $EF90 gibt es einen Pixelfehler bei $F071, kann durch $14 leicht behoben werden.

    Zitat von ogd

    Und wenn man den Text per Spriteoverlay darstellt?

    Dazu müßte man dann auch eine neue Ausgaberoutine zum Malen der Zeichen in die Sprites erstellen.

    Zitat von ogd

    Apropos Sprites: Wozu werden die benutzt?

    Laserfadenkreuz, Explosionen und Trumble IIRC.

    Zitat von Acorn

    Und in der Bitmap ab Adresse $EF90 gibt es einen Pixelfehler bei $F071, kann durch $14 leicht behoben werden.

    Oha, das sieht so aus, als wäre dieser Fehler bereits im Original vorhanden. Ich habe es gerade mit dem Original (.g64) verglichen, und auch hier findet sich der Wert $04 an Adresse $f071. Kann ich aber gerne patchen.


    Der zweite Pixelfehler durch $b093 bereitet mir etwas Kopfzerbrechen. Bei $b091 befindet sich die Routine zum Punktsetzen und wird hier zum Malen der Radaranzeige gebraucht. Auch dieser Fehler ist bereits in der Originalversion vorhanden. Wie er aber entsteht, kann ich leider nicht sagen. :(

    Woran wird denn erkannt, welcher Normalenvektor welche Linien steuert?
    Ich hätte eine Liste erwartet, die zu Flächen alle Linien aufzählt.
    War da nicht mal was, dass man die Sichtbarkeit einer Fläche auch an der Richtung der Kanten erkennen kann, Uhrzeigersinn oder entgegen?


    Und was spricht dagegen, den Text der Titelgrafik bei jedem Bild neu zu schreiben? Die etwas geringere Framerate?

    Zitat von Hoogo

    War da nicht mal was, dass man die Sichtbarkeit einer Fläche auch an der Richtung der Kanten erkennen kann, Uhrzeigersinn oder entgegen?

    Back-face Culling

    Zitat von Hoogo

    Woran wird denn erkannt, welcher Normalenvektor welche Linien steuert?

    In der Linienliste gibt der erste Wert an, bis zu welcher Entfernung (Z) die Linie sichtbar ist. Der Maximalwert ist $1f.
    Der zweite Wert besteht aus 2 Nibbles, die den Index ergeben auf 2 Normalenvektoren. Ist einer der beiden sichtbar, wird die Linie gemalt. Normalerweise begrenzen Linien zwei Flächen, daher gibt es zwei Normalenvektoren. In dem Fall, daß eine Linie allein auf eine Fläche angebracht ist (z. B. eine Schubdüse), wird der Index verdoppelt. (s. die letzten beiden Linien, die zwei Streifen auf die untere Fläche zeichnen.)

    Zitat von Hoogo

    Ich hätte eine Liste erwartet, die zu Flächen alle Linien aufzählt.

    "Elite" organisiert die Daten nicht in Polygone, da dies bedeuten würde, daß man eine Linie bei einem reinen Linienmodell als Kante zweier Polygone unnötig doppelt zeichnen würde.
    Das Programm geht wie folgt vor:
    Zuerst werden alle Normalenvektoren berechnet, die angeben, ob eine Fläche sichtbar ist. Erst danach werden die Punkte berechnet abhängig davon, ob sie zu einer Fläche gehören, die sichtbar ist. Als letzten Schritt werden dann die Linien gezeichnet.
    Beim Backface-Culling werden die Punkte immer berechnet. Damit ist das Vefahren langsamer, aber auch genauer, da es die Information über die Sichtbarkeit direkt aus den fertig berechneten 2d-Bildschirmkoordinaten entnimmt. Die Orientierung der Normalenvektoren wird im 3d-Raum berechnet, jedoch ohne richtige Berücksichtigung der perspektivischen Verzerrung, was zu Darstellungsfehlern führen kann. (Eine Fläche wird fälschlich sichtbar oder unsichtbar.) Ein Nachteil beim Back-face Culling ist jedoch, daß bei Punkten, die in der perspektivischen Abbildung direkt übereinander liegen, bei der Berechnung der SIchtbarkeit die Differenzen von y1 und y2 bzw. x1 und x2 halt 0 sind und damit einen unbrauchbaren Wert erzeugen. Das ist bei reinen Dreiecken nicht tragisch, will man aber Vierecke dabei haben und nimmt dazu 3 Punkte, von denen zwei übereinander liegen, kann auch dies zu Fehlern führen.

    Zitat von M. J.

    In der Linienliste gibt der erste Wert an, bis zu welcher Entfernung (Z) die Linie sichtbar ist. Der Maximalwert ist $1f.

    D.h. bei großer Entfernung vereinfachen sich die Modelle? Hübsch! 8)

    Zitat von M. J.

    "Elite" organisiert die Daten nicht in Polygone, da dies bedeuten würde, daß man eine Linie bei einem reinen Linienmodell als Kante zweier Polygone unnötig doppelt zeichnen würde.

    Oder es müsste halt erst gefundene Linien markieren, dann in einem 2. Durchlauf alle zeichnen. Ich vermute, sowas wie eine Markierung muss es heute schon für die Eckpunkte geben, damit die nicht bei jeder Linie neu berechnet werden müssen.

    Zitat von M. J.

    Das Programm geht wie folgt vor:
    Zuerst werden alle Normalenvektoren berechnet, die angeben, ob eine Fläche sichtbar ist. Erst danach werden die Punkte berechnet abhängig davon, ob sie zu einer Fläche gehören, die sichtbar ist. Als letzten Schritt werden dann die Linien gezeichnet.

    Lohnt sich das? Ich schätze, das 75% der Eckpunkte eh berechnet werden müssen. Der Aufwand, Normalenvektor oder Punkte zu berechnen scheint mir auch den gleichen Aufwand zu machen. 9 Normalen und 12 Punkte wären also Pi mal Daumen 18 Rechnungen.

    Zitat von M. J.

    Interessante Frage. Da ich nicht weiß, nach welchem Verfahren der Exomizer packt, kann ich über die Ersparnis nicht urteilen. DIe Daten sind von Modell zu Modell sehr unterschiedlich lang. Auch sind die Werte sehr gemischt, so daß ich nicht weiß, wo hier ein Packer ansetzen könnte.
    Hier mal ein Beispiel: (...)
    Gesamtlänge ungepackt: $c4 Bytes. Mit Exomizer gepackt: ?? Bytes.


    Habe mal dein Beispiel durch Exomizer gejagt. Als "raw" ohne weitere Parameter wird das Outputfile grösser wird (201 Bytes):



    Mit dem Parameter "-E" (don't write the encoding to the outfile) kommt eine Dateigrösse von 175 Bytes raus:



    Kannst du vieleicht die Modelldaten en bloc zur Verfügung stellen? Nach Möglichkeit auch als Binärdatei. Ich schau mal dann, was sich noch rausholen lässt.


    Zitat von M. J.

    Generell könnte aber die Verwendung eines Packers Vorteile bringen, z. B. auch bei der Kopie der Cockpitgraphik. IIRC liegt diese ungepackt im Speicher vor.


    Auch diese Datei bitte, wenn es nicht zu umständlich ist. Da lässt sich bestimmt mehr einsparen als oben.

    Zitat von Hoogo

    Und was spricht dagegen, den Text der Titelgrafik bei jedem Bild neu zu schreiben? Die etwas geringere Framerate

    Gering ist gut. ^^ Der Effekt könnte deutlich spürbar werden, da die Buchstaben einzeln als Graphik gemalt werden müssen, und die Routine dafür ist auch nicht gerade die schnellste.

    Zitat von Hoogo

    Ich vermute, sowas wie eine Markierung muss es heute schon für die Eckpunkte geben, damit die nicht bei jeder Linie neu berechnet werden müssen.

    So ist es. In der Punkteliste geben die ersten drei Bytes die X-, Y- und Z-Werte als Absolutwerte an. Das vierte Byte enthält wieder die maximale Entfernung (die unteren 5 Bits) und die Vorzeichen für X, Y und Z (obere 3 Bits). In den letzten beiden Bytes geben die vier Nibbles an, zu welchen Normalenvektoren ein Punkt gehört.

    Zitat von Hoogo

    Lohnt sich das? Ich schätze, das 75% der Eckpunkte eh berechnet werden müssen. Der Aufwand, Normalenvektor oder Punkte zu berechnen scheint mir auch den gleichen Aufwand zu machen. 9 Normalen und 12 Punkte wären also Pi mal Daumen 18 Rechnungen.

    Genau die Frage habe ich mir auch seit Jahren immer wieder gestellt, aber so leicht lassen sich die "Rechnungen" nicht zusammenfassen. Wenn ich es richtig erinnere, braucht die Berechnung der Normalenvektoren einmal eine Vollrotation der Objektkoordinaten, um die Sichtbarkeit gemessen an der Position des Objekts relativ zur Kamera zu ermitteln, und darauf für jeden Vektor 3 Multiplikationen. Das ist nicht so viel.
    Eine Punktberechnung hingegen benötigt 9 Multiplikationen und 2 Divisionen. Um ein Back-face Culling durchzuführen (mit Back-face Culling meine ich das in 2d auf Basis der Bildschirmkoordinaten), braucht man für jede Fläche 2 Multiplikationen. Da erscheint die Berechnung der Normalenvektoren gar nicht so ungünstig zu sein. Zudem haben die Modelle bei "Elite" oftmals Verzierungen (wie Schubdüsen oder das Dockingtor der Station), deren Punkte komplett herausfallen, wenn die Fläche nicht sichtbar ist.
    Ein weiterer Grund, warum sich das Nichtberechnen eines Punktes rentieren könnte, ist, daß die Matrixmultiplikation der Punktkoordinaten bei "Elite" (zu finden bei $9a13) aus Platzgründen leider nicht besonders effizient ist, sondern über die Vektorbestandteile x, y und z mit jeweils 3 Multiplikationen und 2 Additionen in Form von Subroutinenaufrufen pro Durchlauf iteriert. Wie bereits erwähnt, hatte ich mit der AppleII-Version herumexperimentiert und u. a. eine neue Berechnungsroutine eingebaut. Das Ergebnis war leicht schneller aber sah vor allen Dingen genauer aus, was allerdings auch kein Wunder ist, da die Multiplikation mittels Logarithmus nicht sonderlich exakt ist und außerdem vom 2-Byte-Ergebniswert der Multiplikation nur der obere Anteil für die Weiterberechnung herangezogen wird.

    Zitat von ogd

    Kannst du vieleicht die Modelldaten en bloc zur Verfügung stellen?

    Hab mal eine ZIP-Datei angehängt mit diversen Bin-Dateien: 33 Einzeldateien für die Objekte, 1 Gesamtdatei für alle Objekte und 1 Datei mit der Cockpitbitmap.
    Das Packen der Objektdaten dürfte nicht so leicht werden, denn die Daten müssen für den Gebrauch ja ungepackt vorliegen. Dazu wäre der bereits erwähnte Cache nötig, der aber ca. $1400 benötig. Die Objektdaten umfassen insgesamt $1ee4 Bytes. Die wird man kaum in $1ee4 - $1400 = $ae4 Bytes reinquetschen können. Und dann braucht man ja noch einen Gewinn, damit es sich lohnt.
    Bei der Cockpitgraphik sieht es anders aus. Das hat die C128-Version bereits gezeigt.
    Und noch etwas: Es sieht so als, als würden von $cf00..$cfff nur die unteren $50 Bytes als Ladepuffer beim Laden eines Spielstands benötigt, so daß die oberen von $cf50 bis $cfff frei sind. Außerdem kann man überlegen, den Ladepuffer in einen Bereich zu verlegen, der ohnehin als temporärer Puffer verwendet wird wie z. B. der Linienpuffer. Dann hätte man die ganze Seite $cf00 bis $cfff frei.

    Zitat von Acorn

    Es gibt zwei kleine Grafikfehler nachdem Elite gestartet wurde. Die Routine ab $B093 schreibt auf Adresse $5769 - $576A.

    Bin der Sache mal nachgegangen und mußte feststellen, daß es sich hierbei um ein "Feature" handelt. Der Pixelfehler ist tatsächlich der Radarpunkt, der normalerweise auf den Planeten oder die Station verweist. Beim Malen der Cockpitgraphik wird neben den Anzeigen für Geschwindigkeit oder Energie auch dieser Radarpunkt gemalt, der allerdings beim Titel nirgendwo hinzeigt, wodurch der Punkt in die rechte, obere Ecke gesetzt wird. Daher habe ich in der Routine zum Anzeigen der Raumschiffe die Malroutine für den Radarpunkt erneut aufgerufen, wodurch dieser wieder gelöscht wird. Die Titelanzeige enthält nun keinen Fehler mehr. Vielen Dank für die Hinweise!
    Eine kleine Rückfrage hätte ich allerdings: Woher wußtest Du, daß die Originalbitmap für das Cockpit im Bereich $ef90.. liegt? Kennst Du Dich vielleicht aus mit den Interna von Elite? (Der Name "Acorn" ist jedenfalls auffällig. ^^ )

    Nein leider nicht, da bist du viel tiefer drin. Wollte nur wissen wodurch dieser Fehler im Radar entsteht.
    Der Monitor von Vice ist schon klasse, einfach mit watch und hunt und schon war die Bitmap gefunden.


    Kurze Geschichte dazu und warum ich nochmal Elite angepackt habe.
    So um Ende 2003 hatte ich die Idee alle Spiele die ich auf Tape (Turbotape) habe ohne Crackintro zu erstellen.
    Da ich alle von Originale (Tapes) haben wollte benutzte ich Final Tap dazu. Ziel war ist die Version soll so kurz wie möglich sein.
    Dafür kam nur Exomizer in Frage, da gab es noch kein ALZ, dieser ist aber auch viel zu langsam beim entpacken und fällt durch.
    Wenn man bedenkt das ich da noch kein 6502 Assembler könnte hatte ich denn noch viele Spiele lauffähig gepackt.


    Nebenbei für alle in Original Spiele.
    Man findet in einigen Spielen Botschaften die wohl für die damaligen Cracker bestimmt waren.
    Aber es gibt auch Nachrichten wie in frantic freddie das freddie was here im Speicher zu finden ist.


    Zurück zu Elite.
    Da deine Version so viel kürzer war als meine wollte ich wissen warum. Beim Vergleich der Bytes mit Maxon-Ass sah ich das ziemlich viele Bytes anders sind.
    Ein kurzer Check mit der G64-Version zeigte das selbe. Dann wollte ich mir noch mal die Punkt-Routine anschauen und sah das diese noch gar nicht lesbar ist.
    Die Routine ab $2022 dekodiert die Daten, nachdem decodieren und löschen der Routine ist Elite jetzt 34241 Bytes lang.


    Aber deine Version gefällt mir viel besser ohne das Flimmern der Linien ist Elite nach mal doppelt so schön.


    Noch mal DANKE dafür.

    Rein Theoretisch.


    Ist bei einer Adaption von Elite auf die SCPU unter Verwendung von 16Bit Code sehr viel mehr möglich
    oder hält sich dass in Grenzen.



    Ich habe übrigens auch eine Botschat im Spiel gefunden



    Gefunden im Spiel Mindshadow


    Track 35 Sektor 00

    GREETINGS

    WE, THE PEOPLE
    FROM INTERPLAY
    PRODUCTIONS WISH
    TO CONGRADULATE
    YOU FOR FINDING
    THIS MESSAGE
    CALL
    (a8,b7,b1,b4,a9,a0,b6,b5,b0,ad,a0,b0,b7,b0,b7)
    AND ASK FOR
    CAPTAIN FARGO
    SIGNED¬ BURGER



    Track 35 Sektor 15


    COMMODORE SUCKS
    APPLE RULES¡¡¡

    Zitat von Klaus Scheuer

    (a8,b7,b1,b4,a9,a0,b6,b5,b0,ad,a0,b0,b7,b0,b7)

    = "(714) 650- 0707"
    Becky war schon immer ein großer AppleII-Fan. :D

    Zitat von Klaus Scheuer

    Ist bei einer Adaption von Elite auf die SCPU unter Verwendung von 16Bit Code sehr viel mehr möglich
    oder hält sich dass in Grenzen.

    Allgemein würde das Spiel natürlich von der höheren Geschwindigkeit der SCPU profitieren. Aber Du fragst gezielt nach dem erweiterten Befehlssatz des 65816, und in der Hinsicht würde ich vermuten, daß sich, folgt man den Algorithmen des Originals, die Verwendungsmöglichkeiten der neuen Befehle eher in Grenzen halten.
    Die Berechnungen der 3d-Graphik beruhen zumeist auf 8-Bit-Operationen. 16 Bit wird verwendet für die Objektkoordinaten, Bildschirmpunkte und Matrixwerte, doch liegen diese häufig in einem ungewöhnlichen Format vor (nicht 2er-Komplement, sondern Absolutwert mit Vorzeichen). Damit ergeben sich direkt nur wenig Ansätze, um den ursprünglichen Code zu verbessern. Bedauerlicherweise verfügt der 65816 (wie auch 65CE02) auch weiterhin über keinen Multiplikationsbefehl, so daß sich ausgerechnet bei dieser häufigen Operation durch Verwendung von neuen Befehlen allein kein Gewinn ergibt.
    Was das Spiel wirklich verbessern würde, wäre ein Umschreiben größerer Codeteile mit Hilfe von mehr Ram, z. B. um die Multiplikation über Quadratzahlen abzuwickeln, da diese genauer und mindestens ebenso schnell funktionieren wie die Multiplikation mit Hilfe der Logarithmentabellen. Außerdem könnte man natürlich die ganzen Malroutinen so abändern, daß sie mit 16 Bit rechnen, was noch genauere Ergebnisse aber auch einen Geschwindigkeitszuwachs erbringen würde. Diese Effekt läßt sich aber bereits mit dem 6502 erzielen, vorausgesetzt ausreichend Speicher ist vorhanden. Der entscheidende Faktor ist also das Ram und nicht der Befehlssatz.

    Zitat von Acorn

    So um Ende 2003 hatte ich die Idee alle Spiele die ich auf Tape (Turbotape) habe ohne Crackintro zu erstellen.

    Nachvollziehbarer Ansatz. Für den AppleII gibt es inzwischen einen ganzen Haufen von "clean cracks", bei denen lediglich der Kopierschutz entfernt, aber ansonsten das Spiel so gelassen wurde, wie es im Original gedacht war (, was nicht ausschließt, daß man offensichtliche Bugs beheben kann).

    Zitat von Acorn

    Man findet in einigen Spielen Botschaften die wohl für die damaligen Cracker bestimmt waren.

    Hab ich auch schon gefunden. ^^

    Zitat von Acorn

    Die Routine ab $2022 dekodiert die Daten

    Die Verschlüsselung mußte ich herausnehmen, da man das Spiel sonst nicht patchen kann. Daß dadurch der Packer besser arbeitet, war ein netter Nebeneffekt. $2022 ist der Einsprungspunkt nach dem Laden des Spiels. Von dort aus wird noch eine Initialisierungsroutine angesprungen und danach geht es mit der Titelgraphik weiter. Beim Patch habe ich den Einsprungspunkt und diese Initialisierungen in den Bereich bei $4000 verschoben, der später als Bitmap überschrieben wird. Dadurch konnte ich den Bereich bei $2022 und an anderer Stelle für eigene Routinen verwenden.

    Zitat von Acorn

    Aber deine Version gefällt mir viel besser ohne das Flimmern der Linien ist Elite nach mal doppelt so schön.

    Freut mich, wenn es gefällt, aber leider war die Version nur eine Testversion, was man auch daran erkennen kann, daß ich Cheats eingebaut sowie das zweite Raumschiff vom Titel (Adder) aus Jux gegen einen Krait ausgetauscht habe. Das entspricht nicht wirklich dem Original. Meine Absicht ist, noch ein paar andere Patches vorzunehmen und auszutesten und dann eine neue Version hier hochzuladen. Leider ist der disassemblierte Code bislang noch nicht relokatibel. Es gibt wohl noch einige Sprungtabellen sowie Zeigeroperationen, die ich umwandeln muß. Um die Labels an gleicher Stelle zu haben, schreibe ich bisher in den beim Patchen frei werdenden Platz einfach nur "NOP"s rein. Wenn der Code erst einmal relokatibel ist, kann man ganz interessante Sachen damit anstellen.