Daikatana 1.3 Pre-Beta (inkl. FreeBSD-Support)

Yamagi

Possessed With Psi Powers
Teammitglied
Hallo,
das Daiktana 1.3 Team ist stolz eine frühe Pre-Beta des kommenden Daiktana 1.3 zu veröffentlichen: http://www.quake.de/phpBB2/viewtopic.php?t=12022 Bitte nimmt den Hinweis ernst, dass es sich wirklich um eine sehr frühe Version handelt und noch keine Ankündigung ist! Dennoch läuft es bereits deutlich(!) stabiler und fehlerfreier als das legendär kaputte Originalspiel. Es macht sogar Spaß :)

Daikatana ist und bleibt Closed Source, es werden also keine Sourcen veröffentlicht werden. Die FreeBSD-Binaries sind unter FreeBSD 9.2 gebaut worden, laufen jedoch mit misc/compat9x auch auf 10.0. Bitte beachtet außerdem, dass Daikatana kein 64-Bit unterstützt. Es sind daher 32-Bit Binaries! Man kann sie mittels eines 32-Bit chroot auf einem 64-Bit Host nutzen. Allerdings nur mit dem Nvidia-Treiber, da FreeBSDs DRM kein "Mixed Mode" unterstützt.
 
Cool. Wie hoch ist denn die Wahrscheinlichkeit, dass noch eine 64-bit-Version erscheint? Und wer steckt hinter der Entwicklung?
 
Eine 64-Bit Version wird es mit an Sicherheit grenzender Wahrscheinlichkeit (nun klinge ich wie ein Politiker) nicht geben. Die dafür notwendigen Mengen an Jungfrauenblut gibt es auf dieser Welt nicht.
 
Ich seh’ gerade, dass die Frage nach dem Entwickler-Team bereits durch den Forenbeitrag auf quake.de beantwortet wird (wer lesen kann, …). Daher noch eine dumme Frage: wenn Daikatana Closed-Source ist, wie kann es dann eine FreeBSD-Portierung geben?
 
Mit SDL2 sind Portierungen auf FreeBSD (und sehr wahrscheinlich auch andere BSDs) sehr simpel. Oft reicht ein simples Neubauen aus.
 
Cool, da fliegt hier sogar noch irgendwo die CD rum und ich hatte es nie durchgezockt :) Allerdings wird mein Setup (AMD) nicht unterstützt :'(

Ist das mit dem "kein mixed mode unter FreeBSD" noch aktuell? Es gab doch mal reports dass mixedmode auch mit Intel KMS geht, wenn ich mich richtig erinnere.
 
Eine 64-Bit Version wird es mit an Sicherheit grenzender Wahrscheinlichkeit (nun klinge ich wie ein Politiker) nicht geben. Die dafür notwendigen Mengen an Jungfrauenblut gibt es auf dieser Welt nicht.
Wenn das mit SDL2 alles so reibungslos läuft, warum gibt es mit amd64 Probleme? Ich kann mir gerade nicht vorstellen, wo so ein Spiel tatsächlich so CPU-spezifischen Code hat. Dachte immer dass es halt Platform und Engine spezifisches gibt und dann natürlich das Buildsystem und so... aber wenn es schon auf FreeBSD-32Bit läuft, wo sind die Probleme mit FreeBSD-64Bit oder Linux-64Bit?
 
Nun, man munkelt, dass der Daikatana source nicht der Beste, wenig bis gar
nicht 64Bit-safe ist und zu alle dem auch noch 32Bit Strukturen auf Platte
speichert. Ich vermute, dass alles in allem der Aufwand recht hoch wäre und man
bei so einem kleinen Team lieber das Augenmerk auf eine stabile 32Bit Version legt.
 
Das bezweifele ich :) Der Source Code von Quake II wurde am 21.12.2001 unter der GPL2 freigegeben. Seitdem wurde sehr viel an Quake II gehackt. Einige der Hobby-Entwickler waren fähig, der Großteil aber nicht. Es sind über die Jahre diverse Clients auf Basis des Codes entstanden, aber auch nach so langer Zeit ist meiner der einzige Client mit vollständiger und nicht nur einer variablen Menge von "teilweiser" 64-Bit Unterstützung. Den 64-Bit Port habe ich ganz allein gebaut, es gab nicht mal ansatzweise Hilfe. Selbst im Jahr 2014 bekomme ich noch regelmäßig Patches zugeschickt, deren Source eindeutig nicht 64-Bit kompatible Konstrukte enthält. Noch krasser ist es bei neueren und deutlich komplexeren Spielen, die auf C++ statt C aufsetzen. Um RTCW, Doom3, Doom3BFG und noch einigen mehr hat sich erst gar keine wirkliche Community gebildet. Es waren und sind immer nur einzelne Personen, die daran hacken und aufgrund des Umfang der Sourcen auf verlorenem Posten stehen. Entsprechend sind die meisten Bemühungen dort wieder eingeschlafen. Ehrlich gesagt wüsste ich nicht, wieso es bei Daikatana anders sein sollte. Ich fände es gut, wenn Daikatana offen gelegt werden würde. Aber Hoffnungen auf Verbesserungen, die über kleine Bugfixes hinausgehen, würde ich mir da nicht machen. Aber da es keinen offenen Code geben wird, ist die Debatte sowieso überflüssig.
 
Ja, gerade die Engines von idSoftware sind alles andere als schön geschrieben. Die Leute haben halt ständig die "alte" Engine aufgemöbelt, umgeschrieben, andere haben noch einen Zusatz reingehackt... dann wurde Multithreading eingebaut, dann wieder ausgebaut, das tut weh beim Code lesen xD
 
Und nach dem Buch "Masters of Doom" (sehr zu empfehlen!) erst ab Quake 3 überhaupt ein VCS genutzt.
 
Mir war klar, dass es nicht viele Leute gibt, welche an den Quake 2/3 Code rumschreiben aber das es nur Einzelpersonen sind, verwundert mich jetzt schon ein bisschen...

Ich war halt immer ein "Unreal" Kind und habe nicht mal ein Quake 2, um deine Sourcen mal zu testen ;)
 
Ich hatte mich mal, nach Veröffentlichung des Codes, in RtCW eingearbeitet. Naja, nicht so richtig eingearbeitet, aber halt versucht das Ganze mal zu verstehen. Dass das Ganze in verschiedene Bibliotheken aufgeteilt wird, es aber ein riesiger Codeblock ist, der per Makro-Hexerei aufgespalten wird, dann ist das nur noch schlimmer.

Im Endeffekt habe ich es dann aber auch wieder verworfen. Die Engine ist alles andere als zukunftsfähig gewesen und hatte ganz andere Voraussetzungen im Hinterkopf, als das was heute gilt.
 
Ich hatte mich mal, nach Veröffentlichung des Codes, in RtCW eingearbeitet. Naja, nicht so richtig eingearbeitet, aber halt versucht das Ganze mal zu verstehen. Dass das Ganze in verschiedene Bibliotheken aufgeteilt wird, es aber ein riesiger Codeblock ist, der per Makro-Hexerei aufgespalten wird, dann ist das nur noch schlimmer.

Im Endeffekt habe ich es dann aber auch wieder verworfen. Die Engine ist alles andere als zukunftsfähig gewesen und hatte ganz andere Voraussetzungen im Hinterkopf, als das was heute gilt.
Aber eigentlich schade. RTCW konnte man damals mit ner einfachen GeForce Grafikkarte in für damalige Zeiten guter Grafik spielen.
 
Die gute Grafik lag aber hauptsächlich am guten Content. Die Texturen waren halt hoch aufgelöst und es standen halt viele (statische) Objekte überall rum. Die Quake Engine krankt halt so ziemlich an allem dynamischen, war dafür aber eine ziemliche Polygonpumpe. Selbst das Skelett-Animationsystem wurde halt erst mit RtCW eingebaut, das hatte die Engine vorher nicht.

Aber eine Engine für heutige Systeme muss man ganz anders aufbauen. Ohne GPGPU und exzessives Multithreading, kommt man heute keinen Meter mehr weit, wenn man was anständiges auf den Bildschirm kriegen will. Wenn man da als Grundlage Engines von 199x nimmt, hat man einfach verloren. Darum spielen idTech-Engines heute auch kaum noch eine Rolle, damals waren sie marktbeherrschend.
 
Man muss halt sehen, dass es eine andere Zeit war. Quake war technisch gesehen revolutionär. Es war der praktisch erbrachte Beweis, dass man eine vergleichsweise detaillierte Welt in echtem 3D in Echtzeit rendern kann. Auf damals zugegeben absoluter High-End Hardware, aber eben auch nicht auf einer sündteuren Workstation von SGI oder ähnlichem. Quake ebnete damit einer ganzen Reihe technisch ähnlich aufgebauter Spiele in den folgenden Jahren der Weg. Aber Quake war auch als reiner Softrenderer konstruiert worden, schließlich gab es noch keine auf dem Massenmarkt verfügbaren 3D-Beschleuniger zum Hardware-Rendern. Und auch wenn später GLQuake kam, Quake 2 mit OpenGL-Renderer ab Werk und Quake 3 komplett ohne Softrenderer, die zugrundeliegende Technik blieb über alle Generationen hinweg gleich und auf CPUs ausgerichtet. Im Prinzip ist es selbst Doom3 noch, wobei da wirklich nicht mehr viel Quake drinsteckt... Eine "Engine lizensieren" hieß damals einfach, dass man den Quellcode von Quake bekam und fertig. Kein sauberes SDK, keine vernünftigen Tools und so weiter. Da id all das nie geboten hat und ihre Technik zudem sehr auf die eigenen Spiele zentriert entwickelten, wurden sie halt von anderen Anbietern erst überholt und schließlich aus dem Markt gedrängt. Das ging ja soweit, dass in der letzten Phase viele Quake III basierten Spiele zusätzlich zur Engine selbst auf Rituals Ubertools aufsetzten, die so eine Art SDK darstellten.

Das mit guten Content kann ich nur unterschreiben. Man sieht sogar im Vergleich der Quake-Derivate untereinander. Während die erste Liga (id Software selbst, sowie einige für die damalige Zeit aufwändige Produktionen wie RTCW oder FAKK2) heute trotz der Tatsache technisch mehr als nur überholt zu sein noch immer gut aussieht, sieht es schon in der zweiten Liga eher günstigeren Produktionen wie SoF oder Heretic II ganz anders aus. Die sind zumindest in meinen Augen einfach hässlich, kranken an schlechten Animationen, lieblosen Leveldesign und zu niedrig aufgelösten Texturen. Das fasst auch recht gut das aus heutiger Sicht hauptsächliche Problem von Daikatana gut zusammen. Es war verbuggt, die Level fehlerhaft und so weiter. Aber damit hätte man leben können, wenn es nicht durch miese Texturierung und verpfuschte Level einfach mieserabel gewesen wäre. Und das sind halt Probleme, die man durch rumfummeln am Code prinzipbedingt nicht rausbekommt.
 
Ja, das hat der Markt ja dann von selbst geregelt. idTech4 und idTech5 waren zwar in ihrer Zeit schon recht innovativ in den Ansätzen, aber halt vollkommen am Markt vorbei entwickelt. Sie wurden dann kurzerhand vom ewigen Konkurrenten Epic und frischen Startups (á la Crytek) einfach geplättet.
 
Zurück
Oben