D2X-XL Bug Reports - Linux
Moderators: Grendel, Aus-RED-5
Re:
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._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
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.
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.
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.
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.
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.
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:
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 23059)]
0xb7c8b428 in strcmp () from /lib/libc.so.6
(gdb) bt
#0 0xb7c8b428 in strcmp () from /lib/libc.so.6
#1 0x08069ed1 in nm_load_background (filename=0x0, bg=0xbff8b890, bRedraw=0)
at newmenu.c:888
#2 0x0806a33e in nm_init_background (filename=0x0, bg=0xbff8b890, x=143, y=64, w=354,
h=352, bRedraw=0) at newmenu.c:1050
#3 0x0806a591 in nm_draw_background (bg=0x812a58f, x1=143, y1=31, x2=353, y2=351,
bRedraw=135439759) at newmenu.c:957
#4 0x08070bdf in newmenu_get_filename (title=0xa853356 \"Select pilot\\n<Ctrl-D> deletes\",
filespec=0xbff8bb20 \"/usr/local/share/d2x-xl/*.plr\",
filename=0x812a58f \"\\001menub.pcx\", allow_abort_flag=0) at newmenu.c:3362
#5 0x080ea49e in SelectPlayer () at gameseq.c:1137
#6 0x0804eb5a in main (argc=1, argv=0xbff8bd60) at inferno.c:1974
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.
http://myxo.css.msu.edu:443/d2x-xl/trunk
I usually have trouble compiling the source on the SVN server though.
Re:
Yep, this solved it.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'
Bugs roundup
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
~/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:
Code: Select all
sed -i main/config.c -e \"s/descent.cfg/.d2x-xl.cfg/\"
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:
Code: Select all
Installation: http://www.descent2.de/d2x-install.html
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.
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.
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.
Re:
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:The main folders D2X-XL uses are configurable, so you can put your data anywhere you want.
d2x-temp.mid is a temporary file.Diedel wrote:D2X-XL doesn't use any temporary files (unless the OS assigns some to it automatically for whatever reason).
Re:
It's the correct separation of program data vs user dataDiedel wrote:overkill.
Re: Bugs roundup
I can confirm this.Brebs wrote: Add option for the keyboard controls to be the original speed - they are unplayably fast Sad
I can confirm this too. But I wonder if this is a problem with D2x-XL or Timidity.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.
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.
Re: Bugs roundup
Did you try turning the keyboard ramping up?Jeff250 wrote:I can confirm this.Brebs wrote: Add option for the keyboard controls to be the original speed - they are unplayably fast Sad
-Suncho
Re: Bugs roundup
Yes - ramping only makes a small difference.Suncho wrote:Did you try turning the keyboard ramping up?
- KoolBear
- DBB Co-Founder
- Posts: 10132
- Joined: Thu Nov 05, 1998 12:01 pm
- Location: Houston, TX USA
- Contact:
Re:
Diedel,Diedel wrote:I had some trouble uploading the file because my web space is full. A complete source tgz should be online now.
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.
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:
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.
-Suncho
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).
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).
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. =)
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. =)
-Suncho
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.
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.
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.
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.
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.
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.