doom3, quake4 won't start

[alex.blackbit]

Hi,

I am posting here, because the ebuilds are masked.
since I got a new graphics adapter with non-broken 3D I thought I'd try again to play a game.
Both doom3 and quake4 fail on me.
quake4 says: "Fatal Error: Texture compression unavailable", doom3 is quite silent.
detailed output below.
ut2004 works as expected.
I am using the radeon driver with a HD6850.
For details please see this post.
Is there anything I can do?
Any hints welcome.
Thanks in advance.

EDIT:
doom3 also says: X..GL_EXT_texture_compression_s3tc not found
bizarrely this worked with some older radeon driver years back.
Is this again a problem with outdated mesa libs in app-emulation/emul-linux-x86-opengl?
My machine is amd64.

[PaulBredbury]

For Doom3, could try dhewm3 on github - is in AUR.

[alex.blackbit]

PaulBredbury,

thanks for that link, that's very interesting and one should write an ebuild for that.
For now I'd like to identify what exactly the problem in my environment is.
ATM I assume it's a missing mesa feature.
It seems like GL_EXT_texture_compression_s3tc is needed and glxinfo does not list that.
also, that information may net even be correct, since doom3 is a 32bit executable and glxinfo outputs information based on the system libraries, which are 64bit.
OT question: how do I use glxinfo on the app-emulation/emul-linux-x86-opengl libs?

I don't understand how all that is possible, I played doom3 in the past with the radeon driver and mesa.
It this feature isn't in current ~ mesa, it surely wasn't in app-emulation/emul-linux-x86-opengl a few years ago.
/me is very confused.

[yoshi314]

install libdtxc-dxtn and use driconf to force texture s3tc compression on.

regarding doom3, i used that port from github : https://github.com/janisl/doom3.gpl/commits/master , as it seems most active as of now. that works for me on hd3300 with radeon driver.
_________________
~amd64
shrink your /usr/portage with squashfs+aufs

[alex.blackbit]

yoshi314,

thanks for the hint.
I noticed it's actually media-libs/libtxc_dxtn, not libdtxc-dxtn, mind the superfluous 'd'.
I'll try it out when I come home in ~8h.
To increase my learning experience, do you know if this was once part of mainline mesa or pulled in my portage or something?
As I already stated, all this worked OOTB a while ago.

[alex.blackbit]

I installed media-libs/libtxc_dxtn.
doom3 console output reflects the added lib but still does not start.
quake4 console output also reflects the added lib and starts now.
I get to the menus and stuff.
When the game itself should start, I get a nice X server segfault.
What would be the best way to debug this?
A X client shouldn't be _able_ to crash the X server after all, right?

[PaulBredbury]

[alex.blackbit]

yoshi314,

doom3.gpl works smoothly!
There is something weird with the detection of video ram and accepted resolutions, but at least it works.
Let's forget about the blob that's in portage.
Have you ever thought about writing an ebuild for doom3.gpl?
Unfortunately there does not seem to exist anything similar for quake4.

[yoshi314]

[jasn]

I ran into similar problems with my system, (Radeon 6970M + radeon driver). I was previously able to run both Doom3 and Quake4, but after a system rebuild, I finally noticed that it had stopped working. I thought the problem may be related to the 32bit nature of both binaries, and tried to use FireBurn's 32 bit Mesa overlay, however I still had the same problem, as I described in my post in that thread.

As I mentioned there, I got a similar error message running doom3 with my mesa 32bit sw profile set to gallium, and while I could get doom3 to run with my mesa 32bit sw profile set to classic, it's unusable. Here's the console log from doom3 with my mesa 32bit sw profile set to gallium, and here's the console log when it's set to classic. What's strange is that I had similar problem with quake4 where it wouldn't even run, however this time when I emerged quake4, it loaded emul-linux-x86-compat as a dependency, and it will run with my mesa 32bit sw profile set to gallium. The problem is that it appears to be running in the bare minimum graphics mode. Here's the console log from quake4, when it wouldn't load previously, and here's the recent console log from it when it would run.

Lastly, I noticed that while there's no ebuild around for either the doom3 gpl port from dhewm, or janisl, there's a live ebuild for the original TTimo release in the gamerlay overlay. I synced it and then copied it to my local portage overlay and edited the homepage and git src variables for first the dhewm and then the janisl forks, however I was only able to get the emerge process as far as completing the compile phase. When the installation phase began I got a failure because it couldn't find the gamex86-base.so lib. I do have both doom3 and doom3-data from portage installed on my system, so I'm not sure what's going wrong.

If anyone has some hints as to how best to install one of the doom3.gpl ports, please feel free to advise. Otherwise I'm not sure exactly where this original issue lies, but it looks like using the 64bit version of the doom3.gpl port, seems to be the best way around the issue for now.

Thanks..

[alex.blackbit]

[jasn]

[PaulBredbury]

[alex.blackbit]

[jasn]

Thank you Alex and Paul,

After reading the Archlinux PKGBUILD, I appear to have compiled it by doing;

[PaulBredbury]

I use:

[jasn]

Thanks again Paul..

The part I was most confused about was what to do with the doom3 data files.

That cleared it up..