Elite - Dangerous ist ja durchweg gelungen. Da hab ich jetzt 1300 Spielstunden und steigend.
Hab das länger nicht verfolgt. Was kostet das? Ich gab gar kein bock auf Multiplayer. Single Mission?
Es gibt 185 Antworten in diesem Thema, welches 34.699 mal aufgerufen wurde. Der letzte Beitrag (
Elite - Dangerous ist ja durchweg gelungen. Da hab ich jetzt 1300 Spielstunden und steigend.
Hab das länger nicht verfolgt. Was kostet das? Ich gab gar kein bock auf Multiplayer. Single Mission?
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:
ZitatThe 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.
Elite - Dangerous ist ja durchweg gelungen. Da hab ich jetzt 1300 Spielstunden und steigend.
Hab das länger nicht verfolgt. Was kostet das? Ich gab gar kein bock auf Multiplayer. Single Mission?
Es gibt das Haupt programm und einen DLC ( Du solltest beides haben, sonst kannst du nicht auf Planeten Landen und da mit dem Buggy Thargoiden Ruinen erworschen und sowas) Preise schwanken stark, aber am besten greift man beim Steam sale zu. Singelplayer kannst du natürlich Spielen. Du Spielst dann im Selben Online universum wie die anderen Spieler, aber du begegnest ihnen nicht, kannst aber sehen, wenn die z.b. einen Planeten zuerst entdeckt haben, dann steht da der name des Spielers. Bei keinem anderen Spiel wollte bei mir dieses Typische Slite Feeling aufkommen, und ich habe fast alle gespielt. Als dann Elite Dangerous raus kam, war das wie ein Feuchter Traum in Bits und bytes.
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:
ZitatThe 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.
Mag ja sein, das jetzt gewisse Aussagen nicht exakt sind. Nur anhand dessen oder sonstiger selektiver Aussagen würde ich Bitte melde dich an, um diesen Link zu sehen. Arbeit nicht bewerten oder gar abwerten. Er hat das Dissassembly zumindest in eine Bitte melde dich an, um diesen Link zu sehen. 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?) 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.
Insgesamt hatte ich aber den Eindruck, dass er zum Schluss kam, dass das Spiel weitgehend deutlich weniger Potenzial für Optimierungen bot, als erhofft. Ich weiß nicht, ob das von ihm als Enttäuschung ausgelegt wurde oder eine respektvolle Anerkennung der ausgezeichneten Originalprogrammierung. ![]()
Als dann Elite Dangerous raus kam, war das wie ein Feuchter Traum in Bits und bytes.
Hört sich gut an. Vielleicht steige ich auch noch ein ![]()
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.)
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.).
Wunderbar! Tolle Arbeit.
Ist das auch in eine C64-Version zurückgeflossen? Ist das eventuell das, was in Bitte melde dich an, um diesen Link zu sehen. vorkam?
Echt blöd, das man nun eine Version hat die nicht mehr Flackert, dafür aber wegen der eingebauten cheats keinerlei herausforderung mehr hat.
Ich hab schon überlegt, ob man die vorinstallierten sachen, wie den Autopiloten via Action Replay raushauen kann und das game dann als Freeze Speichert, aber leider kann man ja die zubehöre nicht wieder aus dem Schiff ausbauen, so das das Action Replay eine Veeränderung finden könnte.
Blöde Idee. bringt es was wenn man das neue sagen wir mal installieren würde, danach das alte, so das die Cheats weg wären ?
So wie bei einem Software updatet. Ist halt die Frage ob dann die alten Fehler mit zurück kommen ?
Blöde Idee. bringt es was wenn man das neue sagen wir mal installieren würde, danach das alte, so das die Cheats weg wären ?
Hm, ist in etwa so wie wenn ich mir einen Teller Suppe mache und ihn dann durch ein Steak ersetze, in der Hoffnung dass ich es dann mit dem Löffel essen kann...
Im TV Bereich mache ich das so mit der Software. Gerätesoftware erneuern, aber alle Einstellungen des Kunden später zurück spielen.
Was normaler Weise nicht machbar ist.
War nur ne Idee.
... dann durch ein Steak ersetze, in der Hoffnung dass ich es dann mit dem Löffel essen kann...
NACH dem Verdauen geht das!
Demnach müsste man das Elite ohne Cheats erst spielen, dann ersetzen ![]()
Installieren? Auf einem C64 ??? ähhhhhhh
Etwas blöd ausgedrückt ![]()
Aber ich dachte man versteht was ich meine ![]()
Echt blöd, das man nun eine Version hat die nicht mehr Flackert, dafür aber wegen der eingebauten cheats keinerlei herausforderung mehr hat.
CPC Version spielen. Die hat keine Cheats und flimmtert nicht. ![]()
Echt blöd, das man nun eine Version hat die nicht mehr Flackert, dafür aber wegen der eingebauten cheats keinerlei herausforderung mehr hat.
CPC Version spielen. Die hat keine Cheats und flimmtert nicht.
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. Echt blöd das es für den 64 so ziemlich alles nur denkbare an neuer Hardware gibt, nur eine Moderne Version der SCPU scheint niemanden zu reizen.
nur eine Moderne Version der SCPU scheint niemanden zu reizen.
Wozu? Die Durchdringung wäre so gering, dass es sich garnicht lohnen würde, Software zu entwickeln.
nur eine Moderne Version der SCPU scheint niemanden zu reizen.
Wozu? Die Durchdringung wäre so gering, dass es sich garnicht lohnen würde, Software zu entwickeln.
Das hat man anfangs auch von 1541U und Mega65 gedacht und jedes Projekt fängt mal klein an. Die Nachfrage wäre sicher da, solange das ganze in einem erschwinglichem Rahmen bleibt. Derzeit liegen meine Hoffnungen ja auf dem Mega65. Wäre schön wenn es hier z.b. eine C65 Version von Elite geben könnte. Dank Projekten wie Oolite, ist Elite ja relative offen und "durchschaubar".
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:
clc
lda log_low, x
adc log_low, y
bmi highbit_gesetzt
lda log_high, x
adc log_high, y
bcc null
tax
lda anti_log_0, x
rts
null:
lda #0
rts
highbit_gesetzt:
lda log_high, x
adc log_high, y
bcc null
tax
lda anti_log_1, x; verwende zweite Anti-Log-Tabelle
rts
Alles anzeigen
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...
Echt blöd, das man nun eine Version hat die nicht mehr Flackert, dafür aber wegen der eingebauten cheats keinerlei herausforderung mehr hat.
CPC Version spielen. Die hat keine Cheats und flimmtert nicht.
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. Echt blöd das es für den 64 so ziemlich alles nur denkbare an neuer Hardware gibt, nur eine Moderne Version der SCPU scheint niemanden zu reizen.
Wo sind beim CPC gefüllte Polygone? Wenn ich mir das Bitte melde dich an, um diesen Link zu sehen. anschaue, dann ist beim CPC gerade der Planet gefüllt, aber andere Objekte haben keine wie auch immer gearteten gefüllten Polygone. Da braucht es m. E. weit mehr als einen 4 MHz Z80 (der der ja - je nach konkreter Aufgabe vielleicht übern dicken Daumen 2 mal so schnell ist). Beim MSX mit knapp 3,6 MHz siehst ähnlich aus. Wenn man mit dem BBC Micro vergleicht, der eine seine 6502 CPU mit 2 MHz taktet, spielt die Maschine auch in der Geschwindigkeitsliga und da ist man von gefüllten Polygonen auch weit entfernt.
Die Polygone kamen doch erst mit 16- und 32-Bitter (also zumindest am Amiga oder Atari ST war es so), oder?