PATCH: Doom 3 unter FreeBSD

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
So, nach nur wenigen Stunden Arbeit - die meiste Zeit ging für das Einarbeiten in scons drauf - habe ich meinen "Doom 3 unter FreeBSD"-Patch fertig: https://bugzilla.icculus.org/show_bug.cgi?id=5292

Einschränkungen:
- Derzeit nur FreeBSD/i386, da Doom 3 (noch) nicht 64 Bit clean ist.
- Braucht lang/gcc46.
- Hat noch Abhängigkeiten auf /proc. Sie schaden nicht, es funktioniert auch so. Ich werde sie aber dennoch entfernen, da ich das Wochenende über nicht zu Hause bin aber erst nächste Woche.

Viel Spaß damit :)
 
So, ich habe mal einen Blob hochgeladen:

1. Doom 3 für Linux normal installieren
2. "rm base/game*.pk4 doom.x86"
3. "fetch http://deponie.yamagi.org/doom3/doom3-freebsd-v2.tar.xz"
4. "tar xf doom3-freebsd-v2.tar.xz"
5. "mv game00.pk4 base/"

Wer unter FreeBSD/amd64 ist, muss noch die Libs bekannt machen:
6. "setenv LD_32_LIBRARY_PATH ./libs"

Danach kann man es starten:
7. "./doom.x86"

Anmerkungen:
- Unter FreeSBD/amd64 muss /usr/lib32 vorhanden sein.
- Es funktioniert natürlich nur mit dem nvidia-blob.
- Das Binary lädt Savegames von Windows und Linux.
- Es ist ein Debug-Build, daher sind die Binaries recht groß.
- "Depth pass" statt des patentierten "Depth fail" zur Schattenberechnung kostet ggü. dem originalem Linux-Binaries etwas Leistung.
 
Ich habe keine Graka, die Doom3 unter FreeBSD kann. Aber ich würde deinen Patch gerne bei iodoom3 abliefern.

EDIT:
Oh, du hast es schon bei icculus abgeliefert ... großartig!
 
Ich würde mit dem Bauen eines Ports aber warten, bis das iodoom3-Projekt Fahrt aufgenommen hat. Als eines der ersten Dinge soll dort das Build-System von scons auf cmake gewechselt werden...
 
So, ich habe einmal die Auswirkungen der Schattenalgorithmen gemessen.

Code: 
Core i7 2400k:
Patent-Workaround: 193FPS
Carmacks Reverse:  196FPS

K7 Sempron 1600MHz:
Patent-Workaround: 17FPS
Carmacks Reverse:  34FPS

Die Schattenberechnung wird umso mehr eine Bremse, je langsamer der Prozessor ist. Ob es sich aber lohnt, diversen Ärger zu riskieren, nur damit einige alte Kisten schneller laufen, bezweifele ich sehr. Die können dann auch gern das Original-Binary nehmen und alleinstehende Spiele wie "The Dark Mod" oder vielleicht irgendwann auch "Phobos" haben eh deutlich höhere Anforderungen. Vor allem aber könnte man durch einen Wechsel auf OpenGL 2.x (derzeit 1.4) die Schatten trivial zumindest teilweise auf der GPU berechnen und die Sache weitaus mehr beschleunigen, als es jeder noch so tolle CPU-Algo kann...
 
Naja außerhalb der USA ist es ja kein Problem. Mich nervt sowas einfach. Patente auf Algorithmen? Was wollen diese Trolle jetzt noch wo ihr ach so toller Algorithmus entbehrlich ist? Würde man mit OpenGL 2.x nicht alle freien bis zum jüngsten Tag ausschließen oder läuft es eh nur mit Nvidia Blob?
 
Derzeit läuft Doom 3 nur mit dem Blob. Zumindest unter FreeBSD wird der Versuch Mesa3D zu nutzen mit einem netten "Segmentation Fault" quitiert. Das mag unter Linux mit neueren Versionen der Mesa-libGL anders sein. Aber man muss es mal so sehen: OpenGL 2.0 wurde im September 2004 veröffentlicht. Das ist nun 7 Jahre her! Wenn die freien Treiber es bisher nicht ausreichend können - sie können ja nicht einmal OpenGL 1.x vollständig fehlerfrei - wie lange soll man dann noch warten? Aktuell ist schließlich OpenGL 4.2. Das hat aber noch zu geringen Hardwareunterbau, nur wenige Karten können es.
 
Ich habe deinen Patch mal getestet. Kam ich vorher gar nicht erst in das Spiel, so komme ich jetzt zumindest in das Menü, kann Einstellungen usw. vornehmen. Sobald ich aber ein neues Spiel starten möchte und einen Schwierigkeitsgrad ausgesucht habe und das Spiel eigentlich laden sollte, hängt sich der komplette Computer auf.

Ich nutze eine ATI Radeon 2600XT mit dem radeon Treiber. Die 3D-Unterstützung läuft. Ob das abschmieren nun durch einen Segmentation Fault verursacht wird, kann ich nicht sagen, aber normalerweise würde sich der Computer nicht komplett aufhängen, oder?
 
Nein. normalerweise sollte nur Doom 3 an sich abschmieren. Wenn der ganze Rechner stirbt, ist das ein sehr deutliches Zeichen dafür, dass der Grafiktreiber den Kernel in den Tod reißt...
 
So, ein Update: Nachdem es nicht danach ausschaut, dass ioDoom3 noch etwas werden würde, ist nun dhewm3[1] der Weg zu gehen. Der Port läuft ohne weitere Probleme unter FreeBSD und ist vollständig 64-Bit clean. Außerdem bringt er eine Reihe Verbesserungen, wie zum Beispiel die durchgehende Verwendung von OpenAL für den Sound, SDL für die Backends und so weiter. Falls noch jemand interessant an einem Doom3-Port hat (ich nicht, da ich Spiele grundsätzlich manuell in einzelne Verzeichnisse installiere) würde ich stark empfehlen auf dhewm3 zu setzen.

1: https://github.com/dhewm/dhewm3
 
Noted. Wird wohl Zeit, dass ich mir das Spiel zulege. Aber ich habe nicht die Hardware um es ordentlich zu betreiben.

Also die Hardware ist schon da, aber nicht mit FreeBSD Treibern.

Ich habe übrigens dank eines Typs namens Matt an rtcw gemacht. Der hat mir ein fast funktionierendes .tar.gz mit einem modifizierten https://gitorious.org/rtcw/rtcw geschickt. Ich habe mir dann seine Änderungen angesehen, die Hände überm Kopf zusammengeschlagen (das war offensichtlich das erste mal, dass er an idTech3 arbeitet). Denn er hat an allen Ecken und Enden Code gepatcht wo es gereicht hätte an einer Stelle das korrekte Define für FreeBSD zu machen.

Zu seiner Verteidigung muss ich sagen, dass ich den Aufbau des Codes (Doku? Welche Doku?) auch erst nach Monaten begriffen hatte.

Jedenfalls habe ich alles nochmal ordentlich gefixt: https://gitorious.org/rtcw/rtcw-freebsd

Jetzt gibt es da aber ein SVN von dem https://gitorious.org/rtcw/rtcw geforkt ist. SVN und Mercurial (was ich verwende) spielen nicht schön miteinander. Aber in dem SVN sind inzwischen eine Menge Probleme gefixt, die ich auch im gitorious Fork nachvollziehen kann. Original und Fork werden zum Überschuss noch aktiv entwickelt. Das Original (http://code.google.com/p/bzzwolfsp/) zielt auf Single Player Coop ab und der Fork auf 64bit kompatibilität.

Wenn ich also Tobias Dörffel nicht dazu überreden kann die Änderungen vom SVN zu übernehmen muss ich das selbst zusammenführen.
 
Zuletzt bearbeitet:
Danke, das teste ich morgen mal auf FreeBSD :)

RTCW ist doch auch wieder so eine Source-Katastrophe. Das Spiel ist irgendein ganz kranker Hybris aus der id Tech 3, dem Teile des wirklich extrem kaputten Quake II Single Player Game Code untergeührt wurden, dass alles irgendwie noch 2x umgestrickt und fertig. Ich hatte damals nur ein wenig drin gelesen und mich dann entschieden, dass Feld besser jemand anderem zu überlassen.
 
Ich grab die Threadleiche hier mal aus....ich hab gar keine Ahnung vom source compilen und wollte mich mal an darkmod rantrauen.

Erste Fehlermeldung...gcc fehlt. Also gcc draufgeschmissen.

Code: 
$ scons BUILD="release" TARGET_ARCH="x64" -j4
scons: Reading SConscript files ...
Loading build configuration from site.conf:
  JOBS='1'
  SILENT='0'
  CC='gcc'
  NOCURL='0'
  GL_HARDLINK='0'
  BUILD_ROOT='build'
  CXX='g++'
  ID_MCHECK='2'
  TARGET_ARCH='x64'
  LIBC_MALLOC='1'
  OPENMP='0'
  DEBUG_MEMORY='0'
  NO_GCH='0'
  BASEFLAGS=''
  BUILD='release'
Command line: BUILD='release'
Command line: TARGET_ARCH='x64'
Inserted SVN revision number into svnversion.h
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build/scons_x64/release/core/glimp build/scons_x64/release/core
g++ -o build/scons_x64/release/core/TypeInfo/TypeInfoGen.o -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -std=c++11 -fno-strict-aliasing -fvisibility=hidden -m64 -g -O3 -ffast-math -fno-unsafe-math-optimizations -DXTHREADS -Ibuild/scons_x64/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/libjpeg -Iinclude/libpng -Iinclude/devil -Iinclude/ffmpeg -I. -Iidlib -Iframework -Igame TypeInfo/TypeInfoGen.cpp
g++ -o build/scons_x64/release/core/cm/CollisionModel_contacts.o -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -std=c++11 -fno-strict-aliasing -fvisibility=hidden -m64 -g -O3 -ffast-math -fno-unsafe-math-optimizations -DXTHREADS -Ibuild/scons_x64/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/libjpeg -Iinclude/libpng -Iinclude/devil -Iinclude/ffmpeg -I. -Iidlib -Iframework -Igame cm/CollisionModel_contacts.cpp
g++ -o build/scons_x64/release/core/cm/CollisionModel_contents.o -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -std=c++11 -fno-strict-aliasing -fvisibility=hidden -m64 -g -O3 -ffast-math -fno-unsafe-math-optimizations -DXTHREADS -Ibuild/scons_x64/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/libjpeg -Iinclude/libpng -Iinclude/devil -Iinclude/ffmpeg -I. -Iidlib -Iframework -Igame cm/CollisionModel_contents.cpp
g++ -o build/scons_x64/release/core/cm/CollisionModel_debug.o -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -std=c++11 -fno-strict-aliasing -fvisibility=hidden -m64 -g -O3 -ffast-math -fno-unsafe-math-optimizations -DXTHREADS -Ibuild/scons_x64/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/libjpeg -Iinclude/libpng -Iinclude/devil -Iinclude/ffmpeg -I. -Iidlib -Iframework -Igame cm/CollisionModel_debug.cpp
In file included from TypeInfo/../idlib/precompiled.h:130:0,
                 from TypeInfo/TypeInfoGen.cpp:15:
TypeInfo/../idlib/../renderer/qgl.h:43:16: fatal error: gl.h: No such file or directory
 #include <gl.h>
                ^
compilation terminated.
scons: *** [build/scons_x64/release/core/TypeInfo/TypeInfoGen.o] Error 1
In file included from idlib/precompiled.h:130:0,
                 from cm/CollisionModel_contacts.cpp:24:
idlib/../renderer/qgl.h:43:16: fatal error: gl.h: No such file or directory
 #include <gl.h>
                ^
compilation terminated.
scons: *** [build/scons_x64/release/core/cm/CollisionModel_contacts.o] Error 1
In file included from idlib/precompiled.h:130:0,
                 from cm/CollisionModel_contents.cpp:24:
idlib/../renderer/qgl.h:43:16: fatal error: gl.h: No such file or directory
 #include <gl.h>
                ^
compilation terminated.
scons: *** [build/scons_x64/release/core/cm/CollisionModel_contents.o] Error 1
In file included from idlib/precompiled.h:130:0,
                 from cm/CollisionModel_debug.cpp:24:
idlib/../renderer/qgl.h:43:16: fatal error: gl.h: No such file or directory
 #include <gl.h>
                ^
compilation terminated.
scons: *** [build/scons_x64/release/core/cm/CollisionModel_debug.o] Error 1
scons: building terminated because of errors.

Mhhhm... mesa ist installiert. :confused:
 
mr44er schrieb:
Ich grab die Threadleiche hier mal aus....ich hab gar keine Ahnung vom source compilen und wollte mich mal an darkmod rantrauen.
Zum Vergrößern anklicken....
Ich empfehle dir, besser dhewm3 zu nutzen, um Doom 3 unter FreeBSD zu spielen. Zum Kompilieren brauchst du nur SDL, OpenAL, CMake, und GNU make. Dann einfach:
Code: 
$ mkdir build/
$ cd build/
$ cmake ..
$ gmake
Siehe auch folgende Anleitung.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben