DescentBB

D2X-XL Bug Reports - Linux
________________________________________________________________________________

Koolbear has kindly provided a support ticker tracker. Find it here.

Please post bug reports there in the future.

The bug reports threads in this forum will be put out of service.
________________________________________________________________________________

This thread is intended for D2X-XL bug reports for Linux - no suggestions, no questions, no bug reports for other OS's here please.

To put them all neatly together and help me not to forget them, I kindly request everybody to post bug reports for D2X-XL/Linux in this thread.

Please keep this thread clean. In case some issue needs detailled discussion, I will open an extra thread for it.

Thanks

Diedel (a.k.a. karx11erx)

PS:

Please read the D2X-XL FAQ and the D2X-XL Version History to see whether your problem has already been solved.

FYI, I had to specify the userdir in d2x.ini and lowercase the mission names before they showed up in the list, but the Descent 1 missions are working.

Still no MIDI tho. Not a big deal, but it would be great if it worked. I do have MIDI in other programs, so I don't think it is my environment. Just in case, I am using SuSE 9.2.

Thanks!

Hm. Afaik Midi is handled by the SDL in d2x-xl. I am not sure about this though. I don't have any knowledge about Midi stuff (libs, coding, how-to) though.

I'm getting a segfault after the choose/create pilot menu with the 1.5.63 source disrtibution. However, I investigated it further and it turned out to be a dereferencing an uninitialized pointer issue. Here is my fix:

--- d2x-xl-1.5.63/2d/bitmap.c Tue Dec 20 12:26:58 2005
+++ d2x-xl-1.5.63-mh1/2d/bitmap.c Mon Dec 26 14:35:37 2005
@@ -265,6 +265,15 @@
grs_bitmap *new;

new = (grs_bitmap *)d_malloc( sizeof(grs_bitmap) );
+#ifdef OGL
+ new->gltexture=NULL;
+ new->bm_parent=NULL;
+ new->bm_frames=NULL;
+ new->bm_curframe=NULL;
+#endif /* def OGL */
+
gr_init_sub_bitmap (new, bm, x, y, w, h);

return new;

Note this bug occurs in ALL os versions of d2x, but with different compilers/operating systems the pointers may be zero instead of the garbage value I got.

Another segfault occurs when I open the Multiplayer menu. Althoug there are only 11 menu itmes it tries to draw 15 and is therefore accesing nonexistent item entries in the draw loop. My fix is only a quick hack, since I had not the time to reconstruct what's going on there, I just disallow setting nMaxDisplayable to be higher than nItems:

d2x-xl-1.5.63-mh1/main/newmenu.c
--- d2x-xl-1.5.63/main/newmenu.c Fri Dec 23 18:50:48 2005
+++ d2x-xl-1.5.63-mh1/main/newmenu.c Mon Dec 26 14:38:38 2005
@@ -1929,7 +1929,10 @@
if (!bTinyMode &&(h> ((nMaxOnMenu+1)* (string_height+1))+ (LHY (8)))) {
IsScrollBox=1;
h= (nMaxOnMenu* (string_height+1)+LHY (8));
- nMaxDisplayable=nMaxOnMenu;
+ nMaxDisplayable=(nMaxOnMenu<nItems)?nMaxOnMenu:nItems;
}
else
IsScrollBox=0;

D'uh! Ppl are sending bug fixes!

Thanks very much for your help, hass.

You do not happen to be a midi guru and can fix/improve the midi handling of d2x-xl?

ajr wrote:FYI, I had to specify the userdir in d2x.ini and lowercase the mission names before they showed up in the list, but the Descent 1 missions are working.

Before specify "userdir" d2x-xl hadn't seen available pilots.
There is no need to do it under Windows. I think d2x-xl should try to load pilots from current directory in that case.

I tried to use "userdir" to point Descent2 files, but it didn't work (tested with 1.5.69). In my opinion it could be very useful and allow to reduce D2 data files to one copy (for Windows and Linux).

Szpak wrote:I tried to use "userdir" to point Descent2 files, but it didn't work (tested with 1.5.69). In my opinion it could be very useful and allow to reduce D2 data files to one copy (for Windows and Linux).

Sorry, I didn't know about -hogdir. With that switch I can use data files from FAT32 partition.

Btw, is there something wrong with "D2X-XL History"?
http://www.descent2.de/d2x-history.html returns empty page.

Diedel wrote:D'uh! Ppl are sending bug fixes!

It was christmas

Diedel wrote:Thanks very much for your help, hass.

You do not happen to be a midi guru and can fix/improve the midi handling of d2x-xl?

Actually, I never got MIDI sound working under Linux, but I didn't put much effort into that, I just don't care. Sorry, I can't help you there.

man i need to find some time... download the latest source, and find something wrong with it so i can post a bug here.

Szpak wrote:Sorry, I didn't know about -hogdir. With that switch I can use data files from FAT32 partition.

I noticed one issue.
Is it normal that "descent2.hog" isn't visible when in "hogdir" directory and has to be placed in "userdir" directory (tested with 1.5.69)?

-hogdir might not be recognized/handled properly anymore. I had recently rewritten the entire folder detection, and there was so much old stuff around that subject in d2x that I didn't find it all. I will have to recode the -hogdir handling and put it properly into the new stuff (not much of a problem).

Diedel wrote:-hogdir might not be recognized/handled properly anymore. I had recently rewritten the entire folder detection, and there was so much old stuff around that subject in d2x that I didn't find it all. I will have to recode the -hogdir handling and put it properly into the new stuff (not much of a problem).

Ok, this is only minor problem.
I have two more

The first one.
I tried to play with "grabmouse" option and 1.5.72 and I was unable to disable it (with previous versions too). I can return to window mode (ALT-ENTER - very useful - under Linux it;s not possible to ALT-TAB in full screen), press ESC to see cursor, but it's trapped in window bound (ALT-TAB doesn't work too).
Have you successfully tried this option under Linux?
Is there switch like "-nograbmouse"? Or if "grabmouse" is disabled (commented) in .ini and it wasn't in command line it should be disabled?


The second thing. I have problem with monitor and have to use nivdia-setting to increase brightness. It works, but only utill first death. After respawn screen is as dark as was without nvidia modification, what especially without ability to switch to another application (problem above) is very uncomfortable.

I cannot reproduce the brightness problem, hence I cannot fix it.

To disable mouse grabbing, use '-grabmouse 0'.

Hi Diedel!

Just tried your version 1.5.73 (upgrading from 1.5.68 )

* Loading savegames made using 1.5.68 results in level music playing but no graphics.

I've mailed you a copy of a savegame that provokes this.

A few d2x-xl versions produced faulty save games. See the history. Don't use them any more.

Diedel wrote:A few d2x-xl versions produced faulty save games. See the history. Don't use them any more.

man that is harsh! do you know why that happens? cause i would be ticked if i kept having to start from scratch each time i play.

It had happened because I had stored 7000 bytes in the save games where it should have been 1400, and had read that 7000 bytes into a memory location sized 1400 bytes.

Diedel wrote:I cannot reproduce the brightness problem, hence I cannot fix it.

After few tests I can say that this isn't (probably) problem with nvidia-settings. It looks like after first respawn (tested in single player) brightness level set in d2x-xl options is reduced to 0. It's as dark as when you star a game with brightness set to minimal (in options).
Step to reproduce.
1. Create new player (it's probably not necessary)
2. Set brightness in options to max (at least to something more than minimum).
3. Star new game in single mode.
4. Wait for death.
5. Observe reduced brightness on screen after respawn.

It returns to normal after abort a mission.
I tested it with d2x-xl 1.5.72, Fedora Core 3 and NVidia binary driver 1.0-7174.
Does it work correctly under your Linux?

To disable mouse grabbing, use '-grabmouse 0'.

Thanks. This works correctly.

I did the following:

Start a game
crank brightness to max
died & respawned
brightness still at max

(Windows version, new menu style)

I need to check this on linux.

Diedel wrote:I did the following:
Start a game
crank brightness to max
died & respawned
brightness still at max
(Windows version, new menu style)

I need to check this on linux.

I checked under Windows (1.5.74) and still the same effect, but you could check also under Linux to be sure.

Due to problems with my monitor difference in brightness is very well visible. Maybe on "normal" monitors it doesn't matter. Do you see different between brightness set to max. and min. value?
I attached screens before and after respawn and with brightness set to 0 (minimum).

Szpak,

Fixed.

fyrephlie wrote:

Diedel wrote:A few d2x-xl versions produced faulty save games. See the history. Don't use them any more.

man that is harsh! do you know why that happens? cause i would be ticked if i kept having to start from scratch each time i play.

This is ofc fixed. So you cannot use the faulty savegames, but savegames you create now are perfectly in order and can be read w/o problems.

Diedel wrote:Fixed.

Great!

I know you already don't like me , but I have one more problem with screenshots (1.5.76). It seems they don't work.
When I press ALT-F9 nothing happens. I already disabled this shortcut in windows manager, so it shouldn't be a problem (I use Gnome 2.8 ).
Where should screenshots be placed under Linux? userdir? home dir?

szpak,

read the folder guidelines in the installation instructions (http://www.descent2.de/d2x-install.html), create the proper folders and move the data to them.

Wow, nice work.

To anyone interested, I have MIDI software synthesis in Linux set up (fairly painlessly) by using \"Timidity\" (Google or see your local package manager). Unfortunately, MIDI isn't working in D2x.

I'm using the .77 binary, and CD audio isn't working either. It's obviously reading the disk when I enable it, but I get absolutely no music.

This bug is for both D2x Windows and Linux: When strange palletes are combined with see-thru textures, there can be some strange coloring on their edges. I can't explain it much better than that, but take a look at the see-thru door just below where you start out in D2 Counterstrike lvl. 21. There is blueness around the see-thru parts in the door.

The following two may just be my crappy laptop hardware or linux drivers, but (1) I get a very slight lag in sounds, and (2) secondary textures are not shaded according to light. A door or sign, for example, will always have 100% light.

Oh I've got one more issue:

Neither ~/.d2x-xl nor /usr/local/share/d2x-xl/d2x.ini seem to be properly read by D2x. I don't know why this would be, since I've double-checked that the paths are right.

Diedel wrote:read the folder guidelines in the installation instructions (http://www.descent2.de/d2x-install.html), create the proper folders and move the data to them.

Currently I have D2 data in /usr/local/share/d2x-xl soft linked to Windows partition (earlier I had userdir and hogdir pointer there in options, so it should be similar). I have "screenshots" (sub)directory. But when I press alt-f9 nothing happen. After observation of hard disk led I can suppose that none action is triggered (and of course there is no file appeared). Should I see some info on screen like "screenshot0002.tag was successfully saved" (or error message)?
Maybe this key combination is broken under my Linux? (Fedora Core 3 with Gnome 2.8 - with disabled default alt-f9 meaning in "keyboard shortcuts"). Is there way to redefine that shortcut (without code modification)?
Tested with 1.5.77.

Jeff,

try ~/d2x.ini.

d2x-xl doesn't contain any real midi support so far. The d2 sound format is hmp, which gets converted to midi and played back by the windows midi functions.

I am currently working on integrating sdl_mixer in d2x-xl and writing a conversion function hmp -> midi. When I am done, you will be able to play midi, mp3 and ogg vorbis songs and specify your own play lists.

What is a 'strange palette'?

Certain textures (doors, grates), which are usually used as overlay textures on some base texture, have a special kind of transparency meaning that transparent areas in these textures are promoted to their underlying textures. This makes sense: Just think of the openings in grates, where you wouldn't want to see the base texture, but want to see through the base texture as well. This is called 'super transparency' in Descent. Super transparent pixels have a special color (purple, as you can e.g. see in DLE-XP). Under certain circumstances, such textures are rendered using a pixel shader. Now the pixel shader only gets active after anti-aliasing has happened. Anti-Aliasing can and will change color values particularly at sharp edges like door openings. This leads to some pixels loosing their original super transparency color key, this in turn leading to super transparency not being applied for them. Hence the mis-colored lines at door openings. Multitexturing via pixel shaders is enabled when turning hires texture usage on.

Overlay textures always being bright is a bug which I will fix.

Great.

~/d2x.ini worked fine. You may want to modify the installation instructions to reflect this, unless it's only me having this problem.

This leads to some pixels loosing their original super transparency color key, this in turn leading to super transparency not being applied for them. Hence the mis-colored lines at door openings. Multitexturing via pixel shaders is enabled when turning hires texture usage on.

How can hires textures be turned off? I don't have a hires texture directory specified in my d2x.ini.

hires texture usage is turned on by the -hires_textures switch in d2x.ini (which isn't present there by default).

I have no hires line in my d2x.ini file, but I still experience the color anomaly on the edges of doors, fans, etc. Should this \"bleeding in\" of the super-transparency palette color occur if hires textures aren't actually enabled and that whole pixel shader thing isn't needed?

I make such a point of this because it is especially apparent in some levels using palettes other than groupa. The alien2 palette for example uses a bright blue color for super-transparency, so doors, fans, etc. look pretty bad.

Szpak,

Sorry ALL for posting this here but Szpak's email address is incorrect and I can't contact him any other way except PM and I sent one of those too.

Szpak you email account must be incorrect here, I need you to correct the problem.

Thank you, back to your regularly scheduled thread.

KB

Jeff250 wrote:I have no hires line in my d2x.ini file, but I still experience the color anomaly on the edges of doors, fans, etc. Should this "bleeding in" of the super-transparency palette color occur if hires textures aren't actually enabled and that whole pixel shader thing isn't needed?

I make such a point of this because it is especially apparent in some levels using palettes other than groupa. The alien2 palette for example uses a bright blue color for super-transparency, so doors, fans, etc. look pretty bad.

If the supertransp color key is palette dependant, I need to look into the code once more. Thanks for the hint, I wasn't aware of that. Can you name a level where this happens?

It is always the same palette index (254 if you start counting at 0), but the color itself changes from palette to palette. D2 Counterstrike lvl. 21, if you go down to the bottom of the room from where you start, these doors have a bright blue bleeding into the edges.

Fixed.

Linux Fedora Core 4.

I have 3 joystickes that I use. 2 of the 3 have 19 buttons each which goes over the limit defined in joy.h in the D2X-XL code. The code currently defines 16 buttons per joystick with a maximum of 2 joysticks. I bumped the defines to 20 per joystick and a total of 3 joysticks and now d2x-xl does not crash anymore on startup. Any chance that the official code could get the supported max joysticks and max buttons bumped up? I created a little SDL program to spit out the joystick info below.

There is another issue where if the first joystick does not start at js0 then d2x-xl will think there are no joysticks when js0 might have just been unplugged so there are only js1 and js2 now. It would be nice if the joystick detection routine would count how many joysticks there are and look at all the joystick index locations (maybe up to 5 or 10 or so) to see if the joysticks are just at higher index numbers.

Joysticks=3
Joystick: 0
Name: CH PRODUCTS CH FIGHTERSTICK USB
Number of Axes: 5
Number of Buttons: 19
Number of Balls: 0
Joystick: 1
Name: CH PRODUCTS CH PRO THROTTLE USB
Number of Axes: 5
Number of Buttons: 19
Number of Balls: 0
Joystick: 2
Name: CH Products CH Pro Pedals USB Rudder Pedals
Number of Axes: 3
Number of Buttons: 1
Number of Balls: 0

Thanks for the bug fixes so far with d2. Great work!

Btw... It looks like d2x-xl will not work when compiled on x86_64 Linux systems. It looks like the font files have pointers embedded in structures. Pointers on x86 are 32bit while on x86_64 they are 64 bit so when the font file is loaded into the ft->data structure the references inside it are no longer valid.

I will look into the joystick issue. I am still planning to install Linux 64, but I am somewhat reluctant - I don't want to accidentally render my WinXP partition unuseable.

[static@localhost d2x-xl-trunk]$ diff -c arch/include/joy.h /media/usbdisk2/usr/local/d2x-xl-1.5.107/src/arch/include/joy.h
*** arch/include/joy.h 2006-02-02 22:25:02.000000000 -0500
--- /media/usbdisk2/usr/local/d2x-xl-1.5.107/src/arch/include/joy.h 2006-02-02 15:31:15.000000000 -0500
***************
*** 102,111 ****
#define JOY_1_U_AXIS 32
#define JOY_1_V_AXIS 64

! #define MAX_JOYSTICKS 2 //16

#define MAX_AXES_PER_JOYSTICK 8
! #define MAX_BUTTONS_PER_JOYSTICK 16
#define MAX_HATS_PER_JOYSTICK 4

#define JOY_MAX_AXES (MAX_AXES_PER_JOYSTICK * MAX_JOYSTICKS)
--- 102,111 ----
#define JOY_1_U_AXIS 32
#define JOY_1_V_AXIS 64

! #define MAX_JOYSTICKS 3 // ALG

#define MAX_AXES_PER_JOYSTICK 8
! #define MAX_BUTTONS_PER_JOYSTICK 20 // ALG
#define MAX_HATS_PER_JOYSTICK 4

#define JOY_MAX_AXES (MAX_AXES_PER_JOYSTICK * MAX_JOYSTICKS)

The real problem seems to be that D2X(-XL) allows the joystick button table to overflow, which shouldn't be. So I will both increase button number and fix that issue.

Your hint about the embedded pointers is extremely valuable. I will look into this and try to rewrite that code. Probably instead of using these struct members as pointers, they have to be treated as offsets and some pointer math needs to be applied.

I have looked into the code: D2X-XL does not think there are no joysticks if stick #0 is unplugged. arch/sdl/joy.c::joy_init() actually queries the number of joysticks, and then checks for the presence each joystick. Those that are present are mapped to D2X-XL joystick #0, 1, 2, etc. Until now (I am just fixing this) having more joysticks than MAX_JOYSTICKS could crash the program.

As far as embedded pointers are concerned: Try undefining src/conf.h::FAST_FILE_IO, recompile and see whether that helps already.

After bumping up the joystick max values I tested x86_64 build by using '--disable-fastfileio' with ./configure and it does fix the font pointer issue crash problem for x86_64. Looks like someone already figured out the pointer issue .

I am now running the x86_64 build without issues.

Well I do know of some network issues but I will refrain from posting that information. One bug issue at a time would probably be wise .

Btw... are any trackers working? I never get a response from any of the trackers(1 byte is sent to them but no response is sent back to the client). I tried 65.222.118.40.9424 and 81.169.162.145.9424. tcpdump logs show that no response is received. It would be nice if the gui would pop a message up stating that no response is received from the trackers so that the user will know something is wrong instead of assuming that they are just empty.

I obscured my source IP slightly with x for some octets.

13:22:42.493274 IP 65.32.x.x.28342 > 81.169.162.145.9424: UDP, length 1
13:22:42.494921 IP 65.32.x.x.28342 > 65.222.118.40.9424: UDP, length 1
13:22:45.565606 IP 65.32.x.x.28342 > 81.169.162.145.9424: UDP, length 1
13:22:45.566428 IP 65.32.x.x.28342 > 65.222.118.40.9424: UDP, length 1
13:22:47.638110 IP 65.32.x.x.28342 > 81.169.162.145.9424: UDP, length 1
13:22:47.639099 IP 65.32.x.x.28342 > 65.222.118.40.9424: UDP, length 1
13:22:48.640527 IP 65.32.x.x.28342 > 81.169.162.145.9424: UDP, length 1
13:22:48.641937 IP 65.32.x.x.28342 > 65.222.118.40.9424: UDP, length 1

FAST_FILE_IO never made much sense. Data stored in structs is read in entire struct chunks instead of member by member. This will not work when struct members aren't aligned on byte boundaries.

Please post the networking bugs - plus any fixes you're able to supply.

Afaik there are no active trackers around. Looks like the VEX tracker has been turned off. I hope Koolbear will run a DBB tracker. If you know enough about Linux, maybe you can help him to install it as a service (demon). It's a very simple perl script.

I had thought of a \"No trackers found\" message myself, but it doesn't make a real difference whether the trackers have no active hosts registered or aren't there, don't you think?