DescentBB

I had some trouble uploading the file because my web space is full. A complete source tgz should be online now.

_sd wrote:With 1.5.132 source, a linker error:

gcc -I ./arch/linux/include -I/usr/include/SDL -D_REENTRANT -pipe -O2 -Wall -Wno-char-subscripts -o d2x-gl main/libmain.a 3d/lib3d.a 2d/lib2d.a arch/linux/libarch_linux.a arch/ogl/libarch_ogl.a arch/sdl/libarch_sdl.a libmve/libmve.a mem/libmem.a iff/libiff.a texmap/libtexmap.a misc/libmisc.a maths/libmaths.a cfile/libcfile.a -lm -lGL -lGLU -lSDL_mixer -lSDL -lpthread
main/libmain.a(songs.o)In function `songs_play_song':
songs.c:(.text+0x535)undefined reference to `midi_volume'
songs.c:(.text+0x549)undefined reference to `midi_volume'
collect2ld returned 1 exit status
make[2]*** [d2x-gl] Error 1

I'm having the same trouble. I noticed that if I just change the midi_volume declaration immediately before the songs_play_song function to actually equal something, like =0 or =255, then it compiles fine. MIDI doesn't work then though, not that it would have worked otherwise. The only way I've gotten the MIDI to work so far on Linux is to just use the pre-compiled binary.

Edit src/conf.h and see whether USE_SDL_MIXER is defined as 1. If not, change that to '#define USE_SDL_MIXER 1'

Setting the midi_volume to 4 enables me to compile the game (1.5.132), but when running, I get

Fatal signal: Segmentation Fault (SDL Parachute Deployed)

and nothing else. The 1.5.127 version still runs fine, with the exception of the memory hog problem, which I am still trying to solve. The binary 1.5.132 also segfaults.

1.5.132 segfaults if you haven't specified a default player profile in d2x.ini (-player <player name>).

Apart from that all I can say is that D2X-XL works on my Linux box with midi enabled. Sorry I cannot help more.

I had \"-player jaakko\" in a file called .d2x-xl in my home dir. Still segfaulted. Tried putting the same string into /usr/local/share/d2x-xl/d2x.ini, with the same result.

Is there an automatic way the game will do this, or will every user need to know to put it there?

_sd,

what can I say?

All the things you find faulty work with my Linux distro, compiler, SDL installation, OpenGL driver and D2X-XL setup.

I don't know how to help you. I'd need to debug the application on your machine to help you.

I'll try to compile d2x-xl tomorrow in an Ubuntu box. I also filed a bug in Freedesktop bugzilla about the memory leak. I still don't get the midi_volume thing. Should I define it or not? Or where is it supposed to come from? Do I have an outdated ALSA, or what else could it be?

If there is no default profile defined, the game could assume that the first profile it finds is the default. Also, I see next to no output on the terminal I run d2x-gl from. I'd like it to report to stderr when it doesn't find something. It could also report when it finds something if -debug is specified on the cmdline.

_sd: The sequence goes:

(1) run ./configure.
(2) edit conf.h. #define USE_SDL_MIXER 1 in it.
(3) make
(4) Should work. (if not, timidity and SDL-mixer have not been set up right for your distro; the instructions on the D2X-XL page should put you in decent stead.)

And, bug reports in 1.5.132.

I'm also seeing the segfault. It's appearing when the \"Select Player\" screen appears, and only if it's the first menu in the game. gdb gave me this backtrace:
Furthermore, it appears that any time I reload a game, the difficulty is reset to Hotshot. This seems to go at least back to .125.

McMartin, that was fixed in 1.5.133 (The Select Player Crash).

Is there a CVS server or whatnot for later-than-latest Linux releases?

No (Actually yes. See Jeff's post =P ), but it also crashed in the Windows version. Here's the change list: http://www.descent2.de/d2x-history.html

Yes, SVN server here:
http://myxo.css.msu.edu:443/d2x-xl/trunk
I usually have trouble compiling the source on the SVN server though.

Diedel wrote:Edit src/conf.h and see whether USE_SDL_MIXER is defined as 1. If not, change that to '#define USE_SDL_MIXER 1'

Yep, this solved it.

I think that src/arch/linux/midi.c src/arch/linux/hmpfile.c and src/arch/linux/include/hmpfile.h are missing from the svn source. After I added these files from the .132 source, it compiled fine.

With the SVN source, the D1 intro briefing doesn't occur, just the pre-level-1 briefing (i.e. the Dravis dialog is missing).

After installing .134's source zip over .132's source tgz, the \"difficulty resetting\" bug appears to have vanished as well.

Hi, here's my list

~/descent.cfg should be ~/.d2x-xl.cfg, to keep to the Linux naming convention (also, ~/d2x.ini should be ~/.d2x-xl.ini). I patch the source with:
ALIEN1.256 should be renamed to alien1.256

Add the source code releases to Sourceforge, for distros like Gentoo which prefer to compile from source. Remove the URL redirection to the latest version on the homepage, because it breaks version-control.

Add option to write files solely within e.g. ~/.d2x-xl-games/, to be compatible with an installation of the Descent files into /usr/share/games/d2x (a read-only directory). My workaround is to add lots of symlinks pointing to /var/games/d2x-xl (which is writeable).

Add option for the keyboard controls to be the original speed - they are unplayably fast

The \"install\" line in readme.txt should be: I want to get this wonderful game into Gentoo's official software list Thanks for your efforts

For tolerably obvious reasons, getting this distro-quality hasn't been very high on his list.

Simply hardcoding in different values isn't going to cut it. A full \"Make this standard Linux software\" project would involve, at minimum:

- Configurable content directory, so that files can be forced onto distro-specific areas.
- User-specific written directories. (This is the biggie. Two instances running on the same drive will stomp on each others' temp files, at present.)
- A configure script powerful enough to, at minimum, work out which value of RENDER2TEXTURE will link, given the installed OpenGL drivers, and which will correctly define USE_SDL_MIXER if SDL_mixer is, in fact, present.

Fortunately, none of this is likely to touch any of the bits Diedel has been working on. So if you find an autotools wizard, you can unleash him upon the buildset and any patches/etc that result should be easily applyable later.

The main folders D2X-XL uses are configurable, so you can put your data anywhere you want.

D2X-XL doesn't use any temporary files (unless the OS assigns some to it automatically for whatever reason).

I wouldn't know how to figure which level of OpenGL support a particular Linux installation (installation, not distro) offers to properly decide with version of rendering to textures to chose.

Diedel wrote:The main folders D2X-XL uses are configurable, so you can put your data anywhere you want.

Linux games should separate the read-only data (in /usr/share/) from the writeable user files (in ~/). I don't currently see a way to do this.

Diedel wrote:D2X-XL doesn't use any temporary files (unless the OS assigns some to it automatically for whatever reason).

d2x-temp.mid is a temporary file.

You want per user configurability?

That may theoretically the perfect way, but in a normal Linux environment (single user on a PC) overkill.

Diedel wrote:overkill.

It's the correct separation of program data vs user data

Brebs wrote: Add option for the keyboard controls to be the original speed - they are unplayably fast Sad

I can confirm this.

McMartin wrote:In particular, something that I'm sure is supposed to be some kind of atomspheric background instrument in D1L2 is actually coming out as a playground whistle.

I can confirm this too. But I wonder if this is a problem with D2x-XL or Timidity.

Also, as I was playing, I noticed that the midi music didn't repeat. Once it got to the end of the song, there was no more music.

Another thing: It seems that if you run out of energy while firing a primary energy weapon that when you go into an energy center, your ship will begin to uncontrollably fire its primary weapon.

Jeff250 wrote:

Brebs wrote: Add option for the keyboard controls to be the original speed - they are unplayably fast Sad

I can confirm this.

Did you try turning the keyboard ramping up?

Suncho wrote:Did you try turning the keyboard ramping up?

Yes - ramping only makes a small difference.

As far as I can tell, it doesn't make any difference.

Another bug: It seems that the D2 ending movie plays at the end of any mission. For example, if I \"beat\" Minerva 3, it plays the ending movie.

Diedel wrote:I had some trouble uploading the file because my web space is full. A complete source tgz should be online now.

Diedel,

KoolBear.com has all the space you need. I will be more than happy to setup a sub-domain as a mirror for you!

KB

Thx for the offer KB.

I have two domains with 100 MB space each though, and after I reorganized some stuff I got everything to work again. Man, I have like 80 or 90 MB screenshots for the level spotlight online ...

People, read my level spotlight, there's tons of hand picked, cool levels in there! It saves you the time to sift through the gazillion of crap Descent 2 levels out there to find something useable.

(My) tonight, I will upload new levels to it.

Diedel, are you on the descent-source@warpcore.org mailing list?

One guy just posted something there:

Hello

My problem with other sourceports is that I can't use OpenGL. When I am in
the game, the display flashes very fast, probably at the refresh rate. That
means I am seeing the image being drawn, then cleared, then drawn, when the
game should double-buffer it so that I see one buffer while the other is
being drawn.

I have this problem with d2x-0.2.5 and d2x-rebirth. Also, with both X.org
6.9.0 and 7.0.0. With d2x-xl I don't have this problem, but instead, when
I'm in any menu, the heap of the game, as shown in
\"cat /proc/pid-of-the-game/smaps\" grows, from 0.5 to more than 20 megabytes
per second.

The allocation that results in this leak is inside a glGenTextures call. I
have filed a bug at freedesktop bugzilla, with no results yet. I have also
reported this at the d2x-xl's forum, but seems that nobody else has had this
problem. I also googled for some tutorials, and found a warning that misuse
of the glGenTextures call will result in a memory leak. But I must assume
the problem is with my Matrox G400's drivers (linux and X 6.9.0 atm) and not
the game, because, again, nobody else has complained about encountering this
problem.

-Kimmo S.

I had been on that list once, but quit from it, because there were more ppl whining about what I did with D2X-XL (D2X-W32 at that time) than helping me along.

That guy had contact with me. Apparently, his OpenGL driver or libs have bugs. The heap grows in calls to the OpenGL driver. I cannot see how I could help him.

He should get himself another gfx card, or install the proper drivers. And get rid of his f'd Linux distro (I think he's using Debian, and most ppl having problems with D2X-XL due to driver issues are Debian users).

Did he have the same problem with other games?

Suncho,

don't try to outsmart me on my own terrain. His gfx card and the Matrox OpenGL ICD suck for gaming.

I'm not trying to outsmart you. I was asking if he had the same problem on other games. If he doesn't, then we might be able to figure out a work-around or something. I'm just trying to help.

If I wanted to outsmart you, I'd just go in there and fix it, but I can't outsmart you because I'm not as smart as you and I don't even know if it could be fixed. =)

I am not saying that you are generally not as smart as I am. It's just about this coding and OpenGL stuff. If you were able to debug and fix problems in D2X-XL, you'd be more than welcome.

For some reason his driver doesn't like glGenTextures() calls by D2X-XL. He is the only person who ever reported that problem. I memory leak checked D2X-XL on several machines, OS's and with several different gfx hardware and could never reproduce this. And I know that Matrox' OpenGL support isn't exactly the best.

The message I wrote to the d2x list was intended to see if anyone else has heard anything about a similar problem, and this far nobody has.

I don't have the memory leak problem with any other game. It doesn't happen with d2x-rebirth, it doesn't happen with original d2x. It doesn't happen with any Doom sourceport known to run under linux. Only a guess, but I would suggest it is limited exactly to the new menustyle in d2x-xl.

Is there a version of the d2x-xl source with the old style menus in place? If there is an incremental change to the new menu style, I'd be eager to try out different stages.

The memory leak doesn't even happen when running the d2x-xl game, i.e. flying around. It only happens if I enter a menu, even an in-game menu, or view the help that is accessible by pressing F1.

Btw. this distribution is Gentoo. Not a riced one or ~x86. Stable x86 with sane and conservative settings. I was going to try d2x-xl in my laptop that has both Gentoo and Ubuntu, but that wouldn't work since it has no accelerated OpenGL support.

Have you tried to turn the new menu style off (-menustyle 0 in d2x.ini)?

Well, this feels a bit silly... the running leak does not happen in the player selection menu, with old menustyle. It happens in the main menu. It does not happen in the mission selection menu, but it does happen in the skill selection menu.

When I, instead of choosing a pilot, run the cursor up and down repeatedly, the game eats memory. It seems that it is about the menus not getting redrawn continuously with the old menustyle. I find it odd that it still consumes more than 80% of a 933MHz cpu while just waiting for my keyboard input.

The intense flashing that happened with d2x-rebirth and original d2x in OpenGL mode happens now with d2x-xl, but as soon as I switch virtual desktops or move the d2x-gl window, it is cured. When I press F2, the screen goes black, i.e. I can't see the menus after being in the game. Then, as I press ESC, to get back to flying, the flashing is back. Again this is cured by moving the d2x-gl window slightly or switching to another virtual desktop and back.

Pressing ESC to exit the actual gameplay, the screen goes pitch black, and I must blindly navigate the menus to quit the game. The pitch-black \"Abort game?\" menu and the options menu accessible by pressing F2 do not leak memory, but the pitch-black main menu does.

I tried the original d2x-gl now. If I cycle through menus on and on, it too eats meory. I'm starting to hate Matrox and the X.org drivers so much.

I can play original d2x-gl in OpenGL mode. Moving the window to stop the flashing works there too. And if I'm using fullscreen, switching virtual consoles (as opposed to virtual desktop, which does the trick when d2x is not fullscreen) also fixes the problem. But then after exiting the gameplay, the main menu and \"Abort game?\" menus are not displayed. Instead, the screen is again totally black. Also, the flashing comes back if I go to \"Abort game?\" menu and resume the gameplay. The F2 options menu has black background, but at least the letters are visible.

I have an old GeForce2 MX somewhere. Will try that next. But not on this machine, because its video signal (DAC) quality is crap. The amazing video signal quality is what attracted me to Matrox in the first place.