[northtwilight]

Hi there,

Since moving over to an AMD64 (running Debian Unstable, as before the arch shift) I've been having a devil of a time trying to get FS2 to run properly, mostly due to permission issues and the rest. I seem to remember while on the i386 arch that it was a great deal simpler. Any reason for the change?

Incidental stuff: 2Gb RAM, Athlon XP 3500 (2200 Mhz), Nvidia 6600LE AGP with 256mb RAM onboard, running 9625 beta (problems occurred on all NVidia drivers while on AMD64), xorg server 7.1.0-5.

I've been following the wiki entry for Linux, if that helps. If anyone needs more info, just let me know and I'll provide.

Cheers
Mass

[taylor]

I run it on AMD64 and don't have any issues.  I'm still using an older NVIDIA driver version, though I can't imagine that would be the problem.  Some 64-bit distros do have issues though, not specifically with the game but with many things.  I think that Fedora Core and Ubuntu (maybe?) are the easiest to deal with there.

What issues are you having specifically?  Maybe I can help out with those, and if it is somehow related to a game code issue then it's something that will need to be fixed.

[northtwilight]

Hey boss!

Good to hear from you.

If I ignore the wiki method and try to run it directly from the same X session (from an X- or gnome-terminal), the screen blanks totally and I lose keyboard input completely -- not even Alt+SysRq+B interrupts properly to reboot, and I have to hard- or soft-reset the machine.

Just before it attempts to launch, I get about five or six error messages saying that they can't access /dev{/sound}/dsp ... which is strange, as most everything else (alsa and openal-related; other apps, that is) seems to be fine.

Following the wiki entry, I set up an alternate Xsession, changed the Xwrapper permissions, and when I try to login, I get a blank Xsession, with stderr showing the following:

AUDIT {date and time: process/thread #}  X: client 1 rejected from local host
Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified


waiting for X server to begin accepting connections


... which I take to mean that I need to add suitable permissions or something.

Hm.

Any advice you could provide would, of course, be much appreciated.

Cheers
Mass

[northtwilight]

OK, just for ****s and giggles I'm going to create a debug build and then try to see if it generates anything useful from a straightahead i386-style install,  will keep you posted {pun not intended}.

[northtwilight]

OK, I get consistent  /dev/{sound/}dsp:Device or resource busy errors (5 or 6) -- and, on the debug build, I usually get an error just before the screen blanks out that says that DirectSound doesn't work (!!!).

I can't seem to get a consistent log of this , however. So instead I'll attach the config.log, hoping that it gives enough clues...

[attachment deleted by admin]

[northtwilight]

OK, here are the errors I get from a 3.6.9rc7 build using just the retail VPs.


open /dev/[sound/]dsp: Device or resource busy
open /dev/[sound/]dsp: Device or resource busy
open /dev/[sound/]dsp: Device or resource busy
open /dev/[sound/]dsp: Device or resource busy
open /dev/[sound/]dsp: Device or resource busy
open /dev/[sound/]dsp: Device or resource busy
open /dev/[sound/]dsp: Device or resource busy
(null): "DirectSound could not be initialized.  If you are running any applications playing sound in the background, you should stop them before continuing."open /dev/[sound/]dsp: Device or resource busy


If I use retail VPs + 3.6.8 zeta VPs, it crashes. Hope this helps...

[northtwilight]

Why would a Linux build on AMD64 complain about needing to access DirectSound??

[taylor]

(Ugh, forgot to come back and check here for anything new...)

What are the contents of your ~/.openalrc?  I assume that sound is working fine otherwise, that your probably using ALSA, and that if you have more than one sound card that the one you normally use is actually set to the default.  If it's not something as simple as that stuff, then I'm not quite sure what to say on the subject.  It's been a really long time since I've had sound errors like that and I can't for the life of me remember what the problems were at the time.

Regarding the DirectSound thing, it's just the error message.  I have (or had) an update around here somewhere which gets rid of any mention of a specific API in non-specific error messages.  I don't think I ever actually got that into CVS though, since I'm rewriting all of the sound code anyway for 3.7.

[northtwilight]

Hey boss,

Me too, got delayed by a bunch of things too trivial to list... anyway, I don't seem to have an ~/.openalrc file present and I'll check tonight if there is a related file in /etc .

Let me know if there is anything else I can add to give you more information about the system, build setup, or other components.

Cheers
Mass

update: attaching config.log and ~/fs.ini


[attachment deleted by admin]