Elite DX Easyflash

Quote from kugelfuhr

Goodie am Rande: Da ist eine Schiffs-Enzyklopädie drin.

Das sieht gut aus. Interessant, wie weit Deine Entwicklung vorangeschritten ist.

Quote from kugelfuhr

Die REU braucht 1 Zyklus pro Byte

Beherrscht die REU denn auch die Behandlung von "rechteckigen" Bereichen im Speicher so wie der Blitter beim Amiga? Wenn nicht, müßte man entweder den Bildschirm unterteilen in 144 / 8 = 18 Unterzeilen und diese getrennt löschen (, was einiges an Overhead erfordert,) unter Berücksichtigung der obersten Linie, die den Rahmen enthält, oder die ersten 144 Zeilen der Bitmap komplett mit linken und rechten Rand aus der REU in die Bitmap umkopieren.

Quote from kugelfuhr

Das "Fenster" ist 256 Pixel breit und 144 Pixel hoch

Hattest Du auch mal daran gedacht, die Anzeige auf die volle Bereite (320) zu erhöhen? Eigentlich ist die Beschränkung auf 256 Pixel keine unbedingte Notwendigkeit, da die Bildschirmkoordinaten ohnehin als 16 Bitwerte abgelegt werden. Für viele Anzeigen (Status usw.) böten aber 320 Pixel mehr Fläche für die Datenausgabe. Bekanntlich kommt es bei der deutschen Version bei einigen Planetenbeschreibungen zu einem Überlauf in der Anzahl der verfügbaren Textzeilen, woraufhin die Anzeige gelöscht, der Cursor in die obere, linke Ecke gesetzt und dort mit der Ausgabe fortgefahren wird.

Quote from kugelfuhr

Ich weiss ja nicht genau, was Ihr vorhabt, aber eine Elite Version auf der originalen Hardware würde ich eher nicht mehr machen. Das kriegt man nicht so schnell, dass es richtig schön zu spielen ist.

Hmm... Da wäre ich mir nicht so sicher. "Schön" ist ja relativ. Mit der Bildrate heutiger Spiele kann man natürlich nicht mithalten, aber was Brauchbares dürfte schon noch machbar sein. Persönlich habe ich "Space Rogue" immer gerne gespielt und dabei bewußt die 8 Bit-Version verwendet und nicht z. B. die vom Amiga. Als Ausgleich zum Bildschirmlöschen beim DoubleBuffering kann man ja auch andere Teile des Programms beschleunigen. Meine Frage wäre daher an dieser Stelle: Inwieweit hast Du in die Berechnungen selbst eingegriffen? Konntest Du z. B. den Code für die Objektvisualisierung optimieren?

Ich muss wohl der einzige sein, der sich schon immer einen "Chill and Easy" Modus für Elite gewünscht hat. Einfaches docken. Einen "peaceful" Modus, zum gefahrlosen herumfliegen. Oder einfach deutlich weniger Überfälle (ganz ehrlich, in so einem Universum gibt's ganz schnell garkeinen Handel mehr). Eine Bank.

Aber bin mal gespannt was ihr so bastelt. Danke für all die Arbeit! Ich habe immer nur die Amstrad version damals gespielt, boah ist das lange her.

Ich habe Elite schon ein paar Stündchen im Emuiator gespielt und fand die Gegner ehrlich gesagt schlimmer als das Landen auf den Stationen.

Erstmal kommen gut und gerne 3-5 auf einmal und dann derart oft, dass ich dann auf die Trainerversion umgestiegen bin und mir unendlich Schilde gegönnt habe.

Zumal man, wenn man tatsächlich die Gegner besiegt hat, dann nicht mehr mit "J" den Kurzsprung machen konnte (Zumindest konnte ich das in sämtlichen Versionen nicht).

Dann konnte man nur warten. War am Emulator zum Glück kaum - garnicht ein Problem.

Also ein peaceful Modus würde mir auf dem Maxi durchaus gelegen kommen.

Aber ich kann auch nur Danke sagen, für alles und jeden der die alten Spiele auseinander friemelt um der Community was gutes zu tun. Danke!

Boah ey - ich komme gerade von der anderen Seite des Universums - da soll es ein Space Game geben was 52 Gigabyte groß ist

Ich finde sehr cool was ihr mit Elite vorhabt - ich muss gestehen, ich habs daaamals™ auf dem C64 kaum gedaddelt (geschnallt) - vielleicht jetzt?

Quote from M. J.

Beherrscht die REU denn auch die Behandlung von "rechteckigen" Bereichen im Speicher so wie der Blitter beim Amiga? Wenn nicht, müßte man entweder den Bildschirm unterteilen in 144 / 8 = 18 Unterzeilen und diese getrennt löschen (, was einiges an Overhead erfordert,) unter Berücksichtigung der obersten Linie, die den Rahmen enthält, oder die ersten 144 Zeilen der Bitmap komplett mit linken und rechten Rand aus der REU in die Bitmap umkopieren.

Nein, rechteckige Bereiche gehen nicht. Das ist aber trotzdem nicht sehr aufwendig. Die eigentliche Schleife für das Löschen sieht so aus:

Das praktische an der REU ist, dass sie die CPU während des DMAs anhält, d.h. nach dem sta REU_COMMAND wird gelöscht und zum iny ist bereits die Zeile fertig.

Quote from M. J.

Hattest Du auch mal daran gedacht, die Anzeige auf die volle Bereite (320) zu erhöhen? Eigentlich ist die Beschränkung auf 256 Pixel keine unbedingte Notwendigkeit, da die Bildschirmkoordinaten ohnehin als 16 Bitwerte abgelegt werden.

Nein, das war für mich bisher kein Thema. Für das obere Fenster ist die Beschränkung mehr oder weniger zwingend, weil sonst alle damit verbundenen Berechnungen langsamer werden. Bei der derzeitigen Aufteilung können alle Zeilen mit einem 8-Bit Indexregister adressiert werden. Wenn Du das Fenster größer machst, dann brauchst Du zusätzliche Adresskalkulationen innerhalb einer Zeile. Für das DTV oder die SCPU könnte man sich das mal überlegen, aber beim nackten C64 verschärft es die Zeitprobleme nochmals erheblich.

Für den Statusbereich unten wäre es evtl. eine Möglichkeit. Man könnte auch im angedockten Zustand die ganze Breite nutzen, bloss verkompliziert das alle Routinen (z.B. Textausgabe). Die werden nämlich in beiden Modi genutzt.

Quote from M. J.

Hmm... Da wäre ich mir nicht so sicher. "Schön" ist ja relativ. Mit der Bildrate heutiger Spiele kann man natürlich nicht mithalten, aber was Brauchbares dürfte schon noch machbar sein. Persönlich habe ich "Space Rogue" immer gerne gespielt und dabei bewußt die 8 Bit-Version verwendet und nicht z. B. die vom Amiga.

Ich habe natürlich gut reden, aber ... Wenn Du mal DTV Elite gespielt hast, dann willst Du die C64 Version eigentlich nicht mehr. Ich liebe dieses Spiel, sonst hätte ich nicht so viel Arbeit reingesteckt. Aber wenn die Framerate im Witch Space auf 2 fps zusammenbricht und Du überhaupt keine Chance mehr gegen die Thargoiden hast, weil nichts mehr bedienbar ist, dann ist das bloss noch ätzend. Das Spiel stammt halt von einem doppelt so schnellen Rechner (der BBC hatte eine 2MHz CPU). Das hat auch wenig mit 8 oder 16 Bit zu tun, sondern mit dem Spiel an sich. "Space Rogue" hat wahrscheinlich keine Level die quasi unspielbar werden, weil die CPU zu langsam ist.

In der DTV Version bleibt die Framerate auch bei vielen Gegnern hoch und es spielt sich weiterhin flüssig. Ich habe da zum ersten Mal realisiert, welche eleganten Bogen die Gegner um mich herum fliegen

Quote from M.J.

Als Ausgleich zum Bildschirmlöschen beim DoubleBuffering kann man ja auch andere Teile des Programms beschleunigen. Meine Frage wäre daher an dieser Stelle: Inwieweit hast Du in die Berechnungen selbst eingegriffen? Konntest Du z. B. den Code für die Objektvisualisierung optimieren?

An den 3D Berechnungen war ich nicht. Ich gehe aber davon aus, dass dort nicht viel Luft drin sein dürfte, weil sie genau so auf vielen verschiedenen Rechnern eingesetzt wurden und von vielen Leuten begutachtet wurden. Die Routinen zur Zeichenausgabe und für die Linien wurde für den C64 geschrieben. An der Textausgabe läßt sich einiges optimieren, das bringt während des Flugs aber wenig. An den Zeichenoperationen geht ein bisschen was, aber auch das geht unter.

Ich bezweifle auch, dass Du mit solchen Peep Hole Optimierungen wirklich viel rausholen kannst. Es geht ja nicht um ein paar Prozent, sondern um Größenordnungen. Damit das Spiel wirklich gut wird sollte die Framerate bei einem massiven Gegner Angriff (z.B. Witch Space) auf zumindest 6-8 fps steigen. Und das sind keine 30%, sondern Faktor 3, d.h. 300%.

Vielleicht geht noch ein bisschen bei den 3D Routinen, etwas bei der Multiplikation usw. Aber das ist alles sehr aufwendig und fehlerträchtig und in Summe kommen vielleicht 30% Geschwindigkeitsvorteil raus (wenn Du wirklich viel Arbeit reinsteckst). Ich helfe gerne bei mit, aber meiner Einschätzung nach wird es nicht gelingen, das Spiel auf einem nackten C64 wirklich gut hinzubekommen. Ich lasse mich aber gerne eines besseren belehren!

BTW: Was kann denn die Easyflash? Ist das nur eine Speichererweiterung, oder sind da auch andere Hardware Features dabei (DMA/CPU)?

Quote from Davidorado

Ich habe Elite schon ein paar Stündchen im Emuiator gespielt und fand die Gegner ehrlich gesagt schlimmer als das Landen auf den Stationen.

Erstmal kommen gut und gerne 3-5 auf einmal und dann derart oft, dass ich dann auf die Trainerversion umgestiegen bin und mir unendlich Schilde gegönnt habe.

Elite 128 hat einen "god mode". Ja, auch in der Version 1.0 (diesmal habe ich genau geschaut). Bei angehaltenem Spiel (Del) die Erweiterungen mit 'X' freischalten, dann 'G' für "god mode". Und für die ganz faulen gibt's den Commander "Fatty", der direkt mit 1000 Credits und Docking Computer startet. Bloss den Namen wirst Du ohne Patchen dann nicht mehr los

...BTW: Was kann denn die Easyflash? Ist das nur eine Speichererweiterung, oder sind da auch andere Hardware Features dabei (DMA/CPU)?

Die Easyflash blendet ab $8000 bis $bfff adressierberes ROM ein. Das wird mittels Bankschaltung, durch das beschreiben von $de00 erreicht. Es ist um vieles schneller als die REU die Daten in das RAM kopiert.

Quote from kugelfuhr

Elite 128 hat einen "god mode". Ja, auch in der Version 1.0 (diesmal habe ich genau geschaut). Bei angehaltenem Spiel (Del) die Erweiterungen mit 'X' freischalten, dann 'G' für "god mode". Und für die ganz faulen gibt's den Commander "Fatty", der direkt mit 1000 Credits und Docking Computer startet. Bloss den Namen wirst Du ohne Patchen dann nicht mehr los

Sobald dann der erste anfängt auf das eigene Schiffchen zu ballern, setzt sich die friedliche Athmosphäre mit der Rettungskapsel ab. Weiter oben hatte jemand genauer beschrieben was so gemeint ist: das ganze Universum ist nicht mehr so ballerfreudig.

Tun wir mal so als würde jeder Schuss Geld kosten.

Quote from Stephan Scheuer

Die Easyflash blendet ab $8000 bis $bfff adressierberes ROM ein. Das wird mittels Bankschaltung, durch das beschreiben von $de00 erreicht. Es ist um vieles schneller als die REU die Daten in das RAM kopiert.

Ahh ok, danke! Das ist für die von mir durchgeführten Änderungen leider weniger hilfreich. Vielleicht hat jemand anderes eine Idee, wie man dieses Feature nutzen kann.

Quote from kugelfuhr

Das ist für die von mir durchgeführten Änderungen leider weniger hilfreich.

Das ist leider auch aus dem Grunde nicht wirklich hilfreich, weil beim Einblenden einer REU-Bank (soviel ich weiß, habe selber keine REU) gleichzeitig auch IO und Kernal-Rom in den Adreßraum eingeblendet werden. Man kann also nicht z. B. in eine REU-Bank die Malroutine für die Objekte ablegen, diese Routine dann später bei Bedarf einblenden und die Objekte malen, weil die Maldaten im Ram bei $dxxx liegen. Diese wiederum kann man nicht einfach mit in die Modulbank packen, weil zu den Maldaten andere Informationen gehören, die von anderen Programmteilen gebraucht werden. Also müßte man die Maldaten irgendwie doppeln usw. usf. ... Alles sehr umständlich. Im Endeffekt erfordert die Verwendung einer REU im laufenden Programm eine komplette Umstrukturierung des Codes und gezielte Anpassung an die REU. Und selbst wenn man dies erledigt hat, bleibt immer noch das Ärgernis, daß wegen der ROM-Einblendung auch der eigene $fffe-Interrupt weggeschaltet und statt dessen auf den langsamen Kernal-Interrupt mit Vektor $314 umgeschaltet wird. Fazit (leider): Die REU ist gut zum Nachladen von Programmen in Spielpausen (z. B. nach dem Andocken), aber nicht für die Verwendung in Echtzeit.

Quote from kugelfuhr

aber meiner Einschätzung nach wird es nicht gelingen, das Spiel auf einem nackten C64 wirklich gut hinzubekommen.

Da wäre die Frage, was "wirklich gut" bedeutet... Wenn man sagt, daß der c64 generell nicht in der Lage ist, Szenarien wie den Witchspace mit seinen Thargoidenmutterschiffen und Thargonen zu handhaben und Beschleuniger wie das dtv Voraussetzung sind, könnte man die Plattform c64 eigentlich gleich verlassen und auf den Amiga wechseln. Da hat man dann auch gefüllte Polygone und andere Annehmlichkeiten. Ich würde eher sagen, daß der Witchspace mit bis zu 11 Objekten gleichzeitig die Ausnahme ist und nicht die Regel. Daß der c64 bei solch einem Extrem in die Knie geht, ist halt normal für einen 8 Bit-Rechner, und daran werden auch alle Optimierungen nichts ändern. Das wäre aber für mich kein Grund, den c64 aufzugeben oder auf Optimierungen zu verzichten und die Verwendung eines Beschleunigers zur Voraussetzung zu machen.

Quote from kugelfuhr

An den 3D Berechnungen war ich nicht. Ich gehe aber davon aus, dass dort nicht viel Luft drin sein dürfte, weil sie genau so auf vielen verschiedenen Rechnern eingesetzt wurden und von vielen Leuten begutachtet wurden.

Da habe ich große Zweifel. Sie mögen von anderen Programmierern, die den Elitecode portiert haben, übernommen worden sein, aber wohl eher aus dem Grunde, weil sich kein Programmierer die Mühe machen wollte, neue Rechenroutinen zu entwerfen. Braben selbst hat in seinem Virus-Spiel (Amiga-Version) weiterhin den Test auf Sichtbarkeit eines Polygons mit Normalenvektoren vorgenommen, obgleich dort a) stets alle Punkte berechnet werden (kein Überspringen von nichtsichtbaren Punkten), b) die Verwendung der Normalenvektoren langsamer ist und deutlich schlechtere Ergebnisse liefert als das backface culling. Ein Beharren auf einer Methode muß also nicht zwingend bedeuten, daß es sich um die beste Methode handelt.

Was das Malen anbelangt, hat das DoubleBuffering sogar den entscheidenden Vorteil, daß es nur einmal für alle Objekte durchgeführt werden muß, wohingegen das Löschen der Linien durch erneutes Zeichnen mittels XOR bei mehr Objekten um ein Vielfaches langsamer ist. Brutales Löschen der Bitmap ist meiner Erfahrung nach daher eher eine Optimierung als eine Verlangsamung, zumal man damit jede Menge Verwaltungscode im Programm einspart, der ebenfalls seinen Tribut fordert.

Was die 3d-Berechnungen anbelangt, so sind diese in "Elite" auf Kürze getrimmt, aber nicht auf Geschwindigkeit. Gerade wenn wie im Witchspace viele Objekte unterwegs sind, bremst die Berechnung der 3d-Malpunkte das Spiel eklatant aus, denn diese wird vorgenommen, wenn

a) sich das Objekt in einem Bereich befindet, für den gilt (abs(objekt_X) >= objekt_Z) UND (abs(objekt_Y) >= objekt_Z). Das bedeutet nicht, daß dieses Objekt tatsächlich sichtbar ist. In vielen Fällen werden die berechneten Punkte trotzdem außerhalb des Bildschirms liegen. Besonders wenn mehrere Objekte um das eigene Raumschiff herumfliegen, kann man davon ausgehen, daß viele Punktberechnungen umsonst vorgenommen werden.

b) eine Explosion stattfindet. Bei der Explosion werden stets alle Punkte berechnet ungeachtet der Normalenvektoren, was z. B. bei der CobraMkIII mal eben 28 Punkte bedeutet. Auf Grundlage dieser Punkte werden dann mit Hilfe eines Pseudo-Zufallszahlen-Generators herumliegende Punkte generiert. Dieser Vorgang dauert elend lange. Möchte man "Elite" beschleunigen, könnte man hier ansetzen, damit die Explosion eines Gegners nicht sofort das ganze Spiel ausbremst.

Ansonsten ist meiner Erfahrung nach gerade bei der Punktberechnung viel Luft für Verbesserungen. Ein kleines Beispiel:

DIe Routine für die Multiplikation mit Hilfe der Logarithmentabelle sieht so aus:

Hierbei wird ein Faktor in der Zeropage-Adresse $b6 zwischengespeichert und für das Highbyte der Logarithmentabelle wieder hervorgeholt. Kürzer wäre es stattdessen zu schreiben:

Ergebnis: 1 Byte im Code gespart und 2 Taktzyklen in der Ausführung. Klingt nach wenig, aber diese Routine wird allein zur Punktberechnung bei der CobraMkIII 28 * 9 = 252 Mal aufgerufen, was 504 Takte einspart, was wiederum dem Löschen von 100 Adressen beim DoubleBuffering entspricht. Des weiteren läßt sich der Test auf 0 für den Matrixwert einsparen (ist selten null), sofern man die Logarithmentabelle korrigiert. Hier ist für log(0) gar kein Wert eingetragen. (Der dort befindliche Wert $a57a wird wahrscheinlich Müll sein, der noch auf die Berechnung der Tabelle zurückgeht.) Setzt man für log(0) dreist den Wert 0 ein, führt dies dazu, daß bei der Addition der Logarithmen das Carry wegen 0 nie gesetzt wird und als Ergebnis korrekt 0 herauskommt. (Ähnliches gilt auch für die Division.) Damit spart man dann weitere 28 * 9 * 2 Taktzyklen. Und das ist erst der Anfang. Der Programmcode enthält sehr viele Stellen, die man optimieren kann, die jede für sich genommen, nicht viel bringen, aber in der Summe dafür sorgen, daß das Programm das DoubleBuffering gut wegsteckt und länger "brauchbar" läuft, bis ihm halt notgedrungen irgendwann die Puste ausgeht.

Tja, und dann kann man natürlich die Berechnungen auch noch ganz anders vornehmen...

Doch, da geht noch einiges.

Quote from M. J.

Das ist leider auch aus dem Grunde nicht wirklich hilfreich, weil beim Einblenden einer REU-Bank (soviel ich weiß, habe selber keine REU) gleichzeitig auch IO und Kernal-Rom in den Adreßraum eingeblendet werden.

Redest Du hier von der REU oder von der Easyflash? Meine Bemerkung (die Du zitiert hast) bezog sich auf die Easyflash, nicht auf die REU.

Falls Du tatsächlich die REU meinst: Die funktioniert ganz anders. REU Bänke werden nicht eingeblendet. Stattdessen hat die REU einen DMA Chip, der Daten zwischen REU und normalem Speicher hin- und herschaufeln kann - das allerdings mit (für den C64) geradezu atemberaubender Geschwindigkeit. Die REU blendet auch nicht automatisch I/O ein, allerdings muss man zum Ansprechen den I/O Bereich einblenden. Ausführen von Code in der REU geht nicht.

Quote from M. J.

Ich würde eher sagen, daß der Witchspace mit bis zu 11 Objekten gleichzeitig die Ausnahme ist und nicht die Regel. Daß der c64 bei solch einem Extrem in die Knie geht, ist halt normal für einen 8 Bit-Rechner, und daran werden auch alle Optimierungen nichts ändern. Das wäre aber für mich kein Grund, den c64 aufzugeben oder auf Optimierungen zu verzichten und die Verwendung eines Beschleunigers zur Voraussetzung zu machen.

Ich habe wirklich viel Elite gespielt in meinem Leben und leider ist das nicht die Ausnahme. Das passiert Dir regelmäßig, z.B. wenn Du versuchst, eine Anarchie anzusteuern, und/oder wenn Dein Status nicht "clean" ist. Oder versuch mal, über die Sonne zu fliegen um Sprit zu "tanken" oder die Trumbels loszuwerden. Das "Original" stammt halt nun mal von einem Rechner, der doppelt so schnell war. Ich will ja auch nicht die C64 Version schlecht machen. Wenn ich aber das Spielerlebnis zwischen der originalen Version und der Version auf DTV oder SuperCPU vergleiche, dann machen letztere deutliche mehr Spass, ohne dass das 8-Bit Feeling verloren geht. Aber das muss selbstverständlich jeder selber entscheiden. Wäre ja blöd wenn wir alle dieselben Vorlieben hätten

Quote from M. J.

Ansonsten ist meiner Erfahrung nach gerade bei der Punktberechnung viel Luft für Verbesserungen. Ein kleines Beispiel:

DIe Routine für die Multiplikation mit Hilfe der Logarithmentabelle sieht so aus:

Ich hatte mal dieselbe Idee wie Du und habe eine Zeitlang selbstmodifizierenden Code in Elite verwendet. Das habe ich inzwischen von wenigen Ausnahmen abgesehen wieder rückgängig gemacht. Mein Code hatte damals regelmäßig Abstürze. Selbstverständlich nur sporadisch und nicht reproduzierbar. Ich habe tagelang diesen Fehler gesucht. Geholfen hat mir dann das Setzen von Breakpoints beim Schreiben auf readonly Segmente in Vice. Das Feature hat mich inzwischen schon mehrfach gerettet, läßt sich aber bei selbstmodifizierendem Code nur mit großen Schwierigkeiten verwenden.

Es wäre natürlich super, wenn Du tatsächlich größere Optimierungen hinbekommst. Meines Wissens gibt es bei keiner der im Netz verfügbaren, angepassten Versionen solche Optimierungen. Eine Beschleunigung auf etwa das doppelte (entspricht der CPU des BBC für den Elite zuerst erschienen ist) wäre klasse! Dann wäre das Spiel in vielen Situationen deutlich besser spielbar.

Gruß, Uz

Quote from kugelfuhr

Redest Du hier von der REU oder von der Easyflash?

Du hast natürlich recht. Ich meinte die Easyflash und nicht die REU. <- M. J.

Quote from kugelfuhr

leider ist das nicht die Ausnahme. Das passiert Dir regelmäßig

Meiner Erfahrung nach entstehen die größten Hänger im normalen Spiel durch die Explosionen, denn solange ein Raumschiff noch etwas weiter weg ist, wird beim Malen nur der eine Punkt berechnet, aber bei einer Explosion werden, wie Du weißt, alle Punkte berechnet und dazu noch die zufälligen Verschiebungen um die Punkte herum durch Multiplikation mit Zufallswerten... Daher würde ich raten, zuerst diese Routine zu ersetzen. Die Frage dabei ist halt immer: Wieviele Veränderungen sind machbar, bevor jemand sagt: "Das ist nicht mehr mein Elite.... "

Quote from kugelfuhr

Geholfen hat mir dann das Setzen von Breakpoints beim Schreiben auf readonly Segmente in Vice.

Breakpoints verwende ich gelegentlich auch, aber zielgerichtet auf einzelne Adressen und nicht ganze Bereiche. Aus diesem Grunde auf selbstmodifizierenden Code auf dem 6502 zu verzichten, halte ich nicht für ratsam, da man mit Selbstmodifikation an sehr vielen Stellen Code kürzen und schneller machen kann. (Auch ein Grund, warum ich die Easyflash nicht im laufenden Betrieb als Programm-ROM verwenden würde, sondern nur als schnellen Nachladespeicher.)

Quote from kugelfuhr

Es wäre natürlich super, wenn Du tatsächlich größere Optimierungen hinbekommst.

Wäre wäre Fahrrad... äh... oder so ähnlich... Schön wäre es, wenn irgendwer sowas hinbekäme, aber... Die meisten Optimierungen brauchen Speicherplatz. Viel Speicherplatz. Aber den habe ich nicht, den hast nur Du mit Deinen Komprimierungsverfahren für Musik- und Textdaten. Zwar ist es mir gelungen, an einigen Stellen ein paar Bytes herauszuholen, doch für echte Maßnahmen braucht man ein paar Kilobyte an zusammenhängenden Speicher.

Nebenbei: "Elite" verwendet ja zwei Bildschirmspeicher bei $6000 und $6400 für die Menüanzeige und die 3d-Sichtanzeige, obgleich beide in vielen Teilen absolut identisch sind. Diesen Witz habe ich nie richtig kapiert. Ich glaub, auch in Elite128 Version 1.0 machst Du von diesem gedoppelten Speicher keinen Gebrauch, oder?

Quote from M. J.

Meiner Erfahrung nach entstehen die größten Hänger im normalen Spiel durch die Explosionen, denn solange ein Raumschiff noch etwas weiter weg ist, wird beim Malen nur der eine Punkt berechnet, aber bei einer Explosion werden, wie Du weißt, alle Punkte berechnet und dazu noch die zufälligen Verschiebungen um die Punkte herum durch Multiplikation mit Zufallswerten...

Also da habe ich jetzt ehrlich gesagt weniger Probleme mit. Das sind ein paar Sekunden und dann ist die Explosion vorbei. Außerdem passiert das, wenn man einen Gegner erledigt hat, und dann bin ich sowieso froh, kurz verschnaufen zu können Problematischer sind die Situationen, wenn Du z.B. im Anflug auf eine Anarchie bist, evtl. sogar mit Rauschgift im Gepäck. Die Piratenmeute sammelt sich und Du kommst minutenlang zu keinem Abschuß, weil das Spiel so langsam wird, dass Du während eines einzigen Bildschirm-Updates den Joystick bereits mehrfach in die verschiedensten Richtungen gedrückt hast.

Quote from M. J.

Breakpoints verwende ich gelegentlich auch, aber zielgerichtet auf einzelne Adressen und nicht ganze Bereiche. Aus diesem Grunde auf selbstmodifizierenden Code auf dem 6502 zu verzichten, halte ich nicht für ratsam, da man mit Selbstmodifikation an sehr vielen Stellen Code kürzen und schneller machen kann.

Na dann wirst Du bestimmt vor Bewunderung erstarren, wenn Du hörst, was ich schon für tolle Fehler in Elite eingebaut habe

["Opa erzählt vom Krieg" Modus ein]

Der Fehler, aufgrund dessen ich ein Großteil des selbstmodifizierenden Codes wieder rausgeworfen habe, war eigentlich simpel:

Mir ist anscheinend irgendwann mal die Hand ausgerutscht und ich habe eine Zeile im Code gelöscht, die nicht hätte gelöscht werden sollen. Dummerweise war das ein RTS am Ende eines Unterprogramms. Das hatte zur Folge, dass bei Aufruf dieser Routine auch das darauf folgende Unterprogramm gleich mit ausgeführt wurde. Dieses Unterprogramm hat dann - weil nicht korrekt initialisiert - Speicher überschrieben. Und zwar nicht immer denselben, sondern immer mal woanders.

Das hatte erstmal keine Folgen. Solange bis der Code an der zufällig überschriebenen Speicherstelle ausgeführt werden sollte.

Die Folge war, dass das Programm völlig unreproduzierbar abgestürzt ist. Und zwar immer unterschiedlich, sowohl was die Stelle im Code, als auch was die einhergehenden Effekte angeht. Manchmal ist das nach 20-30 Sekunden passiert, manchmal konnte man minutenlang spielen, bevor der Crash kam.

Ich habe diesen Fehler tagelang gesucht und war froh, dass ich dann auf die Idee mit Vice und den Segmenten gekommen bin. Die Befehlsdatei für Vice wird seitdem bei jedem Build automatisch generiert und hat mir schon viele Male geholfen.

Jetzt kann es natürlich sein, dass Du

1. entweder ein Programmierlooser bist, der so komplizierte Fehler überhaupt nicht eingebaut bekommt, oder
2. ein Programmiergenie, das solche Fehler in Nullkommanix mittels überlegenem Intellekt findet.

Ich bin eher so vom Typ Otto Normalprogrammierer und deshalb auf solche technischen Hilfsmittel angewiesen

Im Prinzip bietet es sich sowieso an, den Quellcode in viele kleinere Teile zu zerlegen, die man leichter hin- und herschieben kann. Das ist schon wegen des in der Mitte liegenden Bildschirms bzw. dem teilweise Einblenden von I/O und Kernal notwendig. Und wenn Du das mal hast, dann geht der Rest mit ein paar Zeilen Perl Magie zum Einlesen eines vom Linker generierten Debug Files.

Heraus kommt dann sowas:

Das läßt sich mit "ll" in den Vice Monitor laden und schon hält Vice bei Schreibzugriffen das Programm an.

Quote from M. J.

Schön wäre es, wenn irgendwer sowas hinbekäme, aber... Die meisten Optimierungen brauchen Speicherplatz. Viel Speicherplatz. Aber den habe ich nicht, den hast nur Du mit Deinen Komprimierungsverfahren für Musik- und Textdaten.

Das hört sich ein bisschen so an, als ob ich auf einem Haufen streng geheimer Raketenwissenschaft sitzen würde:) Tatsächlich ist es aber nur Arbeit. Ich habe auch kein Problem damit, Code für solche Sachen weiterzugeben. Mir ging's nur darum, dass ich wegen der unklaren Rechtslage nicht den kompletten Elite-Quellcode rausrücke. Ich suche mal die Kompressionsroutinen raus und hänge sie an den nächsten Post an, vielleicht kann jemand was damit anfangen.

Inzwischen liegen diese Daten bei mir übrigens unkomprimiert im erweiterten RAM der REU/DTV/SCPU. Das spart noch mehr Platz.

Gruß, Uz

Anbei die Kompressions -und Dekompressionsroutinen. Letztere enthält übrigens noch selbstmodifiziernden Code. Beide Dateien mit .txt Endung, weil .cc oder .s offenbar zu gefährlich zum Hochladen sind

Gruß, Uz

consoledata.txt  compcons.txt

Quote from Elwyndas

Habt ihr dieses Projekt schon gesehen?

Ja, schon gesehen. Das wurde bereits in dem anderen Thread zu Elite erwähnt. Leider ist das Projekt noch nicht weit vorangeschritten. Im Grunde genommen handelt es sich eher um ein Projekt noch in der Planungsphase, d. h. der Autor sondiert zunächst Möglichkeiten für Veränderungen. Die Beschreibung "Elite : Harmless is a greatly enhanced version" ist da etwas irreführend und sollte vielleicht lauten: "Elite : Harmless will be a greatly enhanced version". Codebasis ist die erste Veröffentlichung von "Elite" mit doppelter log-inv-Tabelle und ohne Titelmusik. Gerade weil letzteres fehlt, war es noch relativ einfach, ausreichend Platz zu finden für neue Tabellen. Das ist bei den späteren Versionen (z. B. "Elite deutsch") wesentlich schwerer. Wie ich schon in dem anderen Thread schrieb, ist die Aussage "The code was unnecessarily storing and copying the blank space either side of the HUD [..] on every frame" nicht korrekt. Die Platzverschwendung mit dem linken und rechten Rand stimmt zwar, aber die Anzeige wird nicht jeden Frame kopiert, sondern nur bei einem Wechsel der (Menü)Anzeige. Man kann mal ruhig ein Auge auf das Projekt werfen, doch wie es zur Zeit aussieht, hat sich da auch seit ein paar Monaten nichts mehr getan.

Quote from kugelfuhr

Anbei die Kompressions -und Dekompressionsroutinen.

Vielen Dank! RLE mit 4 Bits? Okay, dann schau ich mal ob ich das unterbieten kann. Weißt Du noch ungefähr, wieviele Bytes die Bitmap komprimiert braucht?

Quote from kugelfuhr

Das sind ein paar Sekunden und dann ist die Explosion vorbei.

Liegt vielleicht daran, daß ich die Gegner nach Möglichkeit noch alle erledige, wenn sie nur als Punkt dargestellt werden. Da sind die Explosionen schon hinderlich. Okay, ich gebe zu, ich bin jetzt auch nicht der Typ, der mit einer mit illegalen Gütern vollbeladenen Cobra in ein Anarchie-System fliegt. Da wird der Schwellwert zur Erzeugung neuer Gegner auch so weit runtergesetzt, daß ein Loser wie ich mit den Abschüssen nicht mehr hinterherkommt.

Quote from kugelfuhr

Jetzt kann es natürlich sein, dass Du
1. entweder ein Programmierlooser bist, der so komplizierte Fehler überhaupt nicht eingebaut bekommt, oder
2. ein Programmiergenie, das solche Fehler in Nullkommanix mittels überlegenem Intellekt findet.

2.! 2.! 2.! 2.!

Nee, bin auch eher ein harmloser Programmierer, und einen Fall wie Deinen hatte ich in ähnlicher Form ebenfalls schon erlebt. Bei mir war es die Routine zum Punktmalen. Die hatte ich verbessert. Glaubte ich jedenfalls. Aber dabei hatte ich nicht bedacht, daß eine andere Routine den Zeropage-Zeiger auf die Bildschirmadresse weiterverwenden würde. Da dieser aber einen anderen Wert enthielt (, weil ich das Indexregister Y anders verwendete), führte dies dazu, daß wild im Code ein Byte geschrieben wurde. Blöderweise ausgerechnet in die Routine zum Abspielen der Musik. Das Spiel konnte also eine Weile normal laufen, aber wenn man dann den Docking Computer einschaltete, passierte es nach einiger Zeit (, wenn bestimmte Musikdaten gesetzt wurden), daß das Spiel gnadenlos sichtbar crashte. Tja, hat mich auch eine Weile gekostet, diesen Fehler zu finden...

Ich würde mal sagen, Du hast da einfach Pech gehabt mit dem RTS, und ich war zu unvorsichtig und habe nicht richtig aufgepaßt. Doch deswegen würde ich nicht auf Selbstmodifikation verzichten wollen, denn der 6502 ist nun einmal so gebaut, daß der Code dadurch wesentlich an Geschwindigkeit zulegen kann.

Quote from kugelfuhr

Das ist schon wegen des in der Mitte liegenden Bildschirms bzw. dem teilweise Einblenden von I/O und Kernal notwendig.

Hmm... Wie wäre es eigentlich, wenn man den Bildschirm in die Bank 0 ($c000 .. $ffff) verlegen würde? Das sollte doch möglich sein, oder?

Was IO/Kernal anbelangt, so sind diese zumeist abgeschaltet. Der Programmcode schaltet im Spiel nur zum Lesen von Tastatur und Joystick um auf Ram/IO/Ram, und beim Laden auf Ram/IO/Rom, wobei jedoch vorher der IRQ vollständig deaktiviert wird. Ich glaube, in der Version 1.0 verwendest Du noch die Originalmethode von Elite, den Wert von $1 in einer gesonderten Variabel zu speichern. Das hatte ich bei einer Probeversion entfernt und die IRQ-Routine aufgeteilt auf drei separate Routinen: 1.) IRQ-Oben, 2.) IRQ-Unten (Trennung von 3d-SIcht und Radaranzeige, 3.) Nur beim C128 bzw. TC64: Setzen von $d030 zur Beschleunigung. Eigentlich müßte man die Tastaturroutine so abändern, daß sie im Interrupt läuft und bei Tastendruck 8 Werte in die Zeropage speichert (für die 8 Tastenreihen), Im Originalprogramm wird ja für jede Taste ein Byte gelöscht bzw. gesetzt, was ziemlichen Overhead bedeutet. Gleichzeitig könnte man dann für "normale" Tastendrücke (also solche, die nicht parallel zu anderen, sondern nur einmal ausgelöst werden wie z. B. <F1> oder Eingabe von Dateinamen) wie gehabt im Interrupt einen Tastenwert ermitteln und in einer Variablen hinterlegen. Dann hakt es dort nicht mehr so sehr. Aber auch wenn man die Tastatur- und Joystickabfrage so beläßt wie vorher, kann man sich die SEI/CLI-Befehle im Code sparen:

Quote from kugelfuhr

Inzwischen liegen diese Daten bei mir übrigens unkomprimiert im erweiterten RAM der REU/DTV/SCPU.

Wie ist das eigentlich bei der REU? Ist nicht während der Datenübertragung der IRQ quasi abgeschaltet, weil der Prozessor lahmgelegt wird?

Quote from kugelfuhr

Im Prinzip bietet es sich sowieso an, den Quellcode in viele kleinere Teile zu zerlegen

Hmm... tja... Für die Programmierung verwende ich meinen eigenen Assembler, der bei Bedarf auch mehrere Programmsegmente in einem Rutsch ausspuckt, so daß ich auf einen Linker usw. nicht angewiesen bin. Auch die Erzeugung von beliebigen Texten nebenbei zum Assemblercode ist damit ohne weiteres möglich. Persönlich bevorzuge ich es, einen Programmtext vollständig vor mir zu haben und nicht zerstückelt in mehrere Teile. Da ist das Verschieben von Routinen auch nur noch ein Cut&Paste.

Apropos mehrere Segmente: Das Nachladen von Programmteilen dürfte sicher die beste Methode sein, Platz im Speicher zu schaffen. Eine reine Kassettenversion wird heutzutage kaum noch jemand spielen wollen. Welche Programmsegmente wären Deiner Meinung nach am besten geeignet für eine Auslagerung? Bei den Strings hast Du (soviel ich weiß) schon in Version 1.0 die Missionsstrings auf Diskette verbannt. Aber welche Programmteile lassen sich leicht vom Rest lösen, ohne daß der Spielfluß darunter leidet?

Quote from Elwyndas

Habt ihr dieses Projekt schon gesehen?

Kroc hat mich im Mai mal kontaktiert wegen Quellen. Das Projekt kannte ich aber noch nicht, vielen Dank für den Link! Offensichtlich sind andere Leute mutiger als ich.

Quote from M. J.

Nebenbei: "Elite" verwendet ja zwei Bildschirmspeicher bei $6000 und $6400 für die Menüanzeige und die 3d-Sichtanzeige, obgleich beide in vielen Teilen absolut identisch sind. Diesen Witz habe ich nie richtig kapiert. Ich glaub, auch in Elite128 Version 1.0 machst Du von diesem gedoppelten Speicher keinen Gebrauch, oder?

Das hier hatte ich übersehen. Ich habe nur noch eine dunkle Erinnerung daran: Ja, es gab die beiden Kopien und es gab glaube ich auch einen Grund, allerdings keinen wichtigen. Ich verwende das schon lange nicht mehr.

Quote from M. J.

Vielen Dank! RLE mit 4 Bits? Okay, dann schau ich mal ob ich das unterbieten kann. Weißt Du noch ungefähr, wieviele Bytes die Bitmap komprimiert braucht?

Unterbieten geht bestimmt. Aber das Kosten/Nutzen Verhältnis dieser Version ist ziemlich unschlagbar. Unkomprimiert sind es 2240 Bytes, komprimiert 1101. Wenn Du den Dekompressor reinrechnst, dann kommt netto gut 1KB Gewinn raus.

Quote from M. J.

Hmm... Wie wäre es eigentlich, wenn man den Bildschirm in die Bank 0 ($c000 .. $ffff) verlegen würde? Das sollte doch möglich sein, oder?

Das habe ich mir nicht genauer angeschaut. Ich komme mit der derzeitigen Aufteilung eigentlich ganz gut klar:

Zwischendrin sitzt bei $4000/$6000 der Bildschirm. Von der zweiten Seite braucht man nicht alles, weil der untere Teil immer aus Bildschirmseite 1 kommt, d.h. Bildschirm geht bis $7680, wo dann HICODE anfängt. Die einzelnen Teile stehen in separaten Dateien, die vom Loader in der richtigen Reihenfolge geladen werden. Der letzte Teil (LOCODE) müsste dorthin, wo auch der Loader liegt, deshalb wird ein kleiner Codeschnipsel in den Kassenpuffer geladen, der zum Schuss LOCODE dorthin lädt wo vorher der Loader war und der danach Interrupts aktiviert und Elite startet. Dadurch, dass das Laden von einem separaten Programm gemacht wird, läßt sich im Prinzip der komplette Speicher verwenden. Selbst der Kassettenpuffer wird nach dem Start von Elite für Variablen "recycled" (CASSBUF1). Der Loader ist übrigens das, was hinterher "elite128" auf der Disk heisst - obwohl es eigentlich gar nicht das Spiel selber ist.

Quote from M. J.

Das hatte ich bei einer Probeversion entfernt und die IRQ-Routine aufgeteilt auf drei separate Routinen:

Über sowas denke ich derzeit auch nach. Ich habe die letzten Tage wieder SCPU Support hinzugefügt. Und das kompliziert die Sache nochmals, weil der 65816 dabei im Native Mode läuft und deshalb separaten Code für Interrupt Entry/Exit braucht. Wenn ich wieder C128 Support hinzufügen würde, dann käme noch der dritte Interrupt des C128 dazu.

Weil ich aber sowieso schon so eine Art "Treiber" für jede spezielle Hardware habe (DTV/REU/SCPU in der Speicherkonfiguration oben), wäre es das beste, den Interrupt-Code auch dort reinzustecken. Diese Treiber werden vom Loader bereits in Abhängigkeit von der jeweiligen Hardware geladen, d.h. ich müsste an anderer Stelle keine weiteren Unterscheidungen machen. Ich weiss bloss gerade noch nicht, welche Probleme das macht, weil die Treiber bei $F900 liegen und (derzeit) nur $180 Bytes groß sein können. Der für das DTV ist schon ziemlich eng an dieser Grenze.

Quote from M. J.

Wie ist das eigentlich bei der REU? Ist nicht während der Datenübertragung der IRQ quasi abgeschaltet, weil der Prozessor lahmgelegt wird?

Das stimmt, ist aber in der Praxis kein Problem. Zum einen wird nur das Innere des Fensters gelöscht. Das sind Brocken von 256 Bytes, d.h. die CPU wird jeweils für 256 Zyklen angehalten und kann dazwischen "Atmen". Zum anderen beginnt das Löschen nach Umschalten auf den unteren Teil bei Rasterzeile $C2. Ab da ist genug Zeit für das Löschen bis der nächste IRQ kommt. Wenn der C128 wieder dazu käme, dann würde der Interrupt nach der letzten sichtbaren Zeile tatsächlich etwas verzögert, weil das Löschen noch im Gange ist, aber auch das wäre vermutlich kein Problem, die Umschaltung auf 2MHz findet dann eben etwas später statt.

Beim DTV gibt es komischerweise mehr Probleme mit Flackern, da muss ich bei Gelegenheit nochmal nach schauen.

Quote from M. J.

Welche Programmsegmente wären Deiner Meinung nach am besten geeignet für eine Auslagerung?

Das kommt drauf an, ob Du auf Disk oder in erweiterten Speicher auslagerst. Zugriff auf Diskette ist so lahm, dass man das definitiv merkt, da hast Du nicht viele Möglichkeiten. Missionstexte, ja. Aber bereits bei der Musik wird's schwierig. Hier ist der Teil der Speicherkonfiguration, der bei mir festlegt, was nach "EXTDATA" geht (siehe Teil oben - das wird in den erweiterten Speicher geladen):

Übersetzt:

• Ein paar Hilfsdaten zum Löschen
• Die komplette Musik
• Grafik- und Farbdaten der Console
• Alle Raumschiffdaten für die Enzyklopädie
• Alle Texte für die Missions
• Zwei Kopien der Zeropage, eine für Elite, eine für das Kernal (muss bei Load/Save geswapt werden)
• Eine Kopie des Commanders, damit bei Tod nicht geladen werden muss
• Der Default Commander Jameson

Ein Problem, auf das Du wohl auch schon gestossen bist ist, dass es viele gute Ideen gibt, und wenn man sich mal entschieden hat, eine auszuprobieren, dann kommen einem in der Zeit wo man sie umsetzt mindestens 5 neue. Ich habe die letzten Tage den alten Code etwas aufgefrischt, SCPU Support hinzugefügt und Teile des Loaders in den Treiber verlagert. Inzwischen habe ich aber schon wieder neue Ideen: C128 Support, GeoRAM, Interrupt Handler im Treiber, ... Wenn das so weitergeht, dann programmiere ich nächstes Jahr noch ohne einem Release näher zu sein

Aber nochmal zum Thema EasyFlash: Ich habe mir die Specs angeschaut und denke, da ist nichts dabei, was für Elite wirklich hilfreich ist. Weder Beschleunigung noch Auslagern von Daten geht damit sinnvoll. Wenn ich Dich richtig verstanden habe, siehst Du das genauso? Vielleicht sollte man das mal als Ergebnis festhalten, immerhin ist hier das "EasyFlash Subforum". Ein Image auf die Cartridge zu packen geht natürlich, aber da könnte man auch ein Disk-Image auf ein SDIEC legen.

Wie steht's eigentlich mit anderer Hardware für Beschleunigung / Speichererweiterung? Weiss jemand, wie verbreitet andere 65816 Karten sind (TurboProcess oder so)? Oder GeoRAM / weitere Speichererweiterungen? Ich bin ein bisschen draussen, was Erweiterungen angeht, da hat sich in den letzten 10 Jahren anscheinend extrem viel getan.

Quote from M.J.

Hmm... tja... Für die Programmierung verwende ich meinen eigenen Assembler, ...

Ja, wer tut das nicht? Alles andere wäre schlechter Stil

Gruß, Uz

M. J. bei deiner letzten Version (.d64) fehlte ja nur das Fadenkreuz zu meinem Glück, ansonste war die Version ja tiptop. Kannst du das evtl. noch fixen, damit wir wenigsten schonmal eine .D64 Version haben ?