Ich würde sagen, er benutzt als Hintergrundfarbe Schwarz, dann die beiden Zusatzfarben Braun und Grau. Die Hintergrundfarbe ($d800) ist dann einmal Weiß oder Grün oder Blau.
Posts by M. J.
-
-
Du musst dir eine Stelle aussuchen die sich von den anderen Stellen unterscheidet. z.B. durch die eine Klippe
Hmm... Ich dachte, ich hätte es von dort schon mal probiert.
Kann es aber gerne noch einmal versuchen. Danke für den Tip! -
Hast du schon versucht zu tauchen?
Ja, mit letalem Erfolg.
-
Wer von euch ist denn noch am spielen?
Hänge schon seit längerer Zeit fest und komme nicht weiter. Anscheinend gibt es in der Tiefe etwas, doch beim Versuch es anzuschauen oder zu holen, werde ich stets umgebracht.
Habe zwar die Wüste durchquert und mir die Landschaft dahinter angesehen ("Karte" erstellt), aber finde keinen Weg, wie ich diverse dortige Hindernisse überwinden kann. Irgendwas übersehe ich total... 
-
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 ?
Öhm... leider nicht. Das liegt daran, daß ich zunächst wieder eine saubere disassemblierte Version erstellen muß, da die jetzige Version zu viele experimentelle Patches enthält, die allesamt rückgängig gemacht werden müssen. Die saubere Version muß dann erneut mit dem Flickerpatch und anderen (harmlosen) Veränderungen neu gepatcht werden. Da ich zur Zeit meine Freizeit in ein anderes Projekt investiere, bin ich aber dazu bisher nicht gekommen. Nur als Vorschlag: Wie wäre es, in der Zwischenzeit Uz beim Testen der neuen Elite 128 Version zu unterstützen? Und wer weiß, vielleicht gefällt seine Elite-Erweiterung so gut, daß eine andere gar nicht mehr benötigt wird...
Nebenbei: Für den Forum64-Adventskalender hatte ich ein kleines 3d-Programm geschrieben, welches ein Christmas-Egg enthält: Drückt man den Feuerknopf von Joystick 2, werden anstelle der Weihnachtsobjekte ein paar Raumschiffe aus "Elite" angezeigt. Hierbei wird dann auch flimmerfreies DoubleBuffering verwendet. Zwar ist das Programm aufgrund der Eile, in der es geschrieben wurde, ein wenig zusammengehauen, d. h. nicht optimal, aber man kann ungefähr abschätzen, wie schnell DoubleBuffering auf einem normalen C64 umgesetzt werden kann mit einer Einschränkung: Auch wenn es so aussieht, enthält das Programm keine Routinen aus "Elite". Erkennbar ist dies daran, daß zum einen die Berechnungen genauer sind als auch die Objekte sich in verschiedenen Rotationsstärken um 3 Achsen drehen.
Theoretisch könnte man also andere Verfahren zur Berechnung in "Elite" einsetzen, die im Vergleich entweder schneller oder genauer oder sogar beides sind, doch es gibt leider zwei sehr große Haken:
1.) Die Rotationsmatrix in "Elite" verwendet einen krummen Wert von $6000 zur Darstellung des Wertes 1.0. DIe Umrechnung in eine andere Matrix ist aufwendig. ("Elite" selbst dividiert fürs Malen die Matrixwerte vorab durch $60.)
2.) Der Algorithmus für den Docking Computer, aber auch gleichzeitig zum Anvisieren von fremden Schiffen im Kampf (z. B. bei der Steuerung der Raketen) beruht nicht nur auf diesen krummen Werten, sondern auch darauf, daß der eigentliche Wertebereich von -$6000 bis $6000 (entsprechend -1.0 bis 1.0) aufgrund von Ungenauigkeiten in den Berechnungen überschritten wird. Ersetzt man nämlich die ungenauen Berechnungen mit genaueren (z. B. durch Verwendung von Quadratzahlentabellen bei der Multiplikation), so kann dies dazu führen, daß der Docking Computer nicht mehr funktioniert, weil nun der Wertebereich korrekt eingehalten wird.
Diese beiden Punkte machen es so unheimlich schwierig, "Elite" zu patchen. Wenn dem nicht so wäre, hätte ich schon vor Jahren eine rundum überarbeitete Version fertig.
EDIT TRW: Angesprochene Datei aus dem Adventskalender anghängt!
-
Lode Runner (gescriptet)
Bandits
Uridium
Flugsimulator II
Chuck Yeager's AFT
Pool of Radiance und verwandte SSI-Spiele (Zeigen Bilder und einen nicht gescripteten Kampf)
eine Art von Demo (eher Bildershow) eines Adventures: The Serpent's Star
-
Vielen Dank, daß Du das Programm um so viel weiter ausgebaut hast und uns das Ergebnis zur Verfügung stellst.
Hab es runtergeladen und werde es in nächster Zeit gründlich durchtesten (, wenn auch nur mittels WinVice). -
(Gerade erst gesehen)
Genial! Super!
Vielen Dank an Beckett und auch an Dich fürs Hochladen! -
Ja, diese auswärtigen Ereignisse haben sich schon ereignet
wenn wir da von "Licht" im weitesten Sinne sprechen, aber ich steck jetzt trotzdem fest.Hmm.... Um feststellen zu können, was Ereignisse bewirken, wäre es gut, wenn man diese auch überlebt... Manchmal hilft da Schiller weiter: "Alles rennet, rettet, flüchtet..."
-
Irgendwie hänge ich jetzt aber fest. Draußen geht es ja nicht weiter. Das Bild vom Großvater habe ich auch untersucht, da war dann weiter nichts zu erforschen.
Derzeit steh ich gerade etwas auf dem Schlauch.
Auch wenn man selbst draußen nicht viel machen kann, können sich - wie in der Politik - auswärtige Ereignisse trotzdem auf das Innere auswirken. Die Frage ist halt, inwieweit man solche Ereignisse steuern kann, und wenn ja, von wo aus, d. h. wie hoch ist die Wahrscheinlichkeit, daß es von innen gelingt...?
-
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.
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?
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.
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.
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:
Display MoreCode
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?
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?
-
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.
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....
"
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.)
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?
-
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.
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.
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:
Display MoreCodeHierbei 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.
-
Goodie am Rande: Da ist eine Schiffs-Enzyklopädie drin.
Das sieht gut aus. Interessant, wie weit Deine Entwicklung vorangeschritten ist.
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.
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.
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?
-
die Version 1.0, die es im Netz gibt
Öhm... Wo kann ich die finden? Habe mal hier auf csdb geschaut. Dort ist als Version 1.0 im Dateinamen und Begleittext angegeben, jedoch enthält diese kein DoubleBuffering.
nur der obere Teil des Bildschirms umgeschaltet wird
[..]
Die Console im unteren Bereich ist nicht double buffered
Okay,entspricht also auch meinen Versuchen.
-
Uz hier
Ich kann mal ein paar Sachen zu Elite 128 schreiben.
Hallo Uz!
Zunächst mal "Herzlich WIllkommen im Forum!"
Und "Vielen Dank!" für Deine Rückmeldung und das Angebot, Fragen zu beantworten. Diesbezüglich hätte ich allerdings einige..
Sag also bitte bescheid, wenn es zu viel wird.Für den Anfang:
Einen Flickerfix via DoubleBuffering hatte ich mir auch schon überlegt. Das scheiterte aber daran, daß je nach Organisation dazu bis zu ca. 8 kb Speicher notwendig sind für die zweite Bitmap. Bezieht sich Deine Umsetzung daher nur auf eine mögliche REU-/SCPU-Version oder auch auf einen "normalen" C64?
Desweiteren würde mich interessieren, wie Du dabei das Radar handhaben würdest. Bei einem vollständigen DoubleBuffering müßte man ja auch dieses verdoppeln, was aber zu Problemen führt beim Löschen und Neumalen. Ein fortwährendes komplettes Neuzeichnen des Radarhintergrunds würde ich für zu aufwendig halten. Mein Gedanke war daher, das Double-Buffering auf den oberen Anzeigebereich zu beschränken und das Radar weiterhin mit einer Bitmap zu realisieren, auch wenn dies den unhübschen Effekt hat, daß es weiterhin flimmert und aufgrund der EOR-Verknüpfung farbverfälscht ist.
Ein weiterer Punkt, der mir beim DoubleBuffering stets schwer im Magen liegt, ist das andauernde Neuzeichnen von "Front", "Rear" ... oder auch (noch schlimmer) Meldungen wie "Docking Computer On", da dies sehr viele Takte verbrät. Hattest Du dafür eine Idee?
-
Dazu steht etwas unter VICE bug #1083:
Vielen Dank!
-
Was genau wurde denn gefixt, sprich: Was ist die Ursache für das unterschiedliche Verhalten?
-
Er hat es geschafft das flickering zu entfernen - eine erstaunliche Leistung!
Das war nicht ich, sondern vermutlich Ian Bell, der dies in der AppleII-Version, die nach der C64-Version veröffentlicht wurde, eingebaut hat. Ich habe es nur in die C64-Version rüberkopiert.
Das Titelbild stammt offenbar von der Tapeversion, als Ladebild. Ich habe es angefuegt. Es kann sein dass es ein besseres scrape gibt.
1.) Hast Du dafür vielleicht einen Link auf die Bitmap-Daten. Das PNG müßte man ja erst wieder in Bits und Bytes für den C64 umwandeln.
2.) Wann soll das Bild erscheinen? Es dürfte kein großes Problem sein, das Bild zusammen mit dem Spiel zu laden und zu Beginn des Spiels anzeigen zu lassen, bis eine Taste gedrückt wird. Wäre das ausreichend?
- SCPU ich kenne mich nicht aus aber damit kann man sicher die Kämpfe mit mehreren Gegnern glätten
Zwar besteht die Möglichkeit, alle bekannten Beschleuniger (c128, dtv, tc64, SCPU) zu unterstützen, indem man einen zusätzlichen Interrupt einbaut. Schwierig wird es aber, das Spiel auf eine sinnvolle Bildrate zu begrenzen, denn bei aktivierter SCPU oder im 50Mhz tc64-Modus wird es sonst einfach zu schnell.
docking Computer auch in englischer Version verfügbar
Tut mir leid. Das habe ich nicht verstanden. Der Docking Computer ist in allen Versionen vorhanden. Was genau meinst Du?
save file Editor
Ob das so sinnvoll ist...
Nebenbei: Wenn ich mich recht erinnere, gibt es zwei verschiedene Spielstandspeicher-Versionen (Englisch ohne Titelmusik, Englisch und Deutsch mit Titelmusik). Ohnehin wäre dies ein Extraprogramm.
alle bekannten cheats für beide Sprachversionen
Die Cheats sind im Prinzip bei jeder Version gleich, da sich der Code nicht geändert hat. Unterschiede gibt es in der Position des Cheatcodes im Ram, die entstehen aufgrund der Änderung in der Größe der Stringdaten sowie der Reduzierung der Logarithmentabellen auf ein loginv anstelle von zwei.
Dann gibt es noch den Mann hinter Elite 128, Ullrich von Bassewitz.
Tja, es wäre nett, wenn er uns den Sourcecode überlassen könnte, aber anscheinend ist er schon lange nicht mehr in der Szene aktiv.
allerdings bin ich (persoenlich) nicht mit allem zufrieden.
Was genau gefällt Dir daran nicht?
BUG FIX: Joystick Steuerung verträgt sich nicht mit keyboard Input. Es kann nur einen geben. Das ist gerade bei diesem Spiel eine Katastrophe
Prinzipiell ist das machbar. Aber viel schlimmer ist, daß bei der Abfrage von Joystick und Tastatur stets der Interrupt ausgeschaltet wird. Falls sich jemand mal gewundert hat, wieso es öfters zu einem Flackern beim unteren Rasterinterrupt kommt... Das ist der Grund.
Leider gibt es bei dem Programm jede Menge Sachen, die man abändern kann. Für meine Experimente hatte ich zuletzt den Code der deutschen Elite-Version disassembliert und in einen assemblierbaren Sourcecode umgewandelt. Damit ist der Code relokatibel, und man kann verschiedene Anpassungen vornehmen, ohne wild Patches im Speicher verteilen zu müssen. Dennoch ist ein freies Umprogrammieren nicht so einfach, da die Speicheraufteilung das Programm in zwei Hälften trennt. (Die Anzeigebitmap liegt mitten drin bei $4000...) Zwei Bugs hatte ich mal probeweise korrigiert: 1.) Der Carrybug beim Rotieren der Objekte. 2.) Nach dem Laden eines Spielstands springt das Programm merkwürdigerweise hinter den JSR zum Einschalten der Titelmusik. Eigentlich müßte an dieser Stelle die Musik wieder eingeschaltet werden. Des weiteren findet sich In der Soundroutine ein nettes Feature, von dem ich nicht weiß, ob es vielleicht einen Bug darstellt.
Kurz gesagt: Man kann an dem Programm sehr viel ändern, das ist ein nahezu ein Faß ohne Boden, wird aber immer mit dem arg begrenzten Speicher zu kämpfen haben. Was das Alles jedoch mit einer 1581 zu tun hat...?
-
Wo bist du denn M. J. ?
Wo ich bin, hatte ich oben beschrieben. Solltest Du nichts darin erkannt haben, bin ich weiter.
