Hello, Guest the thread was called11k times and contains 179 replays

last post from Ernie76 at the

ELITE tech Diskussion

  • Ich möchte hier mal eine Diskussion zum Thema "Die Vector Grafik von ELITE" starten.

    Für mich ist und bleibt Elite eines der Spiele, die mich am meisten geprägt haben. Die Imersion durch die Vector Grafik, empfand ich damals als grandios.

    Was ich mich aber schon immer gefragt habe: Wäre das auch besser gegangen? Viele Spiele die Später am C64 erschienen und ebenfalls Vector Graphik benutzten, schienen mit Technisch besser.


    Wie empfindet ihr die Technische umsetzung von Elites Vectorgrafk, aus heutiger Sicht, und denkt ihr das eine weniger Flakernde,

    oder gar mit gefüllten Vectoren versehene Version, auf einem Standart C64 möglich wäre? ( Stichwort: Space Rogue ! )

  • Ich hatte damals die CPC Version, da hatte nix geflackert. :D


    Elite ist für mich immer noch ein Meilenstein der Spiele Entwicklung.

    Mehr zum Thema hatte ich hier verlinkt. 35 Jahre Elite

    Und M. J. hatte mal etwas über die technischen Dinge geschrieben. 3D (Spiele-)Programmierung

  • auf golem.de gibts einen artikel zu elite: https://www.golem.de/news/35-j…d-spiele-1909-143339.html


    da wird auch auf die grafik eingegangen und sonstige probleme die sie hatten. da ja insgesamt 2048 planeten im computer gespeichert sind.

    inkl. namen und auch beschreibungen. es wurde ja ursprünglich auf einem bbc micro mit 32k ram geschrieben.


    mist, oobdoo war schneller. hatte seinen link nicht angeklickt.

  • mercenary hat gute 3d gfx aber meist auch einfachere Modelle. Elite wurde halt für BBC geschrieben. Man darf aber nicht vergessen, dass eine volle 3d Bewegung dazu gehört. Diverse andere Spiele mit 3d gfx haben das nicht. Space Rogue finde ich super aber doch etwas zu langsam ab und zu.

  • Wie empfindet ihr die Technische umsetzung von Elites Vectorgrafk, aus heutiger Sicht, und denkt ihr das eine weniger Flakernde,

    oder gar mit gefüllten Vectoren versehene Version, auf einem Standart C64 möglich wäre? ( Stichwort: Space Rogue ! )

    1.) Was das Flackern anbelangt, so wurde es bereits bei der AppleII-Version stark reduziert, indem abwechselnd eine alte Linie gelöscht und eine neue gezeichnet wurde (und nicht "erst alles löschen und dann alles neumalen" wie beim C64). Dieses Verfahren hatte ich vor einiger Zeit mal in die deutsche C64-Version reingepatcht zusammen mit ein paar weiteren Änderungen.

    2.) Um Flackern vollständig zu unterbinden, benötigt man Double Buffering, d. h. zwei Bitmaps. Nur verbrauchen Bitmaps leider sehr viel Speicherplatz. Davon ist bei "Elite" aber nichts mehr übrig, denn die Programmierer hatten sich aufgrund des englischen Kassetten-orientierten Markts darauf konzentriert, einen One-Filer zu erstellen. Das ganze Spiel sollte komplett in 64 kb passen ohne nachzuladen. "Space Rogue" (und andere spätere 3d-Spiele) lädt hingegen munter nach, was beim langsamen Laufwerk durchaus länger dauern kann. Das einzige Spiel, was es in dieser Hinsicht mit "Elite" wirklich aufnehmen kann, ist "Mercenary". Übrigens: Um den Speicherverbrauch beim Double-Buffering zu verringern, verwendet "Fighter Bomber" keine echte Bitmap, sondern Zeichensatzgraphik. Das erklärt auch den schwarzen Rahmen links und rechts in der Anzeige.

    3.) Ein weiterer Unterschied im Vergleich zwischen "Space Rogue" und "Elite" besteht darin, daß bei "Space Rogue" nach dem Andocken oder bei der Benutzung des Navigationspanels völlig anderer Programmcode verwendet wird, was das Nachladen erst möglich macht. Das bedeutet aber auch, daß der Wechsel auf das Panel die aktuelle Weltraumaktion unterbricht, quasi einfriert. "Space Rogue" ist kein Echtzeitspiel. Schaltet man bei "Elite" während eines Kampfes mit einem Piraten um auf z. B. die Galaxiskarte, kann man damit rechnen, daß der Pirat einem das Raumschiff aufschlitzt, denn alle Aktionen, d. h. Bewegungsberechnungen der Objekte, laufen weiter. Damit dies möglich ist, müssen sich die entsprechenden Programmroutinen aber im Speicher befinden. Genau dies ist bei "Elite" der Fall, bei "Space Rogue" aber nicht.

    Nebenbei: Man darf sich hierbei nicht täuschen lassen. Die Routinen, um ein Raumschiff durch den Weltraum zu steuern, sind weitaus umfangreicher als die Routinen zum Malen der Linien auf dem Bildschirm. Es ist eher so, daß die Malroutinen auf einzelne mathematische Routinen des Bewegungscodes (Multiplikation/Division) zurückgreifen. Der Löwenanteil des Codes bei "Elite" (oder anderen Programmen) besteht nicht im Malen, sondern in der generellen 3d-Berechnung (K.I., Bewegungsberechnung, Kollisionserkennung etc).

    4.) Die Verwendung einer einzigen Bitmap bei "Elite" hat allerdings auch einen Vorteil: Die Objekte als auch der "Sternenstaub" (oder was auch immer die Punkte darstellen sollen) werden nacheinander gelöscht und neu gezeichnet. Das hat den Effekt, daß immer irgendwo auf dem Bildschirm sich was bewegt, was den Eindruck einer flüssigeren Bewegung erzeugt. Bei einem Double-Buffering würde man das neu gezeichnete Bild erst ganz am Ende des vollständigen Malprozesses sehen, was rein optisch wie eine geringere Framerate wirkt.

    Hinzukommt, daß beim Double Buffering die Zeichenelemente nicht so einfach gelöscht werden können. Daher ist Double Buffering in der Regel mit einem radikalen Löschen des Anzeigebereichs verbunden. Das jedoch kostet sehr viele Taktzyklen, weshalb viele Programme den Anzeigebereich möglichst klein halten, um so die Framerate ein wenig zu verbessern. Spiele mit einer großen Anzeigefläche wie "Mercenary" sind daher leider die Ausnahme.


    Gemessen an den rein theoretischen Möglichkeiten ist "Elite" nicht das schnellste Spiel, was aber auf den begrenzten Speicher zurückzuführen ist. Bei mehr Speicher könnte das Spiel noch ein wenig schneller laufen. Von daher würde ich sagen, daß bezogen auf den Umfang ihrer Rechenleistung für mich persönlich "Mercenary" und "Space Rogue" die Spiele mit der schnellsten Graphik sind, und beide habe ich in der 8 Bit-Version unzählige Male gespielt.^^


    Wenn Du wissen willst, was heutzutage an 3d-Graphik auf dem C64 möglich ist, kannst Du Dir ja mal meine kleine Demo angucken. Falls Du spezielle Fragen hast zu den in "Elite" verwendeten Algorithmen, frag einfach. Das Spiel habe ich damals[tm] analysiert, und einiges weiß ich wohl noch bzw. könnte es nachschlagen.

  • Gibt das irgendwo, damit man sich das mal ansehen kann? Evtl. auch in de 128er Version?

    Das findest Du hier irgendwo im Forum. Die 128er Version ist ja bereits eine erheblich gepatchte Version. Gerne würde ich auch diese anpassen, befürchte aber, daß es schwierig wird, da diese Version doch erheblich abweicht vom Original. U. a. wurden um Platz zu sparen mehrere Bereiche gepackt (Cockpitgraphik, Strings). Das Original enthielt noch ein paar Stellen hier und da, in die man die neuen Routinen reinpatchen konnte. Die 128er Version kenne ich dafür jedoch nicht gut genug, und leider hat der Autor dieser Version den Sourcecode nicht zur freien Einsicht ins Netz gestellt. :(

  • also die gepatchte c64 Version würde mich sehr interessieren, aber ich finde sie nicht. Kann da jemand helfe, bitte bitte!!!

    Könnte das hier sein. Neue Spielimpulse durch Turbo-CPU-Modus möglich?

  • Hab sie direkt mal auf getestet und ich finde das ohne das Flakern alles gleich viel besser aussieht!

    Schade das der Speicher bei elite schon rappel voll ist. Ein Cockpit Bild wie bei der Amiga Version, würde nochmal besser aussehen, aber da passt ja nix mehr rein.

    Ich denke die einzige Möglichkeit an Elite noch was zu verbessern wäre eine REU version, oder?

  • man könnte das auf reu umbauen und dann aufhübschen. bemerkbar macht sich das ja nur beim erstmaligen laden. die reu kopiert ja mit 1mb/sek. innerhalb des spiels würd man das nachladen nicht merken.

    leider kann man den rec nicht für grafikoperationen verwenden. wäre das möglich hätte man eine derbst schnelle grafik.

  • Ein Cockpit Bild wie bei der Amiga Version, würde nochmal besser aussehen, aber da passt ja nix mehr rein.

    Wenn man es akzeptieren würde, daß der Cockpithintergrund immer angezeigt wird, auch in den diversen Kauf- und Verkaufmenüs, wäre es möglich, da die Bitmap an den Rändern nicht verwendet wird und stets gleich bleibt. Da die Anzeige im oberen Teil jedoch HiRes ist (320x200) bestehen die üblichen Beschränkungen: 2 Farben pro 8x8-Kachel. Außerdem gibt es Schwierigkeiten mit dem unteren Teil der Anzeige, da dieser je nach Anzeigemodus umgeschaltet wird von Hires (Menü) auf Multicolour (Cockpit). Hier müßte man die Graphik so gestalten, daß sie im HiRes- als auch im Multicolourmodus stets gleich aussieht. Das bedeutet, daß man nur mit den Pixelkombinationen 00 und 11 arbeiten darf. 00 wäre stets schwarz (auch in HiRes), und 11 ließe sich dann pro 8x8 frei setzen. Ob man allerdings unter diesen Bedingungen eine ansehnliche Graphik erstellen kann, vermag nur ein echter Graphiker zu sagen.

    Hab sie direkt mal auf getestet und ich finde das ohne das Flakern alles gleich viel besser aussieht!

    Auf dem AppleII hatte ich das noch so gepatcht, daß auch die Planetenanzeige (der runde Kreis) nicht mehr flackert, da er nur dann neu gemalt wird, wenn sich Größe oder Position ändern. Dadurch wird als Nebeneffekt auch der Anflug an den Planeten schneller. ^^ Ob ich das allerdings auch schon bei der C64-Version versucht habe, weiß ich nicht mehr.

    Ich denke die einzige Möglichkeit an Elite noch was zu verbessern wäre eine REU version, oder?

    Egal ob REU, Diskettenlaufwerk, GEORam oder sonst ein Datenträger, es ergibt sich immer das gleiche Problem: Welche Teile des Codes können auf einen externen Datenträger ausgelagert werden, um neue Elemente nachladen zu können? Nehmen wir z. B. die Routine zum Malen des Sternenstaubs. Die könnte man theoretisch mit anderen Code ersetzen, wenn die Sterne nicht angezeigt werden. Doch leider ist das Programm so aufgebaut, daß die notwendigen Unterprogramme verstreut im Speicher liegen. So befinden sich z. B. die Routinen für Multiplikation und Division zusammen an einer Stelle. Da kann man diejenigen, die nur vom Sternenstaub verwendet werden, nicht einfach herausnehmen.

    Wollte man eine REU dazu verwenden, Erweiterungen am Spiel vorzunehmen, müßte man das Spiel wahrscheinlich komplett umschreiben. Der Aufwand ist allerdings so hoch, daß ich mir schon vor Jahren gesagt habe, daß man stattdessen besser ein neues Programm entwerfen sollte.