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
.
Kennt Jemand John Carmack.
Carmack...? Carmack...? Verdoomt, keine Ahnung, wer das sein soll.
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.
) :
Das lohnt aber nicht.
) 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.
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.
