letzter Beitrag von tilobyte am
Gibt es den Sourcecode von Elite irgendwo als Download (idealerweise von der C64-Version, aber gerne auch andere Fassungen) oder stehen da immer noch rechtliche Hürden im Weg?
Zum Bleistift hier und hier:
http://www.elitehomepage.org/archive/
https://github.com/kieranhj/elite-beebasm
Carmack...? Carmack...? Verdoomt, keine Ahnung, wer das sein soll.
Ist das nicht der Typ, der Commander Keen erfunden hat?
Gibt es den Sourcecode von Elite irgendwo als Download (idealerweise von der C64-Version, aber gerne auch andere Fassungen) oder stehen da immer noch rechtliche Hürden im Weg?
Zum Bleistift hier und hier:
Super! Vielen herzlichen Dank! 
Gibt es den Sourcecode von Elite irgendwo als Download (idealerweise von der C64-Version, aber gerne auch andere Fassungen) oder stehen da immer noch rechtliche Hürden im Weg?
Zum Bleistift hier und hier:
Ich hab's glaub ich hier schon erwähnt, das Github-Repo von Kroc, wobei M.J. die Qualität nicht sonderlich überragend findet (was die Durchdringung bei den Erklärungen der Routinen, speziell der mathematischen angeht - mangels Vergleich kann ich das nicht beurteilen). Dennoch eine nette Stöbervariante, allerdings aber eben "nur" ein Disassembly im neuen Gewand, nicht etwa der Original-Sourcecode ...
Zum CPC kann ich sagen das die Kassettenversion nicht nachläd und auch kein Flimmern hat.
Interessant. Die kenne ich gar nicht. Ist sie denn vom Umfang her identisch mit der Diskettenversion oder wurden einige Elemente (z. B. Raumschiffe oder Missionen) weggelassen?
Das kann ich heute niocht mehr beurteilen - so hatte ich keine 'Trumbles' Mission damals - aber mindestens zwei andere. (zumindest ist so meine Erinnerung - war ja noch klein 
... irgendwie war mir abwer nach etwas mit der Constrictor ....
Schon kommt die Frage auf: gibt es eine Liste dwer Missionen pro Version?
so hatte ich keine 'Trumbles' Mission damals - aber mindestens zwei andere.
Soweit ich mich erinnere gab es doch nur drei Missionen, oder? Ich hatte nur die Trumbles. Ich weiss garnicht mehr, wie ich das Problem mit den süssen, flauschigen Trumbels lösen konnte. Internet gabs noch nicht, aber irgendwoher wusste ich was zu tun ist.
Im Zweifelsfall gamefaqs.com und dergleichen. Dedizierte Elite-Webseiten gibt es ja auch nicht direkt wenige.
Wenn Du Dir das wirklich antun willst, würde ich Dir empfehlen, die Version von c64games zu nehmen
Thx - werde dann die nehmen...
Erstmal ein herzliches danke an M. J. das er sich so viel zeit nimmt und hier echt jede kleine Frage so ausführlich beantwortet.
*unterschreib*
Einer Elite Version geht leider oft etwas unter, obwohl sie in sachen 3D Darstellung absolut genial ist, aber leider an einer fast unbrauchbaren Steuerung leidet, und zwar die NES version.
Habs immer wirder mal Versucht, aber die Pad Steuerung ist einfach total überfrachtet und nicht gut durchdacht.
Auch die komische Musik ist extrem Nervig, aber als SID gewohnter Typ, konnte ich mit dem Chip gedudel des NES noch nie viel anfangen.
Ja - hatte die Version sieht cool aus. Aber wie das oft so mit dem Aussehen ist - wenn die inneren Werte nicht ebenfalls stimmen (Stichwort Steuerung), bringts da auch nicht sooo Ist ja nicht
nur zum Anschauen gedacht *g* Wobei - vielleicht kommen ja die typischen Nintendo Daddelkids (dann u.U. auch schon keine Kids mehr btw *g*) damit klar. Für mich ist auch ansonsten das Nintendo Pad nicht so mein Ding...
Ok und das man den Docking Computer von Anfang an hat, ist auch irgendwie Spaß hemmend.
Uuuups.
Der ändert ja nichts daran, dass während der Datenübertragung CPU in C64 und der 1541 blockiert sind. Wenn ich mich nicht irre, dauert ein 512-Byte-Transfer mit den schnellsten Routinen auf zwei Leitungen gut 10ms, und es geht ja nicht nur um den reinen Transfer, sondern auch das Handshake drumherum; wenn z.B. der C64 ewig warten muss, bis die Floppy mit ihren Rechnungen fertig ist und der Transfer beginnen kann, ist das alles Makulatur.
Höchstwahrscheinlich nicht. Gründe, die dagegen sprächen, wären
- Die Datenübertragung zwischen Laufwerk und C64 ist sehr langsam. In der Zeit kann der C64 vieles selber rechnen.
- Der Speicher der 1541 reicht nicht aus. Zwar wäre u. U. die Datenmenge an sich nicht so groß, aber der Programmcode beträgt mehrere Kilobytes, über die die 1541 nicht verfügt.
Ja, so etwa 40 Takte, eher mehr je Byte dürften Grenze bei der Übertragung sein. Aber für den Preis bekommt man keine 2 16Bit-Additionen, geschweige denn kompliziertere Berechnungen hin.
Gefülltes Rechteck von 30*20 Pixel wird in dieser Umgebung kaum unter 1000 zu machen sein und 9 Bytes Zeichendaten brauchen.
Wenn die Berechnung länger als die Übertragung braucht, dann wird man im Parallel-Betrieb Zeit sparen.
Mir fehlt ein Gefühl, in welchen Verhältnis die Rechenzeit zur Zeichenzeit in typischen Szenen steht.
2 KB sind knapp, aber vielleicht dürfen die Rechenroutinen ja langsam sein, weil sie immer noch schneller als das Zeichnen wären?
Ja, so etwa 40 Takte, eher mehr je Byte dürften Grenze bei der Übertragung sein. Aber für den Preis bekommt man keine 2 16Bit-Additionen, geschweige denn kompliziertere Berechnungen hin.
Es gibt Leute, die packen in 40 Takte eine Multiplikation.
Mir fehlt ein Gefühl, in welchen Verhältnis die Rechenzeit zur Zeichenzeit in typischen Szenen steht.
Gute Frage. Hängt wohl vom konkreten Einsatzgebiet ab. Bei einem Flugsimulator gäbe es zunächst nur den Flug des eigenen Flugzeugs zu berechnen, und selbst wenn diese Berechnung physikalisch sehr exakt ist, wäre es kein Vergleich zum Zeichnen aller stationären Objekte (Horizont, Fluß, Straßen...) Bei einem Spiel wie "Elite" kann sich dieses Verhältnis aber radikal umkehren, da hier mehrere Objekte gesteuert werden müssen, und das auch, wenn sie gerade nicht sichtbar sind (außerhalb des Anzeigebereichs liegen).
Die Frage wäre also, welche Berechnungen man überhaupt auslagern könnte. Als Beispiel: Das recht große Modell der CobraMkIII verfügt über 28 Punkte. Für jeden Punkt sind mindestens 9 Multiplikationen und 9 Additionen sowie zwei Divisionen nötig. Um diese Berechnung auszulagern, müßte man jedoch zunächst die Daten der 28 Punkte (28 * 4 = 112 Bytes) und die Rotationsmatrix und Objektkoordinaten an das Laufwerk übertragen, da dieses die Objektdaten in seinem kleinen Speicher nicht vorrätig halten kann. Das Rechenergebnis wäre noch aufwendiger, da man sowohl die berechneten 3d-Koordinaten als auch die finalen 2d-Werte sowie den Sichtbarkeitswert zurückübermitteln muß, d. h. im ungenauesten Fall 28 * (2 + 2 + 2 + 2 + 2 +1) = 308 Bytes. Hierin wäre die Sichtbarkeitsberechnung der Polygone aber noch nicht enthalten. Das Alles würde auch nur dannn wirklich eine Beschleunigung ergeben, wenn das Hauptprogramm im C64 in der Zeit etwas anderes erledigen könnte. Doch was sollte das sein? Als einziges käme hier das Malen des letzten Objekts in Betracht. Damit sich der Aufwand also lohnt, bräuchte es zwei Objekte, die am Bildschirm gleichzeitig angezeigt werden, was bei dem Spiel aber eher selten ist. Von daher würde ich mal ausschließen, daß das Auslagern für den Malprozeß geeignet ist.
Bliebe also die Möglichkeit, die Steuerung der Objekte auszulagern, d. h. während die Objekte an ihrer alten Position im C64 gemalt werden, wird im Laufwerk die neue Position berechnet. Der Datenaufwand wäre in diesem Fall deutlich geringer, da nur die Matrix und die Objektkoordinaten geschickt werden müssen. Es fragt sich aber, ob die 2 kb Ram des Laufwerks ausreichen, um den gesamten Steuerungscode aufzunehmen, wenn allein die Sinustabelle schon 512 Bytes verschluckt. Wenn ich mir dann so anschaue, wieviel Speicher die Routinen bereits zum reinen Rotieren der Objekte verbrauchen (ohne Tabellen ebenfalls um 512 Bytes), kommen mir große Bedenken, daß in dem verbleibenden 1 kb die Objektdaten, die Objekt-K.I. (z. B. Docking Computer) und die Übertragungsroutinen Platz finden. Ganz ausschließen möchte ich die Möglichkeit nicht. Wirklich sicher kann man sich erst sein, wenn man das gesamte Programm vor sich hat, aber nach aller Erfahrung würde ich eher darauf tippen, daß es nicht funktioniert.
Ich habe die flickerfixed version von M.J. ausprobiert und mir ist aufgefallen, dass das Fadenkreuz fehlt. Kann man das mit einer bestimmten Taste aktivieren ?
das Fadenkreuz fehlt
Danke für den Hinweis. Wird korrigiert. Nebenbei; Ich werkel zur Zeit an einer überarbeiteten Version, bei der auch ein anderer Fehler behoben sein wird. Die vorhergehende Version war tatsächlich nur so etwas wie ein Patch, d. h. einzelne Programmteile wurden rabiat überschrieben. In der neuen Version wird der Programmcode zum Malen der Raumschiffe hingegen komplett neu assembliert. Bis zur Fertigstellung wird es allerdings noch ein wenig dauern. Daher bitte ich um etwas Geduld. Danke im voraus.
Edit:
Ich habe heute mal das gute alte VHS Promovideo vom Ur- Elite ein wenig gepimpt.
Gerade erst gesehen. Sieht gut aus. Vielen Dank!
M.J., ich gehe davon aus dass Du deine gepatchte Version selber bei CSDB hochladen willst? Ich warte geduldig auf die neueste Version... danke fuer die Arbeit!
ich gehe davon aus dass Du deine gepatchte Version selber bei CSDB hochladen willst?
Bedaure, ich bin nicht Mitglied bei der CSDB. Daher werde ich die neue Version, sofern sie mal fertig wird, hier zum Testen anbieten. Zur Zeit wurschtel ich an vielen Stellen im Code herum.
Nur so als Beispiel: Ich würde gerne das Ruckeln der Objekte aufgrund der Ungenauigkeiten in der Matrixbearbeitung mindern. Dabei stellt sich jedoch wieder der Docking-Algorithmus (oder allgemein: Anvisieren eines Ziels) als größter Schwachpunkt des ganzen Programms heraus. Man erhält den Eindruck, als wären die Schwellenwerte für den Algorithmus (ab wann wird gebremst oder beschleunigt, wann wird rotiert) händisch an die Rechengenauigkeit des Programms angepaßt worden. Verändert man nun die Genauigkeit der Matrixberechnung, führt das dazu, daß der Docking Computer beim Andocken versagt und an der Station vorbeirotiert. Wie ich feststellen durfte, muß man als Gegenmaßnahme die Matrixwerte überdehnen (also größer machen als 1.0), damit die Schwellenwerte wieder greifen. 
Wie weit ich das Herumpfuschen am Code aber noch weiterführe, kann ich nicht sagen. Wahrscheinlich schlicht, bis ich die Lust daran verliere. Und dann hoffe ich, daß eine brauchbare Version zurückbleibt.
ich gehe davon aus dass Du deine gepatchte Version selber bei CSDB hochladen willst?
Bedaure, ich bin nicht Mitglied bei der CSDB. Daher werde ich die neue Version, sofern sie mal fertig wird, hier zum Testen anbieten. Zur Zeit wurschtel ich an vielen Stellen im Code herum.
Nur so als Beispiel: Ich würde gerne das Ruckeln der Objekte aufgrund der Ungenauigkeiten in der Matrixbearbeitung mindern. Dabei stellt sich jedoch wieder der Docking-Algorithmus (oder allgemein: Anvisieren eines Ziels) als größter Schwachpunkt des ganzen Programms heraus. Man erhält den Eindruck, als wären die Schwellenwerte für den Algorithmus (ab wann wird gebremst oder beschleunigt, wann wird rotiert) händisch an die Rechengenauigkeit des Programms angepaßt worden. Verändert man nun die Genauigkeit der Matrixberechnung, führt das dazu, daß der Docking Computer beim Andocken versagt und an der Station vorbeirotiert. Wie ich feststellen durfte, muß man als Gegenmaßnahme die Matrixwerte überdehnen (also größer machen als 1.0), damit die Schwellenwerte wieder greifen.
Wie weit ich das Herumpfuschen am Code aber noch weiterführe, kann ich nicht sagen. Wahrscheinlich schlicht, bis ich die Lust daran verliere. Und dann hoffe ich, daß eine brauchbare Version zurückbleibt.
Könntest du nicht die derzeit aktuelle Version, also die die ich gerade spiele und als letztes gepostet hatte, zumindest dahingehen fixen, das sie wieder das fadenkreuz anzeigt? Den ansonsten ist die Version ja Ok. Wäre schön dann wenigstens erstmal eine fehlerfrei version zu haben, bevor du durch das ganze optimieren, die lust verlierst. ( Bitte Bitte, ich hänge die letzte Version auch gerne nochmal an )
Könntest du nicht die derzeit aktuelle Version, also die die ich gerade spiele und als letztes gepostet hatte, zumindest dahingehen fixen, das sie wieder das fadenkreuz anzeigt?
Nein, leider nicht. Der Fehler lag darin, daß ich naiv davon ausgegangen war, daß das Spiel zu Beginn selbst die VIC-Register setzt, jedoch werden diese wohl noch vor dem Start des Programms (vom Loader?) gesetzt. Aus diesem Grunde wurden die Sprites nicht an der korrekten Position angezeigt. Der Fix bestand darin, nach Programmstart und vor Aufruf des eigentliches Spiels die korrekten Werte in die VIC-Register zu schreiben, aber dafür mußte ich die Startroutine ziemlich umschreiben, so daß diese Korrektur nicht übertragbar ist auf die alte Version. Vielleicht könntest Du mir jedoch einen Gefallen tun. Wäre es vielleicht möglich, daß Du eine Alpha-Version austestet? Dann würde ich versuchen, zwischendurch eine einigermaßen lauffähige Entwicklungsversion zu erstellen. Wäre das okay?
Könntest du nicht die derzeit aktuelle Version, also die die ich gerade spiele und als letztes gepostet hatte, zumindest dahingehen fixen, das sie wieder das fadenkreuz anzeigt?
Nein, leider nicht. Der Fehler lag darin, daß ich naiv davon ausgegangen war, daß das Spiel zu Beginn selbst die VIC-Register setzt, jedoch werden diese wohl noch vor dem Start des Programms (vom Loader?) gesetzt. Aus diesem Grunde wurden die Sprites nicht an der korrekten Position angezeigt. Der Fix bestand darin, nach Programmstart und vor Aufruf des eigentliches Spiels die korrekten Werte in die VIC-Register zu schreiben, aber dafür mußte ich die Startroutine ziemlich umschreiben, so daß diese Korrektur nicht übertragbar ist auf die alte Version. Vielleicht könntest Du mir jedoch einen Gefallen tun. Wäre es vielleicht möglich, daß Du eine Alpha-Version austestet? Dann würde ich versuchen, zwischendurch eine einigermaßen lauffähige Entwicklungsversion zu erstellen. Wäre das okay?
Klar, häng sie einfach hier an, oder schick sie als PM und sag mir, falls ich auf etwas bestimmtes achten soll.
