DescentBB

Can't you afford a cheap gfx card that will also run your games, like a GF FX 5200?

I'm thinking about that right now. Sure I can afford a video card anytime. But it will be 1. second hand and 2. fanless, because I can't justify any costs bigger than that and I want a quiet machine. I am no big gamer, so there was no problem for me in sticking with an old Matrox, especially because of the wonderful video signal quality,

Also, I did not know the Matrox drivers are that broken until I wanted to fix d2x's OpenGL mode. I also liked the fact the drivers are open source, but I guess that doesn't matter much anymore now as they are broken.

I'll keep on reporting bugs, if I can find any, with the ancient GeForce, and my laptop, if it ever gets OpenGL support, but I'll forget about running d2x with Matrox G200 and G400.

Radeon 9800 pros are pretty cheap now, and their fans are really low noise. I had one quite a while.

If you're shooting for the most trouble-free Linux graphics solution, I would go for an nVidia card.

The downloads for source and executable are stuck at version 1.5.155 (which for me, segfaults with the SDL parachute immediately).

Oops, that's an error on my behalf - the Linux version numbers on the web site are wrong. 1.5.155 is the current Linux version.

Jeff, I'd think twice about that. The NVidia cards do not play nice with OpenGL (at least with the official drivers), especially if you using something like Xinerama.

Brebs wrote:The downloads for source and executable are stuck at version 1.5.155 (which for me, segfaults with the SDL parachute immediately).

This is what happens in Windows if you don't have the Descent 2 data properly installed.

What could I be missing then? In linux, I can run version 137 and 150, but 158 deploys the parachute and segfaults.

_sd wrote:but 158 deploys the parachute and segfaults.

1.5.158 works if I start with command-line option: -sound22k (regardless of whether that option is present in d2x.ini)

I tried it on the OpenSUSE 10 distro (up-to-date) and had no problems.

Here too -sound22k makes the game run (linux 1.5.158 compiled from source), but with old style menus for some odd reason.

DCrazy wrote:Jeff, I'd think twice about that. The NVidia cards do not play nice with OpenGL (at least with the official drivers), especially if you using something like Xinerama.

I used to dual-boot Linux on an nVidia box (with no ailments, although I never tried multiple displays) a couple of years ago, but now I've got it exclusively on my laptop with Intel integrated graphics. I would think that from public opinion and the newest Linux benchmarks that I could find, my recommendation is still safe.

When I select join server with udp tracker selected the screen comes up showing a bunch of empty slots and immediately the game stops responding to input. An strace of the process reveals the below repeated indefinitely untill I kill -9 the process.

[pid 10857] sendto(15, \"D2XUDPn\\266\\0\\0\\0\\0008\\0\\0\\0\\0\\0\\0\\0static\\0\\0\\0\\0\\0\\0\"..., 52, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(\"53.114.24.38\")}, 16) = -1 EINVAL (Invalid argument)
[pid 10857] sendto(15, \"D2XUDPn\\266\\0\\0\\0\\0008\\0\\0\\0\\0\\0\\0\\0static\\0\\0\\0\\0\\0\\0\"..., 52, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(\"53.114.24.38\")}, 16) = -1 EINVAL (Invalid argument)
[pid 10857] sendto(15, \"D2XUDPn\\266\\0\\0\\0\\0008\\0\\0\\0\\0\\0\\0\\0static\\0\\0\\0\\0\\0\\0\"..., 52, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(\"53.114.24.38\")}, 16) = -1 EINVAL (Invalid argument)
[pid 10857] sendto(15, \"D2XUDPn\\266\\0\\0\\0\\0008\\0\\0\\0\\0\\0\\0\\0static\\0\\0\\0\\0\\0\\0\"..., 52, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(\"53.114.24.38\")}, 16) = -1 EINVAL (Invalid argument)
[pid 10857] sendto(15, \"D2XUDPn\\266\\0\\0\\0\\0008\\0\\0\\0\\0\\0\\0\\0static\\0\\0\\0\\0\\0\\0\"..., 52, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(\"53.114.24.38\")}, 16) = -1 EINVAL (Invalid argument)

One note...
A tcpdump shows the following before the lockup:
So it appears that it is getting somewhere before the lockup that happens within a second or so.

The game is requesting data from the tracker it knows, but it should only do so every 3 secs or so ... and not crash.

Compiled linux version 1.5.171 from source, and running the executable results in:

Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Segmentation fault

Whereas 1.5.150 compiled and run in the same environment, works.

Yeah man, it runs on my system, and if it doesn't on yours, it might be an idea to get a debugger and see *where* it crashes, because unfortunately I cannot magically guess the reason of your crashes from your elaborate, verbose error description.

Is there a way I could get sources for different versions between .150 and .171? Thus I could report where the change happened that causes the crash.

Version 158 crashes with the same 2 lines long message. Regrettably, I don't have any versions between 150 and 158. But meanwhile I could try the debugger.

In version 1.5.171

digi_init () at digi.c
276 if (SDL_OpenAudio (&WaveSpec, NULL) < 0) {

Program received signal SIGSEGV, Segmentation fault.
0xb7e08a3c in SDL_BuildAudioCVT () from /usr/lib/libSDL-1.2.so.0

Single stepping until exit from function SDL_BuildAudioCVT,
which has no line number information.
0xb7e059b0 in SDL_Error () from /usr/lib/libSDL-1.2.so.0

Using -nosound allows me to run the game.

The call in .150 and .158 looks very much like the one in .171

Very good, sd. Try to enable/disable SDL mixer usage using the -sdl_mixer [0|1] command line switch. Maybe that helps.

No, -sdl_mixer 0 or -sdl_mixer 1 do not help. The game exits immediately with both.

-nosound allows to run the game, as do -sound11k and -sound22k. Which, by the way, uses the old menustyle now by default. -sdl_mixer 0 or -sdl_mixer 1 do not cause any problems if I use at least -nosound, -sound11k or -sound22k.

On my secondary computer, the game segfaults with

Program received signal SIGSEGV, Segmentation fault.

Debugger shows the problem at line 1441 of ogl.c

if (!gameOpts->render.bUseShaders ||

Cancel everything I had written here a moment ago.

I was running the old d2x 0.2.6 and thinking I was running d2x-xl. Typing d2x-gl launches the old d2x, whereas I must type ./d2x-gl to run d2x-xl even if I am inside the source dir with the compiled d2x-xl binary.

So, that problem remains and is not helped by -use_shaders 0. This is with 1.5.150 and 1.5.171 and Nvidia binary drivers and a GeForce 2 MX card.

With Matrox G400 MAX and its memory leak problems I can run the d2x-xl as long as I use some of the abovementioned sound switches, and there is no problems at all with shaders.

_sd,

I think I have it now. The line you quoted is part of a multi line boolean expression using a char *ext. It could be that ext is NULL on your GF 2 MX system, so try changing the statement to the following: Further down, there is another line, change it to this:

I just tried this and have a couple of questions:

1) I get no sound or music durring game play. Sound still works for the movies though.

2) I can kill those little purple guys on the first level just by bumping into them once. Did someone play with the difficulty levels? It seems a little TOO easy even on rookie if that is the case.

Great job! Looks and runs great!

Forgive me if these problems have already been addressed as I have not read the whole thread. I hope this is ok in the bugs section.

The small drones can't take much.

Now I got 300 times

MEM_FREE_NOMALLOC: An attempt was made to free a ptr that wasn't allocated with mem.h included

and then the game exited. I redirected stderr to a file, and there was one row in the middle of all that said

Fatal signal: Floating Point Exception (SDL Parachute Deployed)

Debugging that, it says:

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1221921056 (LWP 11070)]
0xae873289 in _snd_pcm_adpcm_open () from /usr/lib/libasound.so.2
(gdb) bt
#0 0xae873289 in _snd_pcm_adpcm_open () from /usr/lib/libasound.so.2
#1 0xae868369 in snd_pcm_hw_refine_slave () from /usr/lib/libasound.so.2
#2 0xae873324 in _snd_pcm_adpcm_open () from /usr/lib/libasound.so.2
#3 0xae865425 in snd_pcm_hw_refine () from /usr/lib/libasound.so.2
#4 0xae868461 in snd_pcm_hw_params_slave () from /usr/lib/libasound.so.2
#5 0xae8766c2 in _snd_pcm_rate_open () from /usr/lib/libasound.so.2
#6 0xae868550 in snd_pcm_hw_params_slave () from /usr/lib/libasound.so.2
#7 0xae85d964 in snd_pcm_hw_params () from /usr/lib/libasound.so.2
#8 0xb7e34e88 in SDL_MixAudio_MMX_S8 () from /usr/lib/libSDL-1.2.so.0
#9 0xb7e30508 in SDL_OpenAudio () from /usr/lib/libSDL-1.2.so.0
#10 0x08160f7f in digi_init () at digi.c:276
#11 0x0805012d in main (argc=1, argv=0xbf8e96e4) at inferno.c:2658

Maybe that is a bug in ALSA? With ./d2x-gl -nosound it gets even more mysterious. I get MEM_FREE_NOMALLOC warnings, then the program stops. After pressing Ctrl+C I get some more, and after another Ctrl+C again some more, and then it exits again.

The first MEM_FREE_NOMALLOC is at:

MEM_FREE_NOMALLOC: An attempt was made to free a ptr that wasn't
allocated with mem.h included.
343 Warning (\"Freeing a non-allocated pointer!\");
(gdb) bt
#0 mem_free (buffer=0xa91c328) at mem.c:343
#1 0x0816da0e in args_exit () at args.c:101
#2 0x0816da5a in InitArgs (argc=2, argv=0xbf967c04) at args.c:114
#3 0x0804fdf5 in main (argc=2, argv=0xbf967c04) at inferno.c:2570

Which program/source code version?

linux 1.5.171 with your proposed changes to ogl.c

I'll get 1.5.176 and try it immediately

Update. The shader-related segfault is gone with 1.5.176. The MEM_FREE_NOMALLOC problem is still there, i.e. running ./d2x-gl only gives me about 300 of them and then exit. No d2x-gl window appears at all.

You must be constantly using the debug version, or you wouldn't get that memory handling error message.

I decided to use --enable-debug until I am able to play d2x-xl with my 2nd machine and its GeForce 2 MX.

Do you suggest I forget the MEM_FREE_NOMALLOC and report only segfaults and SDL parachutes? The most recent might need to be reported to SDL or ALSA developers. Or what do you think? If that is so, I'll ask them about it as soon as I have a bit more free time.

I think something is mightily f*d up with your drivers/distro, and that you are consuming my time completely unnecessarily, because I don't have any of these problems, nor apparently do other Linux user (at least those that would bother to report such bugs).

Edit:

I have checked for the memory handler error messages: They were produced due to a bug in the memory integrity check. I have fixed this, and now there aren't any error messages at all from the mem handler.

Edit 2:

I have added some execution logging to D2X-XL. You can grab the source zip file (not the tgz), extract it to your source folder (it won't overwrite any Linux specific stuff), and make another debug build. Execute d2x-xl using -debug-printlog and examine ~/d2x.log after you have terminated it or it has crashed.

With 1.5.177 .zip sourcecode extracted on top of 1.5.177 .tgz sourcecode, -debug-printlog works. No MEM_FREE_NOMALLOC errors appear in stdout, but there are exactly 418 of them in d2x.log

The backtrace of the first MEM_FREE_NOMALLOC is identical to the one posted above.

Parts from the logfile:

Loading main hog file
Loading text resources
File 'descent.tex' not found # Is this serious?
...
File 'descent.pig' not found # I assume this is not fatal, since all Descent 2 datafiles are there.
...
Initializing sound # The last significant line. The remainder is wholly MEM_FREE_NOMALLOCs.

Then the game exits. With -nosound I need to press Ctrl+C three times. I'm now trying to debug into what the game does when it gets stuck.

I'll try --debug-printlog in my other machine, the one with a Matrox card, to see how a healthy d2x.log looks like.

There is a problem with audio on your system. Try to call d2x-xl with '-sdl_mixer 1' and '-sdl_mixer 0', and see whether it works with one of the settings.

Please also re-download the .177 source zip and re-extract it, I have added a few more lines to log, and made sure all memory is allocated via the D2X memory handler.

The machine with the Nvidia GeForce 2 MX is stuck inside newmenu.c:newmenu_get_filename(). It runs all the time, redrawing the menu, but the window is not displayed on screen.

After my first Ctrl+C keypress, the game doesn't call any drawing functions anymore, but instead runs a small loop of some hundred lines in newmenu.c This continues after the second Ctrl+C. (I noticed that, when run as ./d2x-gl -nosound, the game will return to the debugger forever, but when run without debugger, it will now exit after two Ctrl+C keypresses.)

glxgears works, and is accelerated. glxinfo says direct rendering is enabled.

-sdl_mixer 0 and -sdl_mixer 1 have no effect. Only -nosound has. -fullscreen has also no effect.

I am trying to get -hires_textures 1 to work in Linux. I have added a few extra debug statements and found that CreateShaderProg (in arch/ogl/ogl.c) fails. It would appear that glGetObjectParameteriv (fs, GL_OBJECT_COMPILE_STATUS_ARB, &bFragCompiled); fails (~line 1334) since bFragCompiled is false after this call. Any ideas?

The bug has only been fixed in v1.6.6. There is no Linux source archive with this version yet. Get the alternative source zip and extract it over your source. Then change the version no. in configure.ac to 1.6.6, './configure'. Then edit conf.h and enable SDL_mixer. Then compile v1.6.6.

I made the changes you suggested and compiled 1.6.6 for Linux. This still does not seem to fix the problem, at least on my system. I ran d2x-xl with -debug-printlog. The log file is now showing that it couldn't compile the fragment shader.

A bit more information about my system. I am running an NVidia GeForce4 TI4200 graphics card on SuSE 10.0 with the NVidia drivers. d2x-xl works wonderful with this configuration but doe s not display the hires textures.

Doug

Midi playback in Linux is no longer working. Right now a temporary midi file is supposed to be created in the user's home directory and played by SDL. The statetment that sets this up is in arch/linux/midi.c line 110 which reads

sprintf (fnMusic, \"~/d2x-temp.mid\");

However a ~ only works for home in shell commands. If you change the line to

sprintf (fnMusic, \"%s/d2x-temp.mid\", getenv(\"HOME\"));

and include a #include <stdlib.h> at the top of midi.c, then you will accomplish what you intended with the ~ and midi play will work again.

Doug.

Doug,

for some reason the fragment shaders do not compile on Linux. I cannot fix that, because I don't know what's wrong. They work fine with WinXP drivers (both NVidia and ATI). No fragment shaders -> no hires texture support (shaders are needed to render them properly in cases of overlay textures that have a transparent area that goes through the bottom texture too, e.g. doors).