ELITE tech Diskussion

Es gibt 185 Antworten in diesem Thema, welches 34.582 mal aufgerufen wurde. Der letzte Beitrag (11. Dezember 2023 um 13:13) ist von tilobyte.

  • Bei Mandelbrotprogramm würde sowas mit Sicherheit eine Steigerung der Rechengeschwinigkeit mit sich bringen.

    Diese Frage habe ich gestellt, weil man damit der Standartkonfiguration eines C-64 genüge getan hat. Keine SCPU oder REU oder...ect.

  • Wer also sagt, das Gefüllte Polygone, Cockpitgrafik und grafisch ansprechende Menüs nicht möglich wären, der wird halt durch Operation Omega Blast und co. direkt wiederlegt.

    In Sachen Grafik ist "nicht möglich" sehr relativ. Gefüllte Polygone sind schnell/mit angenehm hohen FPS auf dem Ur-C64 nicht möglich. 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).

    Wenn man FPS ganz ignoriert, kann man auf dem C64 sogar Raytraying machen...

    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?

    Da kann man eben wenig dran machen. Und andere Hardware? REU-ähnliches mit Blitter? Dann kann man Vektor-3D auch über Bord werfen, es so machen wie Wing Commander (II) damals und einfach Sprites nehmen, der Speicherplatz ist ja da. Dann hat man auch genügend FPS. :)

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Was die Floppy angeht: Die hat halt kaum RAM, und während des Datentransfers zwischen C64 und Floppy sind beide blockiert (der Datentransfer läuft nicht "im Hintergrund" per DMA, wie es alle halbwegs modernen Systeme machen).

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ja, das hatte ich schon vermutet. Ich dachte, dass hätte mittels 2bit IRQ-Loader klappen können. Also nichts von Diskette laden, sondern vielleicht 512 bytes an berechneten Daten zu c64 tranferieren.

    Naja, die Stärken der 6502-CPU liegt ja auch ganz woanders, aber nicht darin, eine 3d-Animation zu Rendern. Dafür gibt es bessere 8-Bit CPUs.

  • Weswegen hat eigentlich Prince of Persia das Easyflash benutzt? Da heist es ja auch immer das ein Disk Version nicht möglich wäre.

    Was eine Elite Version mit Sprites angeht: Das müsste ja dann zum einen die Schiffe auch noch darstellen können, wenn sie sehr nahe sind, also sehr groß und es müssten alle Rotationen im Ram liegen. Ich glaube das wäre so ohne weiteres auch nciht möglich, auch wenn der Ansatz mal was anderes wäre.

    Bitte melde dich an, um diesen Link zu sehen. Unser Maniac Mansion Remake Projekt

  • Wäre duch die schnelle Bank Schaltung dann nicht auch ein schnelles Wechseln zwischen Weltraum und Menü Teil des Games Möglich?

    Bitte melde dich an, um diesen Link zu sehen. Unser Maniac Mansion Remake Projekt

  • Aber sicher. Das Umschalten der Bänke geht praktisch in nullzeit vonstatten. Das Beste aber ist, dass es adressierbares Rom ist.

    Du kannst für jede Routine eine Bank verwenden. Z.B. die SID-Routine. Die muss dann nur noch etwas RAM zugewiesen bekommen, um Musik abzuspielen. In den Atari 2600 Zeiten war sowas völlig normal.

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

    Thx für die ausführlichen Infos. Dein Adventure werde ich mal antesten...

    Wer hat eigentlichen die gößeren programmiertechnischen Anteile bei Elite - Braben oder Bell? Oder war das einfach ungefähr 50/50?

    Warum trennten sich später ihre Wege - hatten die sich verkracht?

  • Laut Braben hatte Bell schlicht keine Lust mehr, nach Frontier-Elite 2 und auch etwas andere ideen zur umsetzung. Als dann First Encounters raus kam, soll Bell Plötzlich direkt Geld eingefordert haben.

    Jeh nachdem welches Interview man als Quelle nimmt, klingt das immer etwas anders und Bells Seite der Geschichte ist bestimmt nochmal anders, aber da dieser weniger Interviews gibt, ist die nicht so geläufig.

    Was das Bank Switching beim EF angeht, wäre das ja eine Prima möglichkeit, um 3D Basierte Games etwas umfangreicher zu machen. Klar die 3D Darstellung wird dadurch nicht beschleunigt und wird am C64 nie sehr schnell sein, aber man könnte mehr 3D Objekte benutzen und sie bei bedarf schneller reinladen und wieder raus werfen. Und halt umfangreichere Menüs wären möglich.

    Was wäre eigentlich mit 3D Sprites, also Objekte die Als Sprites in verschiedenen Ansichten wie bei Wing commander benötigt werden. Könnte man die mit einem EF schnell genug rein und raushauen um eine halbwegs flüssige bewegung damit zu erzeugen, oder müssten zwischen alle Ansichten bereits im Ram liegen um das Flüssig hin zu bekommen?

    Bitte melde dich an, um diesen Link zu sehen. Unser Maniac Mansion Remake Projekt

  • Laut Braben hatte Bell schlicht keine Lust mehr, nach Frontier-Elite 2 und auch etwas andere ideen zur umsetzung. Als dann First Encounters raus kam, soll Bell Plötzlich direkt Geld eingefordert haben.

    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.

  • Ich dachte, dass hätte mittels 2bit IRQ-Loader klappen können.

    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.

    Eventuell könnte man etwas machen, wenn man z.B. die Welt-Berechnungen kontinuierlich in der Floppy laufen ließe und mit sehr kompaktem Format ("Raumschiff X an Position Y in Ausrichtung Z") die Parameter zum C64 übertrüge, aber keine Ahnung, ob das viel brächte und ob dafür überhaupt das RAM in der Floppy ausreichte. Und schon alleine z.B. die vielen Trümmerteile, die nach einem Abschuss rumfliegen, sprengen evtl. den Datenrahmen schon wieder.

    Was eine Elite Version mit Sprites angeht: Das müsste ja dann zum einen die Schiffe auch noch darstellen können, wenn sie sehr nahe sind, also sehr groß

    Ich meinte "Sprites" im allgemeinen Sinn, nicht im VIC II-Sinn. In dem Fall also Anzeigen der Raumschiffe durch Kopieren aus dem ROM (ggf. unter Zuhilfenahme einen Blitters). Z.B. der C64DTV könnte sowas grundsätzlich.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Laut Braben hatte Bell schlicht keine Lust mehr, nach Frontier-Elite 2 und auch etwas andere ideen zur umsetzung. Als dann First Encounters raus kam, soll Bell Plötzlich direkt Geld eingefordert haben.

    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.

    Ich denke die beiden sind tatsächlich grundverschieden und irgendwann musste es mal krachen. Braben ist mehr der Geld Typ und steht auf Realistische Darstellung des Weltraums. Bell ist eher der Geschichten erzähler, der gerne etwas erschafft, das unterhaltsam ist und dafür nicht zwingend alles Physikalisch Korrekt haben muss.

    Dahingehen, musste ja Braben schnell lernen, das seine Pysicakisch Korrekte Steuerung im All, nicht wirklich zum Zocken geeignet war.

    Bitte melde dich an, um diesen Link zu sehen. Unser Maniac Mansion Remake Projekt

  • Ian Bell ist durchaus vertreten in Interviews und im Web.

    Vor allem hier:

    Bitte melde dich an, um diesen Link zu sehen.

    Ich stand eine Weile in Kontakt mit ihm.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

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

    Eventuell könnte man etwas machen, wenn man z.B. die Welt-Berechnungen kontinuierlich in der Floppy laufen ließe und mit sehr kompaktem Format ("Raumschiff X an Position Y in Ausrichtung Z") die Parameter zum C64 übertrüge, aber keine Ahnung, ob das viel brächte und ob dafür überhaupt das RAM in der Floppy ausreichte. Und schon alleine z.B. die vielen Trümmerteile, die nach einem Abschuss rumfliegen, sprengen evtl. den Datenrahmen schon wieder.

    Du, ob das sinnvoll ist, und dem Spiele einen etwas schnelleren Aufbau der 3D-Grafik verleiht, weiß ich leider auch nicht. Ich hatte gehofft, dass es hier im Forum ein Profi in Sachen,

    Paralleprozessor gesteuerte 3D Berechungen mit der 1541 gibt. Die Idee dazu hate ich, weil Ich eine sehr gute Demo mit dem Feature kenne. Da wurde die Floppy-CPU als Coprozessor genutzt.

    Natürlich zur Berechnung der 3D-Animationen.

    PS: Kennt Jemand John Carmack. Der Mann hatte Anfang der 90er 3D-Spiele progranmmiert, die es bist Dato noch nicht gab. Eine Revolution war das.

  • Ich denke die beiden sind tatsächlich grundverschieden und irgendwann musste es mal krachen. Braben ist mehr der Geld Typ und steht auf Realistische Darstellung des Weltraums. Bell ist eher der Geschichten erzähler, der gerne etwas erschafft, das unterhaltsam ist und dafür nicht zwingend alles Physikalisch Korrekt haben muss.

    Dahingehen, musste ja Braben schnell lernen, das seine Pysicakisch Korrekte Steuerung im All, nicht wirklich zum Zocken geeignet war.

    Aber ist doch ne geniale Mischung gewesen - gerade durch diese Gegensätze..

    Bitte melde dich an, um diesen Link zu sehen.

    Haha - like it's 1997 - so ähnlich sah daaamals™ meine erste Internetsite aus :D

  • Die Floppy CPU als Co Prozessor?! Was würde passieren, wenn man die Demo versucht in einer 1541U2+ zu starten?

    Bitte melde dich an, um diesen Link zu sehen. Unser Maniac Mansion Remake Projekt

  • Ich schaue mal, ob ich die Demo finde. Der Name ist mir leider entfallen. Eventuell könnte es eine Demo von Samar sein. Ich erinnere mich auch, dass die Floppy-LED die ganze

    Zeit, während der Berechnungen, aufgeregt geflackert hat. Wenn die 1541U2 2Bit IRQ-Fast/Trackloader unterstützt, läuft auch die Demo mit der Hardware.

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

  • Die Diskussion hier finde ich interessant und sie hat mich neugierig gemacht. Allerdings finde ich gerade keinen entsprechenden Hinweis.

    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?

    Ich bin für jeden entsprechenden Hinweis dankbar. :thnks: