CFT: ioquake3 1.36

Kamikaze

Kamikaze

Warrior of Sunlight
Teammitglied
Nachdem ich das Thema für Monate aus Frust habe ruhen lassen, habe ich heute alles verworfen und von vorne Angefangen. Das hier ist das Resultat.

Ich brauche Tester für ioquake3 1.36 unter FreeBSD bevor ich einen Port daraus mache. Amd64 läuft bei mir, aber i386 ist komplett ungetestet.

Bauen:
Code: 
fetch http://www.ioquake3.org/files/1.36/ioquake3-1.36.zip
fetch -o ioquake3-1.36-patchset http://bugzilla.icculus.org/attachment.cgi?id=2107
unzip ioquake3-1.36.zip
cd ioquake3-1.36
patch < ../ioquake3-1.36-patchset
gmake

Ausführen:
/usr/local/share/quake3 muss bereits mit den nötigen pak Dateien befüllt sein.
Code: 
cd build/release-freebsd-<ARCH>
./ioquake3.<ARCH> +set fs_basepath /usr/local/share/quake3/
 
Zuletzt bearbeitet:
Viel Glück mit deinem Patch. Diese Zeilen haben sie mir vor a. 2 Jahren mit der Begründung, dass es unter Linux läuft, abgelehnt:
Code: 
--- code/qcommon/vm_x86_64.c.orig	2009-08-30 20:50:41.000000000 +0200
+++ code/qcommon/vm_x86_64.c	2009-08-30 20:51:43.000000000 +0200
@@ -246,7 +246,7 @@
 #else
 #define JMPIARG \
 	emit("movq $%lu, %%rax", vm->codeBase+vm->instructionPointers[iarg]); \
-	emit("jmpq *%rax");
+	emit("jmpq *%%rax");
 #endif
Vielleicht ist man dort inzwischen ein wenig aufgeschlossener...
 
Sie haben's ja in der Zeile darüber richtig. Da sollen sie sich entscheiden, beide falsch oder beide richtig.

Ich brauche übrigens dringend einen i386 Tester. Es kann sein, dass hier noch mächtig Tweaks ins Makefile müssen, damit das baut.
 
Ich kann es leider nicht testen, da meine Intel-Karte sich bei stärkerer Beanspruchung sofort verabschiedet, bzw. der Xorg in irgendeinem drm-Wartezustand geht und ich neustarten darf…

Wenn du aber schon so großartig dabei bist, kannst du dir ja mal Xreal [1] angucken. Sollte ich in ferner Zukunft wieder zocken können, werde ich sicher Lust genau darauf haben :)

[1] http://xreal-project.net/
 
Also bauen tuts hier unter i386 nicht, log habe ich angehangen.

(habe leider keine Zeit genauere Tests zu machen, aber vielleicht hilfts ja)

PS: Können wir eigentlich mal die Dateityp-Sperre aufheben? Ist ja ohnehin sehr Security-by-Obscurity und kostest jedes Mal einen Nerv die Dinger in .txt umzunennen...
 

Anhänge

  • build_log.txt
    31,3 KB · Aufrufe: 235
audio/openal ist jetzt obligatorisch. Kannst du das nachinstallieren und es nochmal versuchen. Desweiteren gibt es glaube ich keine neuen Abhängigkeiten.

Danke für den Test, übrigens. Der Ausgabe kann ich zumindest schon entnehmen, dass ich wohl keine murksige arch-umbenennerei wie für amd64 vornehmen muss.
 
shmctl ist ein Befehl um shared-memory Segmente zu verändern. Anscheinend ist libSDL gegen eine veraltete FreeBSD-Version gelinkt.
 
XReal hatte ich vor längerer Zeit mal am Laufen, aber ohne nVidia-Blob kann man das im Moment leider knicken. Die freien Treiber sind dem nicht gewachsen. Baute recht straight forward durch, wenn man den Radiant (den Editor) rausnimmt.
 
OT: schade dass es insgesamt von den Radeon(HD)-Entwicklern so wenig Infos gibt. Woran liegt der langsame Fortschritt? Ist es mangelnder Support von AMD, eigene Unfähigkeit oder Grundproblem im XServer?

Ich meine der (es ist doch nur einer, oder?) Radeon-Entwickler hat es seiner zeit geschafft funktionierende Treiber für die r300-Generation zu schreiben ohne Doku zu haben. Wie kann es da sein, dass eine Team aus Vollzeitbeschäftigten mit Doku immernoch nicht ansatzweise aktuelle Grafikkarten unterstützen kann...
 
Also gut, radeonhd mal kurz zusammengefasst: Grundsätzlich gibt es zwei Treiber für die ATi-Karten, wie sicher bekannt ist. Der ältere xf86-video-ati ("radeon") und den neueren xf86-video-radeonhd ("radeonhd"). Nachdem man zuerst gegeneinander gearbeitet hatte, arbeitet man nun miteinander. Vor dem Hintergrund wurde radeon grundsaniert. Die Idee ist inzwischen, dass radeonhd mehr oder weniger inoffziell in radeon aufgehen soll. Ob und wann das passiert, ist eine völlig andere Frage, die eh erst interessant wird, wenn radeon die neue Hauptversion herausbringt. Aber beide Treiber sind in wesentlichenteilen fertig. Sie können 2D-Beschleunigung per EXA, sie können XVideo, sie können 3D-Beschleunigung. Das einzige, was beiden Treibern noch fehlt, ist Powermanagement. Für R100 bis R500 funktioniert es, für R600 bis zum kommenden R800 nur sehr eingeschränkt. ATi ist da auch recht knauserig mit Doku, allerdings ist die vorhandene noch nicht vollständig implementiert. Wann das passiert kann man nicht sagen, denn der entsprechende Code wird von SuSE-Entwicklern im Auftrag von Novell geschrieben, die allerdings auch noch an diversen anderen Teilen der Distribution basteln. Oder anders gesagt ist die Zeit dort begrenzt.

Das eigentliche Problem, worauf wir seit Monaten warten, sind also gar nicht die Treiber. Die können längst 3D. Es scheitert an zwei Dingen. Dort ist einmal DRM, also der Kram im Kernel. Die aktuelle Version kann für den R600 bis R800 nur eingeschränkte Beschleunigung, ausreichend für EXA und XVideo. Den Code für 3D-Beschleunigung hat Robert Noland vor wenigen tagen in FreeBSD -CURRENT commitet, er wird aber kein Teil von 8.0 werden. Wenn Interesse besteht, habe ich einen Patch für 7.2 und 8.0. Also ist DRM nun auch aus dem Spiel.

Bleibt der dritte im Bunde, Mesa3D. Mesa - besser bekannt als libGL - ist eine OpenGL-Implementierung, die in Software und per DRM in hardware rendern kann. Mesa untestützt zur Zeit in der aktuellen Version 7.5 die R600 bis R800 nur extem rudimentär. Damit ist kein nutzbares 3D möglich. In den Ports ist sogar noch Version 7.4, das wird sich wohl erst nach 8.0 ändern. Neue Mesa-Versionen sind meist recht destruktiv. Die Entwicklerversion kann bereits für diese Karten 3D. Es ist noch recht langsam, aber es geht und reicht für Quake III. Entwickelt wird es von AMD und Red Hat. Motivierte Frickler können sich also Mesa3D aus dem Git ziehen, ein -CURRENT nehmen und sich über echtes 3D auf ihrer neueren ATi-Karte freuen. Mit Mesa3D, was im Herbst bis Winter kommen soll, werden dann alle jemals gebauten ATi-Karten inklusive allen neu kaufbaren, freie 3D-Beschleunigung haben.

Das große Problem ist jetzt aber, dass OpenGL im Moment bei Version 3.2 ist. Mesa3D unterstüzt maximal Version 2.1. Das ist an sich noch kein Beinbruch. Nun kann aber kein DRM-Modul, welches für die 3D-Beschleunigung benötigt wird, dies. Allen fehlt mindestens GLSL, die Unterstützung für Shader. Diese benötigen aber praktisch alle Spiele, die neuer als Quake III sind. Sprich: Keine Shader in Hardware -> Müssen in Software gerendert werden -> Doom 3 und co. sind unspielbar. Auch an GLSL arbeitet man aktiv, aber ob es mit 7.6 kommt, kann keiner sagen.

Einmal von all dem abgesehen, gibt es noch Galium, welches im Moment in Mesa3D integriert wird. Gallium ist ein neuer Renderstack, der plattformunabhängig ist. Sprich, der gleiche Treiber würde auf Windows, OS X, Linux, FreeBSD und vielem mehr laufen. Die Idee ist, dass man vielleicht Hersteller dazu bringen kann, so mehr und vor allem höherwertige Blobs zu bauen. Es hat noch mehr Vorteile, wie 3D-Beschleunigung in virtuellen Maschinen ohne hacks und weiteres. Aber Gallium hat noch keine Treiber, aus einem für den Cell-Prozessor und einem für die alte Intel i915. Ein Radeon-Treiber ist in Planung. Aber Gallium wird kaum vor 2011 für den Endnutzer kommen.

So, das ist grob der aktuelle Stand der Radeon-Front.
 
Zu nVidia gibt es nichts neues. Nouveau macht Fortschritte, sieht sich selbst aber eher als 2D-Treiber, der anders als der freie xf86-video-nv auch nutzbar funktioniert. Das Ding ist auf aktuellen Karten ein besserer Witz, kaum schneller als Vesa. Ein Blob für FreeBSD/amd64 ist bekanntlich das Ziel vieler Spekulationen und Gerüchte. Halten wir uns mal an die Fakten, gibt es nicht viel. Einmal ein paar Commits in FreeBSD, "submitted by czander at nvidia dot com". Sie betreffen ausschließlich FreeBSD/amd64. Außerdem gibt es von Christian Zander diese Aussage:
For those of you monitoring this thread in the hopes of receiving status updates: Alan Cox very recently committed a set of supporting changes to HEAD (see http://svn.freebsd.org/viewvc/base?v...evision=195649). John plans on updating his branch over the next few days. I'll probably have to resolve the pending driver updates against a current snapshot at that point, retest and debug any problems (as time permits). So while it will likely still be a while before there is a FreeBSD snapshot/release and BETA driver for you to test, progress is still being made.
Zum Vergrößern anklicken....
Oder anders gesagt, im Westen nichts Neues. Vielleicht kommt eines Tages ein Blob, vielleicht nicht, bis dahin ist ATi erste Wahl.
 
Ich habe den Patch für den Port noch mal aktualisiert, da hat sich ein kleiner Fehler eingeschlichen.
 
Rückeroberung

Es ist Zeit das Thread-Thema wieder in den Vordergrund zu rücken:
Kamikaze schrieb:
So, hier ist erst mal das vorläufige diff für den Port games/ioquake3:
http://www.home.hs-karlsruhe.de/~fado0011/patch-ports-games-ioquake3.diff

Das shar für ioquake3-devel setzt obigen Patch voraus:
http://www.home.hs-karlsruhe.de/~fado0011/shar-ports-games-ioquake3-devel.sh
Zum Vergrößern anklicken....

Ich benötige mindestens eine i386 Erfolgsmeldung bevor ich das submitten kann. Das muss doch machbar sein.
 
8.0/i386

Code: 
gmake[2]: Entering directory `/home/uqs/ports/ioquake3/work/ioquake3-1.36'
DED_CC code/server/sv_bot.c
DED_CC code/server/sv_client.c
DED_CC code/server/sv_ccmds.c
DED_CC code/server/sv_game.c
DED_CC code/server/sv_init.c
DED_CC code/server/sv_main.c
DED_CC code/server/sv_net_chan.c
DED_CC code/server/sv_snapshot.c
DED_CC code/server/sv_world.c
DED_CC code/qcommon/cm_load.c
DED_CC code/qcommon/cm_patch.c
DED_CC code/qcommon/cm_polylib.c
DED_CC code/qcommon/cm_test.c
DED_CC code/qcommon/cm_trace.c
DED_CC code/qcommon/cmd.c
DED_CC code/qcommon/common.c
code/qcommon/common.c: In function 'Com_Init':
code/qcommon/common.c:2514: error: expected ')' before 'PRODUCT_VERSION'
code/qcommon/common.c:2627: error: expected ')' before 'PRODUCT_VERSION'
gmake[2]: *** [build/release-freebsd-/ded/common.o] Error 1
gmake[2]: Leaving directory `/home/uqs/ports/ioquake3/work/ioquake3-1.36'
gmake[1]: *** [targets] Error 2
gmake[1]: Leaving directory `/home/uqs/ports/ioquake3/work/ioquake3-1.36'
gmake: *** [release] Error 2
*** Error code 1
 
da meine Intel-Karte sich bei stärkerer Beanspruchung sofort verabschiedet, bzw. der Xorg in irgendeinem drm-Wartezustand geht und ich neustarten darf…
Zum Vergrößern anklicken....

Soul Rebel, das Problem hab ich auch. Aber mit einer ATI Radeon Karte 9250 und DRM. Sobald ich was zocke und z.B viele Texturen abgebildet werden oder Explosionen etc. hängt sich die Karte auf und ich bekommen einen schwarzen Bildschirm und kann die Kiste nur noch neu starten.

Bei meiner NVIDIA Karte und closed source Treiber hatte ich nie Probleme mit sowas. Ich werd wohl wieder meine alte Geforce einbauen. DRM hat mich nicht wirklich überzeugt
 
Bei mir reicht da schon der KDE-Screensaver :S
Das Compositing-Zeugs funktioniert komischerweise inzwiscen relativ stabil...
Früher hat ich solche Probleme mit Intel auch nicht.
 
Ich habe diff und shar noch mal aktualisiert. Damit sollten die i386-Probleme (sofern ich sie richtig erraten habe) gegessen sein.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben