Posts by M. J.

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

    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!

    Dann würde ich sagen, der Emulator hat einen Bug. Bei der absoluten indizierten Adressierung ($ffff, x) wird X dazuaddiert und der Überlauf ignoriert, was auch Sinn macht, denn der 6502 kennt keine Adressen > $ffff.

    Anders ist es bei der Zeropage indizierten Adressierung ($ff, x). Hier würde nicht von der Adresse $103, sondern von $03 gelesen werden, da bereits das Highbyte ignoriert wird.

    Achtung: Dies gilt nur für den 8 Bit-6502, aber nicht für den 16 Bit-65816.

    Aber ein Online-Emulator (http://skilldrick.github.io/easy6502/) sagt etwas anderes.

    Vielleicht könntest Du die genaue Stelle in der Beschreibung heraussuchen, wo ein abweichendes Verhalten behauptet wird.

    Ernsthaft?

    Ja, ernsthaft. ^^ Vor einiger Zeit hatte ich zwecks einer Anpassung des Spiels an die SCPU am Code herumgefummelt, wobei mir auch die dazugehörige IRQ-Routine ins Auge fiel. Man kann es in Vice schön erkennen: Das Programm schaltet während des Vertical-Blanks per Interrupt in den 2 Mhz-Modus, was die Bildrate auf dem C128 deutlich höher werden läßt als auf dem C64. Dabei hätte das Spiel am C64 durchaus schneller sein können, wie meine Experimente gezeigt haben. Der Turbomodus auf dem C128 gleicht daher leider nur die Unzulänglichkeiten im Programmcode der Commodore-Version aus.:(

    Kann mich den Vorrednern nur anschließen. Es gab damals durchaus Gründe für einen Kauf (und warum ich meinen C128 immer noch mag :love: ) :

    - schönes Design

    - bessere Tastatur (gut fürs Programmieren)

    - eingebauter Maschinensprachenmonitor

    - 2 Mhz-CPU auch im C64-Modus, was nicht nur Spiele beschleunigen kann ("Elite", "Test Drive II"), sondern auch das Assemblieren arg beschleunigt

    - schnelles Laufwerk

    - 80 Zeichendarstellung und professionelle Software wie Protext (, mit der ich damals[tm] tatsächlich meine erste Seminararbeit geschrieben habe).

    - Musik in "Ultima V" ^^

    Ja, ich weiß, Blasphemie, aber für mich ist der C128 immer der bessere C64 gewesen. ^^

    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.

    Ein umschreiben des Ur Elite ist Praktisch Sinnlos.

    Komplett sinnlos würde ich nicht sagen. Die C128-Version ist so entstanden, jedoch sind in dieser Version die allermeisten Programmteile übernommen worden, dazu gehören die Grundlagen (Aufbau der Matrix) und die darauf aufbauenden Algorithmen sowie die Art der Visualisierung (HiRes ohne Double-Buffering). Anders gesagt: Trotz allem Herumschraubens bleibt es der gleiche Motor und auch die gleiche Karosserie. Für sowas wie gefüllte Polygone wären deutlich mehr Veränderungen nötig. Nicht unmöglich. Schließlich hat schon jemand den BBC-Code genommen und in ein C-Programm für den PC umgewandelt. Aber wer sollte warum sich diesen Aufwand aufhalsen? Neuprogrammieren wäre halt einfacher und für einen Entwickler auch interessanter.

    mit Schnellen Speichermedien wie 1541U oder Easy Flash

    Die Geschwindigkeit externer Datenträger wäre nicht so sehr entscheidend. Bei "Space Rogue" wird auch häufig gemächlich nachgeladen. Das kann in der heutigen Zeit vielleicht unruhige Gemüter nerven, dennoch sehe ich es nicht als Voraussetzung für ein Spiel an sich.

    Man kann ja Mal Castle Master mit der engine in der Andropolis Demo vergleichen

    Lieber nicht, da schneidet die Andropolis Demo eher schlecht ab. Wie bei einer Demo üblich, verschluckt sie jede Menge Speicher, der bei einem echten Spiel fehlen würde für den ganzen weiteren Code bzw. die Spieldaten. Des weiteren ist die Engine von "Castle Master" viel komplexer, d. h. für jeden Punkt (aka Vektor) werden mehr Multiplikationen und Additionen durchgeführt als bei der Demo, die nur über eine Rotationsachse verfügt. Füg eine zusätzliche Rotationsachse ein, und Du wirst sehen, wie die Geschwindigkeit zusammenbricht. Füg vor allen Dingen ein, daß weitere Objekte in den BSP tree eingehängt werden können zusammen mit Sichtbarkeit und painter's algorithm, und das Programm wird nochmals deutlich langsamer. Es muß natürlich nicht so langsam werden wie bei den Freescape-Spielen, aber so schnell wie die Demo suggeriert, könnte eine echte Spieleengine nicht werden.

    Das verstehe sogar ich, obwohl ich die höhere Mathematik niemals in der Schule hatte wie z.B. Integralrechnung, Differentialrechnung mit Kurvendiskussion, Vektorrechnung etc. und pp. Mittlerweile ärgert mich das immer mehr und mehr.

    Du wirst lachen, aber der Mathe LK an der Penne hat so gut wie gar nicht dabei geholfen, das Spiel zu verstehen. Einzig bei paar Begriffen wie Einheitsvektor ist es ganz nett, wenn man weiß, was sich dahinter verbirgt, aber ansonsten... Fehlanzeige. 3d-Graphik an sich ist auch gar nicht schwer zu berechnen und kann z. B. auch in Basic umgesetzt werden. Fies wird es, wenn es darum geht, die Algorithmen in Assembler zu schreiben, und die Tricks, die dabei zur Anwendung kommen, stehen in keinem Lehrbuch.:(

    Ich denke mal, dass für die hier genannten Spiele ein Videochip mit eingebauten 64kb Video Ram und einem Blitter, viel mehr bringen würde als eine Supercpu mit 20MHz.

    Der Gedanke ist zunächst naheliegend, weil die 3d-Graphik am Ende das ist, was der Spieler zu sehen bekommt. Tatsächlich verbringt das Programm aber mehr Zeit damit, Objekte durch den Raum zu steuern, das eigene Raumschiff auf Tastendruck hin zu bewegen, Musik oder Geräusche im Hintergrund zu spielen usw. Von daher würde ein schnellerer Prozessor größere Auswirkung haben als ein wie auch immer gearteter Zusatz-Grafikchip. Nebenbei: Ein Blitter, wie er z, B. im Amiga zum Einsatz kam, wäre für den C64 unbrauchsam. Damit könnte man höchstens einzelne Linien beschleunigen (, sofern der Blitter die krude Zeichensatz-Struktur der Bitmap versteht). Wie ich an anderer Stelle schon anmerkte, erfüllte der Blitter schon auf dem Amiga nicht die Erwartungen, die man mit ihm verknüpfte. Zu mehr als zum reinen Bildschirmlöschen wurde er bei 3d-Programmen meistens nicht eingesetzt. In einem anderen Thread hier im Forum hatten wir daher schon mal den Einsatz eines umfangreicheren Graphikbeschleunigers diskutiert. Dabei vertrat ich persönlich jedoch die Auffassung, daß solch ein Beschleuniger, der genau einer Engine entspricht, in seinen Möglichkeiten zu beschränkt ist, um den Anforderungen verschiedenster Spielformen gerecht zu werden. Daher würde ich stets für eine schnellere CPU plädieren, weil damit wirklich alles beschleunigt werden kann. O.O.B. läuft daher beschleunigt auf dem C128, dem DTV, dem TC64 und der SCPU. Und auch über den Sinn und Einsatz von CPU-Beschleunigern wurde - wie Du weißt - schon oft und ausführlich diskutiert. Für mich stellt eine Hardware-Beschleunigung eine zusätzliche Option da, wäre aber keine Voraussetzung, d. h. ein Programm läuft auch immer auf einem normalen C64.

    Ich denke mal, dass die Anzahl der Programmierer die ein Spiel wie Elite entwickeln und coden könnten, auch heute noch recht groß ist. Nur programmieren die meisten heute in C++ oder eine andere höhere Programmiersprache, um damit ihren Lebensunterhalt zu verdienen. Zur Hochzeit der 8-Bit Computer musste das Verhältnis der Personenstunde und des zu erwartenden Gewinns stimmen. Die Erstellung eines komplexen Spiels dauerte um ein vielfaches länger als z.B. die Entwicklung von Giana Sisters. Aufgrund der damals ausufernden Raubkopiererei, haben die meisten Firmen es nicht mehr riskiert, aufwändige Simulationen zu entwickeln, weil das ganz schnell zum Konkurs führen konnte und auch passiert ist.

    In der Tat, da ist was dran. Auf dem PC habe ich schon 3d-Programme in einer Hochsprache geschrieben, die kürzer und einfacher zu warten sind als ein Pendant in 6502. Entsprechend geht die Entwicklung schneller von der Hand und ist teilweise in ein paar Tagen erledigt. Ein 3d-Programm für den 6502 zu schreiben, dauert hingegen Monate. Davon konnte damals[tm] schon bald keiner mehr leben, geschweige denn heute. Ich gehe außerdem davon aus, daß für den Fall, daß jemand ein 3d-Spiel für den C64 veröffentlichen würde, die Verkaufszahlen im Vergleich zu anderen Action-/Hüpf-Spielen weit zurückliegen würden. Und sowas wirkt auch heute noch auf potentielle Entwickler abschreckend.

    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?

    Bisher läuft alles Super. Keine Bugs, keine Auffälligkeiten.

    Freut mich.

    Eigentlich müsste man doch also problemlos die Rahmenfarbe z.b. auf Dunkelgrau ändern können

    Die Rahmenfarbe $d020 kann sehr leicht geändert werden zu Beginn des Programms. Das würde jedoch nicht ausreichen, da die Anzeige horizontal lediglich ca. 256 Pixel der 320 Pixel verwendet. Folglich müßte man diesen Bereich ebenfalls über das Farbram einfärben. Könnte funktionieren, allerdings frage ich mich, ob es für die Augen gut ist, ständig auf einen grauen Rand zu starren.:/

    die planetenbeschreibung mit grafik (jeder eine eigene).

    Nur nebenbei: Die "Planetengraphik" bei der Planetenbeschreibung auf dem Amiga entsteht dadurch, daß das Spiel eine komplette Bitmap mit Punktemustern in verschiedenen Farben bereithält, von der ab einer zufälligen Koordinate ein Kreis als "Planet" kopiert wird. Die Punktemuster werden also gar nicht bei der Generation der Planetenbeschreibung aufwendig berechnet, was ein Beispiel dafür ist, wie man aufwendig erscheinende Probleme mit ein bißchen Speicher erschlagen kann.

    meinetwegen macht eine neue version aber dann für den m65 bitte

    Ich hatte mal daran gedacht, das Programm für den MEGA65 anzupassen, doch anfangs flossen die Informationen über das Gerät nur sehr spärlich, und nun beschäftige ich mich lieber mit anderen Projekten.

    Könnte man die CPU in der Floppy zur Berechnung der 3D-Grafik heranziehen und würde das eine merkliche Verbesserung ergeben?

    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.

    Das sieht man auch bei Operation Omega Blast: so schick es ist, so zäh ist's eben auch (deutlich langsamer als das Ur-Elite; OOB kommt ja schon mit nur einem Modell im Titelbild hart an die 1FPS-Grenze).

    Leider kann man das C64-Elite und O.O.B. nicht gut vergleichen. Nur so als Information:


    Multiplikation in der Punktberechnung

    C64-Elite:

    - Punktberechnung als 8x8 Multiplikation, wovon nur das Highbyte des Ergebnisses für die nachfolgende Addition weiterverwendet wird.

    Amiga-Elite, O.O.B.:

    - Punktberechnung als 8x16 Multiplikation. Alle 24 Bit des Ergebnisses werden für die Additionen verwendet.


    DIvision in der Punktberechnung

    C64-Elite:

    - Division über Logarithmentabelle. Ist der Wert für X oder Y größer als Z (, was der Fall ist, wenn man nah an Objekte heranfliegt), wird der Dividend stufenweise durch 2 geteilt (bitweise nach rechts geschoben) und das Ergebnis nach der Division der Anzahl der Stufen gemäß mit 2 multipliziert (bitweise nach links geschoben). Dies bewirkt, daß z. B. die Öffnung für den Dockingschacht (das Rechteckt bei der Station) im Nahanflug wild auf dem Bildschirm hin- und hertanzt.

    Amiga-Elite:

    - 16 / 16 Division, jedoch wurden vorher Zwischenwerte in unteren Bits abgeschnitten. Das führt dazu, daß z. B. das Orbit Shuttle (eines der kleinsten Objekte in Elite) in der Titeldemo leicht wackelt.

    O.O.B.:

    - 16 / 8 DIvision. Die Werte werden vorab so skaliert, daß mit der maximal möglichen Bitauflösung gerechnet wird. ==> Bei O.O.B. bleiben auch kleine Objekte stets stabil und wobbeln nicht herum.


    Sichtbarkeitsberechnung

    C64-Elite:

    - Verwendung von Normalenvektoren im 3d-Raum. Folge: Ungenau, da die perspektivische Verzerrung nicht berücksichtigt wird. Es gibt in den Modelldaten daher einen Extrawert, der angibt, wie "kantig" das Modell ist (z. B. Adder), um die Berechnung weniger genau zu machen, so daß Flächen früher als "nicht sichtbar" deklariert werden, da man ansonsten aufgrund der perspektivischen Verzerrung die Rückseite sehen würde.

    O.O.B.:

    - Verwendet die fertigen 2d-Bildschirmkoordinaten zur Bestimmung der Orientierung des Polygons, was exaktere Ergebnisse liefert. Dafür müssen aber die einzelnen Punkte vollständig durchgerechnet sein. Elite berechnet aber Punkte nur, wenn die Sichtbarkeit vorab bestätigt wurde.


    Rotation

    C64-Elite:

    - 2 fixe Drehungen um die eigene Objektachse und 2 variable Drechachsen für die Rotation des Spielerraumschiffs, die jedoch ungenau sind. Von letzteren wird im Titelbild nur eine verwendet (Drehung um die Z-Achse).

    Amiga-Elite:

    - Rotation in mehreren Stufen um 2 Achsen für Objekte und Spieler

    O.O.B.:

    - Rotation in mehreren Stufen um 3 Achsen für Objekte (und über die frei positionierbare Kamera und der damit verbundenen Matrixmultiplikation auch für den Spieler)


    Anzeigebereich

    C64-Elite:

    - in X-Auflösung nur von 0 bis 255. Beim Malen gibt es kein Highbyte für den X-Wert.

    O.O.B.:

    - volle X-Auflösung von 320 Pixeln und damit größerer Anzeigebereich.


    Linienziehen

    C64-Elite:

    - DDA mit Quotient ermittelt durch Division über Logarithmus (ungenau)

    O.O.B.:

    - Bresenham


    Alle diese Berechnungen haben noch nichts mit dem Füllen von Polygonen zu tun, führen aber zu einem Unterschied, doch dieser Unterschied liegt hauptsächlich in der Qualität der Berechnungen. Ich habe absichtlich zunächst eine möglichst genaue Berechnung gewählt, einmal in Anlehnung an den CPC-Code, aber auch, weil nur mit exakten Werten ein echter Eindruck von Plastizität entsteht, den ich bei den wobbligen Elitegraphiken ein wenig vermißt habe. Zum Austesten habe ich auch Drahtgittermodelle wie Elite verwendet, und die Differenz ist klar erkennbar. Zusätzlich gibt es im Programm die von außen nicht aktivierbare Option, die Polygondarstellung in HiRes vorzunehmen anstelle von Multicolour. Auch hier macht sich die höhere Genauigkeit trotz der diversen Füllmuster bemerkbar. Kurz gesagt: Man könnte O.O.B. beschleunigen, indem man die Genauigkeit herausnimmt und wie bei Elite rechnet. Oder man verwendet komplett andere Rechenverfahren, die aber mehr als 3 kb für zusätzliche Tabellen erfordern. Berechnungen auf dem 6502 sind ein weites Feld mit vielen Möglichkeiten und entsprechend vielen Stellschrauben.

    Elite z.B. auf dem Amiga ist da einfach eine ganz andere Hausnummer. Mit wieviel FPS läuft das da? Typisch etwa 20, minimal 4 oder sowas die Größenordnung schätze ich. Elite auf dem C64? Typisch 10, minimal 0,irgendwas vielleicht?

    Die Geschwindigkeit während des Raumflugs ist auf 18 fps begrenzt. Auf einem Amiga500 sinkt die Rate stark ab, wenn man z. B. nah an einen Planeten heranfliegt. Auch während der Launch Sequence kann man ein Ruckeln beobachten, und wenn man genau hinsieht bereits beim Thargoidenraumschiff im Titel. Die Graphikroutinen von Elite gehören im Vergleich zu den sonst mir bekannten leider zu den langsamsten. Das Spiel hätte schneller laufen können, doch anscheinend war es gar nicht nötig, denn den Spielern fiel es nicht auf, und eine höhere fps hätte auch eine feinere Steuerung der Raumschiffe nach sich gezogen, also wieder mehr Aufwand...

    Dein Adventure werde ich mal antesten...

    Wenn Du Dir das wirklich antun willst, würde ich Dir empfehlen, die Version von c64games zu nehmen und nicht die auf csdb. Letztere ist die allererste Version, die noch über einen nervigen Bug verfügt. Die Version auf c64games wurde ein wenig fehlerbereinigt und um einige Texte und Aktionen ergänzt.

    Was Braben über Bell sagt, würde ich immer mit grösster Vorsicht geniessen. Deren zwischenmenschliches (und damit geschäftliches) Verhältnis ist grundlegend verseucht, und von Bells Seite erläutert (insbesondere mit Blick auf die Rechtsstreitigkeiten) sieht das alles sehr viel anders aus als das was Braben auch nur irgendwie über die Entwicklung von Elite in die Welt verkündet. Bell ist hier nicht der bad guy, und Braben ist verglichen mit Bell mindestens mal der deutlich schwierigere Charakter.

    Und andersherum gilt dasselbe: Braben ist nicht der bad guy, und Bell kann auch ziemlich schwierig sein. Als Außenstehender hat man keine Möglichkeit da reinzugucken. Da kann man bestenfalls:popcorn:.

    Kennt Jemand John Carmack.

    Carmack...? Carmack...? Verdoomt, keine Ahnung, wer das sein soll.

    Mal schauen, vielleicht mache ich in einigen Wochen, Flight Simulator II mit allen Erweiterungen, mal als 1581/cmd/sd2iec/Easyflash fertig.

    :thumbup:

    Chuk Yeagers AFT, The Eidolon, Koronis Rift und Grand Prix Circuit haben auch eine recht flotte 3D Animation.

    "Chuck Yeager's AFT" und "Space Rogue" basieren beide auf der Engine von Edward Lerner, die nicht nur sehr schnell ist, sondern auch gefüllte Polygone verwendet. "Rescue on Fractalus", "Koronis Rift" und "The Eidolon" beruhen hingegen auf einer ganz anderen Art der 3d-Graphik-Berechnung, bei der nur die Landschaft als 3d berechnet wird sowie die Position von Objekten und die Objekte selber durch Verkleinerung perspektivisch angeglichen werden. Im Vergleich zu den anderen Spielen ist es also keine "vollständige" 3d-Berechnung, aber trotzdem gut gemacht. Besonders "Koronis Rift" hat es mir persönlich angetan. Das Spiel hätte ich gerne ohne Level und dafür in der Form von "Elite", also open end sand box.

    Was mir schon immer gefehlt hat, ist in Piloten Bildschirm ein Anzeige über die anzahl der Abschüsse. Man kann immer nur erahnen, wie nahe oder fern man der nächsten beföderung ist.

    Ich glaube, das ist Absicht der Programmierer. Sie wollten ja eine klassische Scoreanzeige eigentlich vermeiden. Eine Anzeige der Abschüsse würde daher dieser Absicht zuwiderlaufen.

    Oder das man beim kaufen immer alle wren einmal durch drücken muss, nervt mich schon seit ich klein war.

    Mich auch, aber ein Umschreiben der Menüs ist nicht so einfach. Der Programmcode ist aufgrund dieser einfachen Abfrage sehr kurz. Eine gezielte Auswahl von Waren wäre aufwendiger, damit vom Code her länger und würde nicht mehr in den Speicher passen. Um solche Änderungen vornehmen zu können, müßte man zunächst irgendwo Platz freischaufeln usw.

    Oder das man zum Speichern immer erst auf Diskette umstellen muss, weil Datasette als Default eingestellt ist.

    Das müßte man ändern können, sofern man weiß, wo sich der Schalter dafür befindet.

    Wäre es eigentlich möglich, die Gitter Linien einiger Objekte Farbig darzustellen

    Nein. Die Anzeige ist in HiRes (320x200) gehalten. Der C64 kann in dieser Auflösung nur 2 Farben darstellen in einem Bereich von 8x8 Pixeln. Da die eine Farbe die HIntergrundfarbe Schwarz ist, bleibt nur eine weitere Farbe für die Objekte übrig. Für mehr Farben müßte man daher den Multicolour-Modus (160x200) verwenden, was einer Halbierung der horizontalen Auflösung entspricht. Wie sich das auswirkt, kann man z. B. bei "Star Wars" sehen oder vielen anderen Flugsimulatoren. Nötig wären dafür aber neue Malroutinen. Ob die dann genauo schnell sind wie die Originalroutine ist wegen des höheren Platzbedarfs schwer zu sagen, denn die Linienroutine in "Elite" ist zwar auf eine Farbe beschränkt, aber dafür optimiert für die HiRes-Auflösung. Würde man diese Methode einfach auf Multicolour ausdehnen, wäre der Platzbedarf immens, weshalb es auf Poken von Werten hinausläuft usw. Desweiteren wäre die Farbverteilung gar nicht so einfach, denn auch im Multicolour-Modus kann der C64 pro 4x8-Kachel nicht mehr als 4 Farben anzeigen. Schaut man sich die verschiedenen 3d-Programme an, erkennt man, daß sie mit Ausnahme von "Space Rogue", welches tatsächlich zusätzlich das Farbram setzt, auch nur mit 4 Farben arbeiten. Bei "Elite" wären das (ungefähr, Variationen sind möglich) Schwarz für den Weltraum, Weiß für Sonne und Sternenstaub, Grün/Blau oder sonstwas für den Planeten und eine Farbe für alle weiteren Objekte wie Station, Raumschiff, Asteroid usw. So viel bunter dürfte es also nicht werden, besonders eine gezielte Einfärbung der einzelnen Raumschiffe halte ich für eher nicht realistisch. Und selbst, wenn man das alles geregelt hat, verbleibt das Problem, daß in der 3d-Anzeige auch Texte ausgegeben werden in einem HiRes-Zeichensatz wie "Docking Computer On" oder einfach nur "Vorne", "Hinten" etc. Dafür bräuchte man dann mindestens einen eigenen Multicolour-Zeichensatz, was zusätzlichen 1 kb entspricht, dazu im Programm eine Vorrichtung, die zwischen HiRes und Multicolour-Textausgabe umschaltet... Nein, leider alles viel zu aufwendig.

    Ist Fligh Simulator II komplexer als Elite?

    Puuuh... Das ist eine schwere Frage. Sind die beiden überhaupt vergleichbar? Mal sehen...


    (N. B.: "Flight Simulator II", "The Jet" oder auch "Thunderchopper" beruhen auf der gleichen Engine. Keines dieser "Spiele" habe ich wirklich gespielt. Alle Angaben ohne Anspruch auf Korrektheit mit der Bitte um Korrektur bei Fehlern. In "Flightsimulator II" gibt es z. B. den Modus "World War I" (oder so ähnlich), doch habe ich keine Ahnung, wie der aussieht.)



    Nachladen

    Elite:

    -

    Flightsimulator II:

    +


    mathematische Berechnungen

    Elite:

    Beschleunigung von Multiplikation und Division mittels Logarithmus

    Flightsimulator II:

    Multiplikation und Division als klassisches Bitshiften plus Addieren/Subtrahieren (bei Z-Projektion Restdivision mittels Tabelle)


    hidden line removal

    Elite:

    + Modelle sind bewußt konvex gebaut

    Flightsimulator II:

    - Gebäudemodelle sind teilweise zu kompliziert (wie bei "Mercenary")


    gefüllte Polygone

    Elite:

    -

    Flightsimulator II:

    + Nicht bei Gebäuden, aber bei der Landschaft (Meer, Landmasse). Bei "The Jet" und "Thundercopper" auch bei Gebäuden.


    Horizontberechnung

    Elite:

    -

    Flightsimulator II:

    +


    Welt

    Elite:

    prozedural generiert, 3d-Welt besteht nur aus Objekten relativ zur Spielerposition. Planet und Sonne sind ebenfalls Objekte (eine Objektliste für alle Elemente).

    Flightsimulator II:

    fest eingespeicherte Karte. 3d-Welt besteht aus Landschaftszeichnungen und Gebäuden


    Objekte

    Elite:

    verschiedene frei bewegliche Objekte

    Flightsimulator II:

    Im normalen Modus: Nur eigenes Flugzeug kann bewegt werden, andere Objekte (Gebäude) sind statisch. Zumindest bei "The Jet" gibt es gegnerische Kampfjets.


    Kamera

    Elite:

    nur eine Kamera (Spieler). Alle anderen Objekte befinden sich in relativer Position und Drehung zum Spieler

    Flightsimulator II:

    frei positionierbare Kamera


    visuelle Berechnung

    Elite:

    Objektpunkte werden bei der Visualisierung auf Grundlage von 8*8-Multiplikation um den Objektmittelpunkt rotiert. Eine Rotation um die Kamera findet dabei nicht statt.

    Flightsimulator II:

    Objektpunkte werden nicht um den Objektmittelpunkt (feste Punkte in der Landschaft), sondern als 16*8-Multiplikation um die Kamera rotiert.


    Clipping

    Elite:

    Beim Linienzeichnen wird auf Sichtbarkeit getestet und gegebenfalls ein Clipping auf den 2d-Bildschirmkoordinaten durchgeführt.

    Flightsimulator II:

    Es wird bereits vor der Z-Projektion (Z-Division) im 3d-Raum ein Clipping gegen das Frustum durchgeführt. Getestet wird hierbei auf ABS(X) > Z bzw. ABS(Y) > Z. Vorteil: "Lazy Evaluation" (vgl. Brabens Vortrag). Außerdem wird dadurch die nachfolgende Division vereinfacht, da stets gilt Dividend <= Divisor. Um das Frustrum jedoch deckungsgleich zu machen mit den rechteckigen (nicht quadratischen) Ausmaßen des Anzeigebereichs, wird die Rotationsmatrix entsprechend gequetscht. Die sich daraus ergebende Ungenauigkeit erkennt man bei den Gebäuden daran, daß sie horizontal leicht gestreckt wirken.


    Z-Clipping

    Elite:

    -

    Flightsimulator II:

    + (ergibt sich aus dem 3d-Frustrum)


    Simulation

    Elite:

    - keine echte Simulation. Physik frei erfunden, und mathematische Operationen angepaßt an möglichst einfache Berechnung in Assembler

    Flightsimulator II:

    + beruht auf echten physikalischen Berechnungen


    Steuerung im Raum

    Elite:

    frei drehbare Rotationsmatrix, kein Gimbal lock (wie z. B. bei "Mercenary")

    Flightsimulator II:

    Berechnung der Rotationsmatrix auf Grundlage von Winkeln


    K.I.

    Elite:

    Gegner verfügen über Algorithmen zum Anfliegen von Objekten (Station, Spieler), Abschießen von Raketen, Ausweichmanövern usw.

    Flightsimulator II:

    ?? Bei "The Jet" werden gegnerische Kampfjets gesteuert, aber Genaues kann ich darüber nicht sagen.


    Sonstige Menüs

    Elite:

    Handel, Sternenkarte/-Informationen, Schiffserweiterungen, Status

    Flightsimulator II:

    reine Simulation


    Das ist nur eine kleine Auswahl nennenswerter Punkte. Bei längerem Nachdenken würden sicherlich noch mehr einfallen, doch schon hier könnte ich persönlich nicht mehr sagen, welches von beiden komplexer ist. Dafür sind sie in ihrer Grundstruktur einfach zu verschieden. Je nach dem, worauf man selbst Wert legt, könnte man mal den einen, mal den anderen Punkt herauspicken und dessen Komplexität im Vergleich hervorheben. Beide Programme sind jedenfalls kompliziert genug, daß ein Programmierer sehr lange braucht, um sie zu schreiben, und beide können in ihrer Zielgruppe für ebenso langen Spielspaß sorgen.

    allerdings scheint was mit der Datei nicht zu stimmen

    Danke für den Hinweis. Dummerweise hatte ich vergessen, die Datei wie vorher mit dem Exomizer zu packen. Da ich bei mir in WinVice den Autostart auf "inject to ram" eingestellt hatte, habe ich es nicht gemerkt. :( Tut mir leid. Hier also die gepackte Version.

    Hab mir dafür extra mal eben unterwegs nen Emu auf dem Smartphone installiert

    8| Das lohnt aber nicht.

    Bei Operation Omega Blast ist es aber bei einer Demo geblieben oder?

    Bislang leider ja. Die Konvertierung vom CPC auf den C64 war schwieriger als gedacht, da man auf dem 6502 mehr Tabellen anlegen mußte, die jede Menge Speicherplatz verbrauchten. und auch viele Programmroutinen länger wurden im Vergleich zum Z80. Dann kamen die Menüs hinzu, und der Speicherbedarf platzte aus allen Nähten. Ich habe mehrfach versucht, das Problem mit Nachladen zu lösen, mußte aber dafür das Programm wiederholt umschreiben, wodurch viel Zeit verloren ging, so daß es bis zum Abgabetermin nicht mehr gereicht hat. :( Das liegt auch daran, daß unsichtbar für den Spieler unter der Motorhaube neben der 3d-Graphik eine noch ganz andere Code-Entwicklung in das Programm eingeflossen ist, die letztendlich das Rückgrat des gesamten Spiels darstellt. Dieser Bestandteil war damals noch recht neu und ein wenig unfertig. Inzwischen habe ich zwar beide Sachen getrennt weiterentwickelt, verfolge aber zur Zeit ein ganz anderes Projekt, so daß es mit O.O.B. nicht weitergeht.

    könnten die nicht helfen, die Flickerfixed Version zu "Entcheaten"

    Vielleicht. Aber wozu sich die Arbeit machen, wenn man sich nur ein bißchen in Geduld üben muß? Anbei eine Version ohne Cheats. Sollte irgendwann irgendwo ein Fehler auftreten, bitte ich um Mitteilung. Vielen Dank!

    Würdest Du Dich programmiertechnisch auf einem Level mit Braben/Bell daaamals™ sehen?

    Nein, nein, keineswegs. Es gibt einen entscheidenden Unterschied zwischen den Programmierern damals[tm] und Typen wie mich heute: Damals haben sie nicht nur 3d-Graphik programmiert, sondern zugleich auch alle Algorithmen und Tricks entwickelt, die sowas auf einem Homecomputer erst möglich gemacht haben. Die Verwendung von Logarithmentabellen für Multiplikation und Division, die Handhabung der Rotationsmatrix zum Drehen der Objekte, die prozedurale Generierung der Sternenwelt... All das haben sie in einem ziemlich kurzen Zeitraum mitkreiert. Viele der Vorgehensweisen von Bell&Braben finden sich auch heute nicht in den üblichen Standardwerken zur Graphikprogrammierung, weil sie eben nicht zum Standard gehören. Um Algorithmen auf diesem Niveau neu entwickeln zu können, braucht es fundierte Kenntnisse in Mathematik und deren Anwendung. (Ian Bell hatte Mathematik studiert sowie Informatik, und David Braben Naturwissenschaften.) Das gilt übrigens nicht nur für die Autoren von "Elite", sondern auch für andere wie Paul Woakes ("Encounter", "Mercenary"), die Entwickler des "Flightsimulator II" und viele mehr (nicht zu vergessen die anderern Spielegenres wie Abenteuer- oder Rollenspiel). Wir heute imitieren und kopieren nur das, was damals[tm] aus dem Nichts geschaffen wurde. Oder, wie Oasis es so schön formulierten: Wir "stehen auf der Schulter von Giganten". (Wobei sie leider vergessen haben, uns zu sagen, welche Schulter sie meinen: links oder rechts.:nixwiss:) Zwar ist die Engine von O.O.B. von grundauf komplett neu entwickelt, zwar versuche ich auch eigene Algorithmen in den Code mitaufzunehmen, aber es bleibt unverkennbar eine starke Anlehnung an den Klassiker. In dieser Hinsicht bin ich mit meinem Adventure mehr zufrieden. Nicht nur, weil das Programm fertig geworden ist, sondern auch, weil - abgesehen vom Genre Textadventure an sich - die Implementation eines Parsers, der deutsche Befehlssätze wirklich analysiert, tatsächlich ein Novum darstellt, und auch alle weiteren Algorithmen zur Scriptsprache oder Schnellader einzig auf meinem Mist gewachsen sind.

    Würdest du sagen, das Vector Grafik Spiele deutlich schwere zu erstellen sind, wegen der Mathematik die dahinter steht und das es daran liegt, das sich da niemand ran traut?

    Das man auch am C64 was Flottes in 3D auf die Beine stellen kann, beweist ja Stunt Car Racer ganz gut. Auch Gunship habe ich damals sehr geliebt.


    Oder sind 3D Games schlicht nicht beliebt genug, im vergleich mit 2D Games?

    Zum einen gilt, was Claus sagt. Es wurde ja sogar schon versucht, sowas wie "Doom" auf dem C64 zu programmieren. Hauptsache, man läuft durch irgendwelche grob pixeligen Gänge und ballert auf Monster.:sleeping: Der Geschmack bzw. das, was Menschen bereit sind zu akzeptieren, hat sich stark gewandelt. Damals[tm] war es üblich, dicke Handbücher zu lesen, und die angedeutete Graphik, sei es als Vektorgraphik oder als Strichmännchen in Rollenspielen wie "Ultima IV", war gleichzeitig Schwäche und Stärke der damaligen Spiele. Wer bereit war (oder noch immer ist), sich darauf einzulassen, kann tief in diese Welten eintauchen, aber die Bereitschaft dazu hat schon ziemlich abgenommen. Anders als bei den Hüpf-Spring-Schießspielen, wo Pixelgraphik zu einer eigenen Kunst erhoben wurde.

    Die Mathematik dahinter wäre gar nicht so kompliziert, wenn nur die Umsetzung auf einem 8 Bit-Rechner nicht allerlei Verrenkungen verlangen würde. Das gleiche Programm, welches auf dem PC ein paar Zeilen kostet, verschluckt hunderte von Zeilen 6502-Code, und neulich hatte ich für einen kleinen Vergleichstest auf dem Amiga500 ein kurzes Programm geschrieben, welches eine CobraMkIII auf dem Bildschirm als Vektorgraphik rotieren läßt. Dieses Programm lief nicht nur mit einer Framerate von 50 Bildern pro Sekunde, der Codeumfang war im Vergleich zum C64 auch noch minimal.

    Im Gegensatz zu Actionspielen benötigen 3d-Programme auf dem 6502 also viel mehr Code. Ich habe schon kommerzielle Spiele auf dem AppleII gesehen, deren gesamter Programmcode in 7 kb steckte (von $400 bis $1fff). Der Rest der 48 kb war gefüllt mit Graphikdaten. Bei 3d-Spielen ist es genau anderes herum. Man hat vielleicht 7 kb für Graphikdaten, aber der Rest der 48 oder 64 kb geht vollständig drauf für Code. Mit anderen Worten: Der Programmieraufwand ist immens. Während man auf dem C64 schon unter Zuhilfenahme von ein paar Sprites ein lustiges Spiel in 100 Codezeilen unterbringen kann, sind es für 3d-Spiele tausende von Zeilen.

    Hinzukommt noch, daß 3d-Spiele selten vom Plot her einfach gestrickt sind wie Weltraumshooter: Abballern, Punkte kassieren, neuer Level... Viele Spiele waren "Simulationen" - wie das von Dir erwähnte Gunship - mit umfangreichem Handbuch und komplizierter Steuerung, d. h. es kommen neben den aufwendigen mathematischen Berechnungen noch allerlei weitere Routinen und Menüs (prozedural generierte Sternenkarte, Missionsgenerator, Navigationpanel etc) hinzu. Ein solches Spiel zu entwickeln dauert Jahre. Welch Wunder, daß daher kaum jemand die Mühe auf sich nimmt, zumal ein Erfolg beim Publikum eher fraglich ist (s. Claus).

    Hmm.... Zum einen ist Karl May wohl eher ein deutsches Phänomen und damit deutsche Entwickler in der Verantwortung. Die gab es damals[tm] aber noch selten. und die meiste Software stammte aus England und den USA.

    Wäre das nicht ideal für ein Textadventure gewesen?

    Sicherlich, nur wäre der Markt dafür nicht so groß gewesen, und die wenigen, die deutsche Adventures entwickelt haben, wollten lieber ihren eigenen Stoff umsetzen. Nichtsdestoweniger bieten die gesammelten Werke von Karl May natürlich genügend Material für vielfältige Abenteuer. Es gibt ja nicht nur die Old-$name-hand-Geschichten, sondern ebenso zahlreiche Bände um Kara Ben Nemsi oder die Münchmeyer-Romane.

    Kann jedoch auch sein, daß sich keiner an die Umsetzung gewagt hat, da die Gefahr besteht, daß gerade die Fans von Karl May ein Computerspiel ablehnen, weil es nicht "authentisch" genug ist. Zum einen gibt es da die Leser der Romane, die sich ihr eigenes Bild gemacht haben, zum anderen gibt es die Anhänger der Filme, welche das Prädikat "frei nach Karl May" tragen, weil der Inhalt doch ziemlich lose an die Romane angelehnt ist, aber dafür mit den Ikonen Pierre Brice und Lex Barker aufwarten. Allein eine Pixelversion dieser beiden Charaktere dürfte auf wenig Gegenliebe gestoßen sein. Besser also man nimmt sich stattdessen die früheren Werke (und späteren Bände) als Grundlage vor, doch welcher Programmierer hat die schon gelesen, und wer würde sie im Kaufhof im Regal als "typisch Karl May" erkennen? "Die Herren von Greifenklau", "Trapper Geierschnabel", "Zobeljäger und Kosak", "Der Peitschenmüller"... Nicht bekannt? Eben.

    Another world auch fürs SNES von Burger Becky.

    Danke. Guter Hinweis.

    Rein für 16-Bit staubt ein 20 MHz 816er einen 8 MHz-68000 schon ab.

    Jo, die Turbokarte auf dem Apple//gs mit einem 20 Mhz 65816 hat durchaus das Zeug, den 68000 links liegen zu lassen.^^ Aber auch der Standard Apple//gs hatte schon 2.8 Mhz, was mehr ist als der C128 im Turbomodus. Umso erstaunlicher also, daß kaum jemand versucht hat, das Mehr an Rechenpower für 3d-Graphik auszunutzen. Die Rechenroutinen liefen ja bereits auf dem 6502. Die hätte man teilweise auf 16 Bit erweitern oder einfach so lassen müssen. Man sieht ja schon an der C128-Version, wie sehr ein bißchen mehr an Mhz für einen spürbaren Schub sorgt.

    könnte man bei ELITE den vorhandenen Code noch weiter Optimieren das etwas Ram frei wird,

    Ja, die C128-Version hat das bereits gezeigt. Ein wenig mehr Platz kann man rausholen. Der Autor nennt selbst solche Sachen wie Komprimierung der Cockpitgraphik und anderes. Grundvoraussetzung hierfür ist aber, daß man Code hat, der bis aufs letzte Label disassembliert und damit völlig relokatibel ist. Bei meiner AppleII-Version ist das der Fall, beim C64 nicht. Hier müßte man noch alle indirekten Sprünge (über Sprungtabellen etc) sowie weitere indirekte Referenzen im Sourcecode aufspüren und umformen. Das ist rein theoretisch kein Problem.

    Generell jedoch würde ich sagen, daß entscheidend für ein Umschreiben nicht die Frage ist, ob es machbar ist, sondern viel mehr: Wer macht es? Dies betrifft auch alle Gedankenspiele über einen beschleunigten Prozessor (SCPU, TC, C65 etc). Bereits jetzt kann man auf dem normalen C64 ein Spiel erstellen, welches über das damalige "Elite" hinausgeht, sei es als Vektorgraphik wie früher oder mit gefüllten Polygonen. Nur... bis auf einen komischen Spinner, dessen Namen ich hier nicht nennen will, hat sich noch niemand daran gewagt. Statt dessen gibt es weiterhin jedes Jahr viele neue scrollende Actionshooter. Solange aber niemand bereit ist, sich an die Aufgabe zu machen, ein 3d-Spiel zu entwerfen, erübrigen sich eigentlich die Diskussionen um eine Beschleunigung, denn heutzutage ist es nicht die Hardware, die die Software gebiert, sondern die Software steht am Anfang des Entwicklungsprozesses. Wo das nicht berücksichtig wird, gerät auch die beste Erweiterung schnell in Vergessenheit.

    Da braucht es m. E. weit mehr als einen 4 MHz Z80

    Hmm... Die Entwicklungsversion von O.O.B. auf dem CPC hatte auch schon gefüllte Polygone und war - meiner Meinung nach - ausreichend schnell und deutlich schneller als auf dem C64.

    Die Polygone kamen doch erst mit 16- und 32-Bitter (also zumindest am Amiga oder Atari ST war es so), oder?

    Nein, Spiele mit der Lerner-Engine ("Space Rogue" sowie "Chuck Yeager's AFT") verwendeten auch schon gefüllte Polygone. Auch einige Flugsimulatoren wie "ThunderChopper" oder "The Jet" setzen teilweise gefüllte Polygone ein. Bei "Driller" usw. sind (langsame :sleeping:) Polygone fester Bestandteil. Etwas schneller sieht es hingegen aus bei dem späteren "Battle Command" mit einer schon spielbaren Framerate. Allerdings haben diese Spiele zumeist eine begrenzte Anzeigefläche bis maximal der Hälfte des Bildschirms. So schöne große 3d-Graphik wie bei Virus, Frontier, Zeewolf... gibt es auf dem C64 selten.


    Edit: Verzeih, Du meintest wahrscheinlich bezogen auf "Elite". In dem Fall hast Du natürlich recht. Die erste Version mit gefüllten Polygonen war wohl die für MS-DOS, also auch schon 16 Bit. Danach kamen dann Acorn Archimedes, Amiga und AtariST. (Für den Apple//gs gab es leider keine Version mehr, wie es überhaupt kaum 3d-Spiele für den Rechner gab. :()

    Echt blöd, das man nun eine Version hat die nicht mehr Flackert, dafür aber wegen der eingebauten cheats keinerlei herausforderung mehr hat.

    Leudä... Bitte... Gebt mir ein bißchen Zeit. Ich hab den Sourcecode ja schon rausgesucht.

    Ja die CPC Version hat echt was für sich. Was ist am CPC eigentlich so anders, das bei dem gefüllte Polygone, kein flimmern ect. möglich sind, und am C64 nicht? der hat doch auch nur 64 KB. Die der so viel höher getaktet ?.....( GOOGEL....bitte warten.....aha) ok 4 Mhz Takt ist natürlich ne ecke mehr.

    Die CPC-Version hat gefüllte Polygone??(

    Daß diese Version nicht flimmert, liegt daran, daß es eine Art Double Buffering verwendet. Die Graphik wird zunächst in einem Puffer gemalt und dann auf die eigentliche Bitmap kopiert. (Gleiches Prinzip findet sich z. B. auch bei der C64-Version von "Driller".) Warum das möglich ist? Ganz einfach: Die CPC-Version ist kein One-Filer, sondern lädt von Diskette nach. Wie ich schon schrieb: Double Buffering wäre auch auf dem C64 möglich unter der Voraussetzung, daß wie bei "Space Rogue" (und anderen 3d-Spielen) nachgeladen werden kann. Man hat aber damals[tm] entschieden, das Programm in einer Kassettenversion ohne Nachladen auf den Markt zu bringen. (Andere Spiele wie "Space Rogue", "Flightsimulator II", "Chuck Yeager AFT" entstanden auf dem AppleII, der standardmäßig über ein schnelles DIskettenlaufwerk verfügte.)

    Der 4 Mhz-Takt des Z80 ist nicht 1:1 vergleichbar mit dem 1 MHz-Takt des 6502 (, der intern auch mit 2 Mhz läuft). Der Z80 braucht für die Bearbeitung der meisten Befehle mehr Arbeitsschritte als der Z80 6502 und ist im Endeffekt dadurch nicht unbedingt schneller, zumal CPC und C64 ähnlich schnelles Ram verwenden. Von Vorteil ist, daß der Z80 für Rechenoperationen wie Multiplikation oder DIvision mehr Register zur Verfügung hat, während der 6502 auf Zeropage-Variablen ausweichen muß. Außerdem gibt es einige Befehle wie "INC B", die tatsächlich doppelt so schnell sind wie auf dem 6502. Und die indirekte Adressierung über das HL-Register ist ebenfalls schneller als die komplizierte Adressierung "(zp), y" auf dem 6502. Zuletzt gibt es auf dem Z80 natürlich auch den Vorteil, daß es einige (nicht unbedingt leicht handhabbare) 16 Bit-Befehle gibt. All dies zusammen sorgt dafür, daß man in puncto 3d-Berechnung auf dem Z80 einiges herausholen kann. So braucht man anders als beim 6502 z. B. keine Multiplikationstabellen für eine schnelle Multiplikations. Die helfen dem 6502 auf die Beine, da Tabellenadressierung seine Stärke ist. Doch der Platzbedarf dafür ist enorm und eben in One-Filern nicht zu leisten. Die 3d-Adventure-Spiele wie "Driller" und Co bleiben auf dem C64 weit hinter ihren Möglichkeiten zurück. Hätte man diese Spiele so gestaltet, daß die einzelnen Räume nachgeladen würden, gäbe es genug Platz für schnellere Multiplikationen, echtem Double-Buffering und damit eine wesentlich höhere Framerate. Hätte... Hätte...

    Ist das auch in eine C64-Version zurückgeflossen? Ist das eventuell das, was in Flicker Fix etc. vorkam?

    Nein, der Flicker Fix ist so bereits in der Originalversion von Elite auf dem AppleII vorhanden. Diese Version entstand später als die C64-Version und wurde - wenn ich mich recht erinnere - hauptsächlich von Ian Bell geschrieben. Es ist aber auch gut möglich, daß bereits allgemeine Arbeiten an einem 6502 "Elite II" mit eingeflossen sind. Der Vortrag von David Braben im obigen Link deutet darauf hin, daß neue Berechnungsalgorithmen entwickelt worden sind, die aber nicht mehr den Weg in eine Veröffentlichung auf den 6502 gefunden haben, da das Projekt später abgebrochen wurde und Braben die Entwicklung von "Frontier" auf den 68000 verlagerte. Ein kleines (meiner Meinung nach nettes) Feature gibt es in der AppleII-Version im Vergleich zum C64: Bei der Explosion der Energiebombe wird auf dem C64 die Bildschirmfarbe geflasht. Auf dem AppleII werden hingegen Zufallslinien von links nach rechts auf dem Bildschirm gemalt, die eine Art Energieblitz andeuten sollen.

    Übrigens gibt es auf dem C64 schon einige Unterschiede zwischen den einzelnen Versionen. So weit ich beim Überfliegen sehen konnte, beruht die verlinkte DIsassembly-Version auf der ersten Umsetzung, die noch ohne Titelmelodie war. Das ist auch der Grund, warum es bei der Version gelungen ist, 2 kb frei zu haben für die Quadratzahlen-Tabellen. Bei der deutschen Version hingegen bleibt ohne sehr aufwendige Änderungen am Code kaum Platz für irgendwelche Ergänzungen, geschweige denn 2 kb. Im Gegenteil wurden damals für die Versionen mit Titelmelodie sogar die Logarithmentabellen um eine Tabelle gekürzt. Ursprünglich gab es vier Tabellen:

    - Log Low

    - Log High

    Damit läßt sich für einen Wert zwischen 1 und 255 ein 16 Bit-Logarithmus ermitteln.

    - Anti-Log 0

    - Ant-Log 1

    Andersherum läßt sich für einen logarithmischen Wert zwischen 0 und 255 hiermit der "normal" Wert berechnen. In der alten Version gibt es hierfür zwei Tabellen. Dies liegt daran, daß hier bei den Berechnungen noch das Highbit des Lowbytes für die Ermittlung des finalen Anti-Log hinzugezogen wird. Das macht die Berechnung ein wenig genauer. Im Grunde genommen handelt es sich also um eine Gesamttabelle mit 512 Einträgen:

    Diese Aufspaltung auf zwei Antilog-Tabellen hat man in den späteren Versionen (wohl aus Platzmangel) herausgenommen. Allerdings habe ich mir bei der gepachten C64-Version die Freiheit genommen, diese Tabelle wieder mit aufzunehmen.

    Eine kleine Sache, die tatsächlich von meiner modifizierten AppleII-Version übernommen wurde, ist die Verwendung einer weiteren Tabelle für die Matrixdivision. Das ist eine merkwürdige Sache in Elite. Die Werte für die Rotationsmatrix liegen als Festkommawerte zwischen 0 und $6000 vor, wobei $6000 dem Wert 1.0 entspricht. Entsprechend bedeutet $3000 einen Wert von 0.5 und $1800 einen Wert von 0.25. Vor dem Malen werden diese Matrixwerte künstlich aufgeblasen, indem sie zuerst mit 2 multipliziert werden (aus $6000 wird $c000) und dann das Highbyte durch $c0 geteilt wird. Das Ergebnis zwischen 0 und 1.0 entspricht dann in der Festkomma-Darstellung in einem Byte einem Wert zwischen 0 und 255 und nicht zwischen 0 und $c0. Dieser Wert wird später bei der Vektorberechnung der Modelle verwendet.

    Dieses Aufblähen der Matrixwerte ist natürlich ungenau, da die Division nur auf einem Byte ausgeführt wird. Beim C64 wird diese Division aber auch noch über die Logarithmentabellen abgewickelt, was bei großen Zahlen zusätzlich sehr ungenau ist. Als Gegenmaßnahme habe ich eine Tabelle eingebaut, die für jeden Wert von 0 .. $c0 einen vorab genau berechneten Wert für X / $c0 enthält. Beide Maßnahmen (zweite Antilog-Tabelle und genauere Division durch $c0) sorgen dann (hoffentlich) für ein wenig exaktere Berechnung der Graphik. Nebenbei: Auf dem Amiga/AtariST hat Mr. Micro für die Matrix Werte von 0 bis $4000 genommen, da diese einfacher zu handhaben sind. Ein Wert von $6000 für 1.0 hat nämlich auch im weiteren Code noch einige Auswirkungen.:(


    EDIT by FXXS: einen Z80 durch 6502 ersetzt...

    Er hat das Dissassembly zumindest in eine Assembler-Version (auf Github) gebracht (wenn ich das soweit richtig verstanden habe und er sich da nicht mit fremden Federn schmückt), mit dem Ziel eine Basis für Verbesserungen zu haben (wie schon eingangs gefragt wurde: würde man es heute besser machen können?)

    Hmmm... Was soll ich dazu sagen... :/ Also... Die Patches, die ich bei Elite vorgenommen habe, beruhen auch auf diassemblierten Sourcecode. Genauer gesagt habe ich das damals[tm] schon gemacht, als ich noch zur Schule ging...

    und hat schon das eine oder andere optimiert und probiert (wenn man so im Source-Code stöbert).

    Er hat sicher noch einiges vor bzw. wollte das eine oder andere noch probieren.

    Vor ca. 15 Jahren oder so hatte ich mir nochmal die AppleII-Version vorgenommen (entspricht der C64-Version abgesehen von Sound, Trumble-Mission und Planetenzeichnung) und mit allen möglichen Erweiterungen ausgestattet. Dabei habe ich große Teile des Codes umgeschrieben oder komplett neugeschrieben (Routine zum Malen der Raumschiffe, Zeichnen des Planeten mittels echtem Bresenham-Kreis ohne Flimmern, neuer Docking-Algorithmus usw.).

    Insgesamt hatte ich aber den Eindruck, dass er zum Schluss kam, dass das Spiel weitgehend deutlich weniger Potenzial für Optimierungen bot

    Ich hab eher den Eindruck, daß er vor der Mathematik kapituliert hat. Die hat es nämlich in sich, und ohne die wirklich verstanden zu haben, sind Änderungen am Code nicht wirklich möglich. Elite bietet noch sehr viel Potenzial für Optimierungen, die Frage ist nur, wieviel man davon in den Speicher reingequetscht bekommt. (Beim AppleII stellte sich dieses Problem nicht, da dieser einerseits über zusätzliche 16 kb in der Language Card verfügte, die vom Spiel - warum auch immer - nicht gebraucht wurden sowie (heutzutage auf Emulatoren ohne weiteres verfügbar) weitere 64 kb AuxRam.)

    Auf Twitter gibt es jemanden, der Elite mal unter die Lupe genommen hat. Einen Thread dazu gibt es hier.

    Hmm.... Ich weiß nicht... Er behaupt gleich zu Beginn:

    Quote

    The entire HUD bitmap -- include completely empty space at the sides -- is copied *every* frame; and with a non-optimal copy method as well. No wonder this game is slow :/

    Das ist Unsinn, wie jeder leicht feststellen kann. Die Routine zum Kopieren der Cockpitgraphik liegt bei der deutschen Version bei $b2e3. Setzt man im Vice-Monitor einen Breakpoint auf die Adresse, stellt man fest, daß sie nur aufgerufen wird, wenn die Ansicht/das Menü umgeschaltet wird, aber definitiv nicht bei jedem Frame. Die Balken der Radaranzeige als auch die anderen Anzeigebalken für Geschwindigkeit usw. werden wie die Vektorgraphik mittels EOR-Verknüpfung gemalt und wieder gelöscht, aber nicht durch Neuzeichnen der Cockpitgraphik.