DescentBB

To get d2xtracker.pl running as a daemon, if he has perl already installed he can use:
nohup /path/to/d2xtracker.pl &

Ideally damonizing code could be added(very easily) that would cause it to go into the background. I am no expert in perl but I know enough to get some things done in it. I have a local version that already backgrounds itself with the command line -d or --daemon . Then all you have to do is run 'd2xtracker.pl -d' and it would automatically background itself and direct all input/output to /dev/null.

One of the network bugs is a bug where if you change the network port the code never uses the changed information win32 uses mpParams.udpClientPort where the linux/osx file uses udpClientPort which is assigned to BASEPORT early on.

I looked at the ipx_udp.c in the win32 and linux directory and they are both very similar and looks like it would be pretty easy to merge them(I already have a partial merge just in 10 minutes of time). With the files merged and just a few ifdefs for win32/osx/linux it would be much easier to make sure that part of the network code stays in sync with each platform. meld merge utility on Linux is great for merging things btw.

Where it would come in handy to know if the tracker is not working is if a client has an old version where the pre-defined tracker IP was changed by the tracker server operator. How would the end client know to update it? Keep in mind this might happen now if CoolBear puts up a trcker so it would have already been handy for anyone who has the current version at this time . At least they would have some clue that the tracker is not working and maybe find out why it quit working.

I remember CoolBear from around 97 or 98 when I was heavy into D2 and Kali but I am out of the loop for D2 stuff anymore(lost my kali username and password too). static at xstatica dot com is my email in case you want him to contact me about getting the tracker setup on Linux. I will definitely help in any way I can.

When the game comes up, it asks me to select a pilot. There are no pilots, because I'm running for the first time. So, I pick <CREATE NEW>, and it asks me for a name.

I give it my name, and it asks me to choose an input device. I do as I am told, and the game goes back to asking me to select a pilot. Only available option is again to create new. Doing this multiple times doesn't help.

There are no error reports anywhere.

If the game can't find the Descent II data, it will hog the cpu for about a minute, and then does a segmentation fault.

If the game finds the Descent II datafiles, the abovementioned infinite loop results. The game has write permission to hogdir and userdir. If it didn't have, it should complain about it.

Copying existing .plr files to d2x-xl's userdir doesn't solve this.

The game is a linux binary version d2x-xl-lx-1.5.109, and compiling from source fails. ./configure finishes ok.

minor: The main screen of d2x-xl still shows the old version of 1.5.107 instead of the 1.5.109.

Then its probably still 1.5.107 due to a mistake of mine. Will check on monday, goes for _sd too.

With source d2x-xl-src-1.5.116.tar and linux, I tried to solve the OpenGL problem. I commented out one #ifdef and one #endif in arch/ogl/fbuffer.c, and likewise in include/fbuffer.h

There is also

#ifdef _WIN32
# include <windows.h>
# include <stddef.h>
# include <io.h>
#endif

in arch/ogl/fbuffer.c and that I did not comment out.

Then I ran sh ./autogen.sh and ./configure --enable-release=yes and make. Got:
In file included from ../include/ogl_init.h:87,
from 2dsline.c:85:
../include/fbuffer.h:22: error: `glBindRenderbufferEXT' redeclared as different kind of symbol
/usr/include/GL/glext.h:6442: error: previous declaration of `glBindRenderbufferEXT'
../include/fbuffer.h:23: error: `glIsRenderbufferEXT' redeclared as different kind of symbol
/usr/include/GL/glext.h:6441: error: previous declaration of `glIsRenderbufferEXT'
../include/fbuffer.h:24: error: `glDeleteRenderbuffersEXT' redeclared as different kind of symbol
/usr/include/GL/glext.h:6443: error: previous declaration of `glDeleteRenderbuffersEXT'
../include/fbuffer.h:25: error: `glGenRenderbuffersEXT' redeclared as different kind of symbol

and about a dozen more.

Then I changed #define RENDER2TEXTURE 2 to #define RENDER2TEXTURE 0 in include/ogl_init.h and the result:

if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../arch/include -I../../main -I ../../arch/linux/include -I/usr/include/SDL -D_REENTRANT -pipe -O2 -Wall -Wno-char-subscripts -MT fbuffer.o -MD -MP -MF \".deps/fbuffer.Tpo\" -c -o fbuffer.o fbuffer.c; \then mv -f \".deps/fbuffer.Tpo\" \".deps/fbuffer.Po\"; else rm -f \".deps/fbuffer.Tpo\"; exit 1; fi
fbuffer.c:65: error: syntax error before '*' token
fbuffer.c: In function `ogl_fbuffer_avail':
fbuffer.c:69: error: `fb' undeclared (first use in this function)
fbuffer.c:69: error: (Each undeclared identifier is reported only once
fbuffer.c:69: error: for each function it appears in.)

I tried ./configure --enable-release=yes --without-opengl then and got:

d2x has been configured successfully.

Platform(s): linux sdl
Features : no_asm network kalinix ipx OpenGL fasteventpoll release

(No ogl in Platforms, but one in Features)

Result:
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I ../include -I ../main -I ../arch/linux/include -I/usr/include/SDL -D_REENTRANT -pipe -O2 -Wall -Wno-char-subscripts -MT bitmap.o -MD -MP -MF \".deps/bitmap.Tpo\" -c -o bitmap.o bitmap.c; \then mv -f \".deps/bitmap.Tpo\" \".deps/bitmap.Po\"; else rm -f \".deps/bitmap.Tpo\"; exit 1; fi
bitmap.c: In function `gr_free_bitmap_data':
bitmap.c:341: error: structure has no member named `bm_frames'
bitmap.c:342: error: structure has no member named `bm_frames'
bitmap.c:343: error: structure has no member named `bm_frames'
bitmap.c:344: error: structure has no member named `bm_curframe'
make[2]: *** [bitmap.o] Error 1

I'll get the 1.5.121 source and then tell what happened.

Edit: Got the exact same results with 1.5.121 source.

Did you consult the FAQ and the installation instructions about this? There's a 2nd, fallback solution for this. You seem to lack the OpenGL 2.0 support on your distro.

I thought that

#define RENDER2TEXTURE 0

is the 2nd fallback solution. My distro is an up-to-date Gentoo, but my graphics card is only a Matrox G400.

Well, the Matrox could be the problem.

I will look into the source file, but can only try compiling using RENDER2TEXTURE 0 on Linux next monday.

Edit:

I have checked this with the Win32 version and have fixed the source code. D/l the alternate source file from my D2 site and unzip it to your d2x-xl source folder (chose overwrite all regardless of date; you will not overwrite any linux specific files with this).

You should then be able to compile with RENDER2TEXTURE 0.

It worked. I was able to compile it. But now I'm again stuck at the pilot selection screen. This same happens with linux 1.5.121 binary.

Stuck in what way?

Stuck in the way that I have no pilots created yet. So, when d2x-xl asks me to select a pilot, the only possibility is to <CREATE NEW>. I give the pilot my name, and it asks me to pick a controller. I choose KEYBOARD ONLY.

Then I think it should put me to the main menu. Instead, it takes me back to the \"Select pilot\" screen, with no pilots created. Again I can only choose <CREATE NEW>. Problem is, it never actually creates the pilot.

The program probably does not have the access rights to create a new file in the folder it wants to store the plr file in.

The game has write permission to everything in my home directory. The game does not have write permission to /usr/local/share/d2x-xl/ where the datafiles are located. I have no idea where it tries to create the files, because it doesn't tell me anything. The -debug switch only outputs:

Built: Feb 17 2006 16:40:08
Compiler: 4.0.2 20050901 (prerelease) (SUSE Linux)

But that's a moot point. A far more serious problem appeared, and actually happens with 1.5.109 and 1.5.121 binary versions, as well as with the mixed version I managed to compile (I used GCC 3.3.6).

As soon as the pilot selection menu appears, the game starts hogging memory at 8 to 9 MB per second (in a 933MHz Pentium III), until it is killed. The CPU usage (of the d2x-gl binary, according to top) also goes to 90% and up, and stays there.

Player profiles are created in /usr/local/share/d2x-xl, or /usr/local/share/d2x-xl/profiles if the latter folder exists and does already contain player files.

xstatica,

a tad late - you can always add trackers via d2x.ini. Thx for the info, btw.

I ran it as root. It worked, and it is beeeautiful!

Only problem is that while I am in any menu, the memory taken by d2x-xl keeps growing. As soon as I enter the game, the memory usage stays same. But as soon as I exit the game and enter the main menu, the memory usage starts growing again.

Update: All in-game menus have the same problem. Even the little menu that asks \"Abort game?\" and lets me choose between Yes and No. The memory usage grows continuously, by the second, even when I don't do anything.

I will check this.

Edit:

The memory code does not constantly allocate memory.

Compiled 1.5.125 source. Went perfectly, no problems.

Then, running the binary, the memory hog problem is still there. This is a part from /proc/6773/smaps (the d2x-gl process):

0813e000-196d3000 rw-p 0813e000 00:00 0 [heap]
Size: 284244 kB
Rss: 247736 kB
Shared_Clean: 12 kB
Shared_Dirty: 4980 kB
Private_Clean: 0 kB
Private_Dirty: 242744 kB

How can I know whether I am using the new or the old menu style?

New menu style displays the menus (except the main menu) on a blueish background with a blue frame.

I can only repeat what I said: Once D2X-XL is done allocating what it needs for a menu, it doesn't malloc any code it wouldn't release if it doesn't need it any more. There's one instance where the text display function allocates a temporary buffer, but that buffer always gets released. It could only be that that function doesn't work properly on your Linux distro. You can grab the alternative source file from my Descent site, unzip it over your D2X-XL source installation, recompile and see whether that helps you.

I just compiled 1.5.125 successfully, after a bit of a nightmare getting 1.5.121 to work.

AND.

I got MIDI working.

Of the .121 experience, two patches were still needed to get .125 to work.

First. My drivers don't allow #define RENDER2TEXTURE 2, but do allow it to be 1. However, when RENDER2TEXTURE is 1 and you aren't on Win32, a syntax error hits you in camera.c:
Getting MIDI working kind of involves some fiddly bits with Timidity and SDL_mixer, but those aren't bugs, with one exception. The HMP-to-MIDI converter misreports the resulting MIDI as Format 0, when it is actually Format 1, and Timidity happily interprets the resulting file as about three seconds of silence. This is another one-line fix:
General squeeing over the project is presumably for other threads, but if not, consider that happening in the background.

Wow! Thank you very much, your input is very much appreciated, particularly regarding midi support.

I will fix the compile error, too.

About the memory hog problem. The cause of it is probably not in the menu code. Whereas displaying the in-game help (by pressing F1) caused a hogging speed of about one megabyte in two seconds, the credits screen (accessible from the main menu) made a record of 22 megabytes per second.

I really wish I could use some kind of debugger, to see which function causes these allocations. The problem could be related to libSDL or the X.org's mga driver. First problem is, I am unable to compile the game (linux source 1.5.127) with ./configure --without-opengl. The result is:

if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I ../include -I ../main -I ../arch/linux/include -I/usr/include/SDL -D_REENTRANT -pipe -O2 -Wall -Wno-char-subscripts -MT bitmap.o -MD -MP -MF \".deps/bitmap.Tpo\" -c -o bitmap.o bitmap.c; \then mv -f \".deps/bitmap.Tpo\" \".deps/bitmap.Po\"; else rm -f \".deps/bitmap.Tpo\"; exit 1; fi
bitmap.c: In function `gr_free_bitmap_data':
bitmap.c:340: error: structure has no member named `bm_frames'
bitmap.c:341: error: structure has no member named `bm_frames'
bitmap.c:341: error: structure has no member named `bm_frames'
bitmap.c:342: error: structure has no member named `bm_frames'
bitmap.c:343: error: structure has no member named `bm_curframe'
make[2]: *** [bitmap.o] Error 1

Also, I am unable to get commandline help from d2x-xl. It'd help me to see how to disable OpenGL or music or sound, like I could with original Descent or d2x 0.2.5

You cannot compile w/o OpenGL. To enable debugging, './configure --enable-debug=yes --enable-release=no'\".

How do you check memory consumption on Linux (Task manager like program?)

There's no memory hogging at all on WinXP.

To chech memory consumption under linux, I run a program called 'top' in a terminal window. From another terminal windows I run d2x-xl. This would look better with a fixed width font.

top - 19:10:51 up 3 days, 1:33, 13 users, load average: 0.20, 0.39, 0.48
Tasks: 127 total, 1 running, 124 sleeping, 1 stopped, 1 zombie
Cpu(s): 0.8% us, 0.1% sy, 0.0% ni, 98.9% id, 0.1% wa, 0.1% hi, 0.0% si
Mem: 905768k total, 421912k used, 483856k free, 8732k buffers
Swap: 1941368k total, 179428k used, 1761940k free, 122508k cached

PID RES SWAP %CPU TIME+ COMMAND
23914 84m 63m 0.8 331:48.68 X :0 -auth /home/jaakko/.serverauth.23896 -deferglyphs 16
11155 46m 229m 0.0 0:04.78 ./d2x-gl
23328 44m 73m 0.0 14:34.30 /usr/lib/mozilla-firefox/firefox-bin
11053 22m 198m 0.0 0:02.34 java_vm

I'll try building with debug enabled.

I am running a loop in newmenu.c and I have breakpoints at lines 3686, 3693, 3697 and 3731. The allocations happen between 3693 and 3731, both before and after the break at 3697.

Those lines come and go in an infinite loop, until I choose the pilot. Is this the way it should go?

I have two pilots. Lines 3704 and 3711 are in a loop that is repeated 5 times until 3731 is reached once. Within that loop there is no malicious allocations.

After the break at 3698, there is one malicious allocation before 3704 is reached.

The problem has to do, at least in part, with gr_rect or gr_string at 3729 and 3730. Nothing between 3718 and 3728 causes bad allocations.

_sd,

get the 1.5.127 source and compile in debug mode. All allocation should be done via a function named mem/mem.c::mem_malloc().

Ok. It took me this night to figure out what is debugging and how to use a debugger. Going to sleep now, and will try that tomorrow. I knew it had to do with the placement of the breakpoints.

A debugger is a program that can execute another program 'step by step' (i.e. assembly instruction by assembly instruction, or source line by source line). Good assemblers allow not only to set breakpoints, but also to examine the state of the programs variables and see the chains of function calls. Really good debuggers have a comfortable GUI.

What you can do here is to set a breakpoint on mem_malloc() once the menu code is being executed and check whether it's called at all, what code calls it, and whether the corresponding mem_free() calls are being made.

The memory hogging allocations are not done through mem.c's mem_malloc. Either some part of the code (probably in font.c) do allocations some other way, or there is a leak in X's drivers or the SDL library.

mem_malloc doesn't get called at all after the pilot selection menu has appeared.

Update -- All the leaks happen in ogl.c:ogl_loadtexture

Update 2 -- The guilty call is one of these two (lines 1042 to 1045 in ogl.c):

// Generate OpenGL texture IDs.
glGenTextures (1, &tex->handle);
//set priority
glPrioritizeTextures (1, &tex->handle, &tex->prio);

It must be glGenTextures() then. I have checked that code though, and at least on my system (both OpenSUSE 10.0 Linux distro and WinXP pro) the textures are freed immediately when they're not needed any more (the caller here is ogl_ubitblit_i(), which generates a texture, renders it, and then frees it). I think your gfx driver might be to blame here.

I'm given to understand you got the HMP->MIDI converter from somewhere else, so I imagine this is extremely low priority, but for the record, the HMP->MIDI conversion is still pretty badly bugged on Descent 1 tracks.

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.

The D2 tracks seem reasonable (though I haven't played them as much) so this might be a D1/D2 thing.

McMartin,

your post isn't particularly helpful. Feel free to investigate in the issue and come up with a solution. The source code is available on my D2 site.

FYI: The background sound is not midi, it's a 11 khz sound effect that gets resampled to 22 khz.

Diedel wrote:FYI: The background sound is not midi, it's a 11 khz sound effect that gets resampled to 22 khz.

If you're talking about the sound I think you're talking about, there are no Class 1 Drillers on lvl. 2.

McMartin wrote:Getting MIDI working kind of involves some fiddly bits with Timidity and SDL_mixer, but those aren't bugs, with one exception.

Could you explain what you did to get midi working? I already have a functional Timidity, the sdl mixer libs, and D2x XL 1.5.128--which I believe should have the D2x-side of MIDI taken care of at least.

1.5.128 Linux has a bug in hmp to midi conversion. Get 1.5.130.

Diedel wrote:McMartin,

your post isn't particularly helpful. Feel free to investigate in the issue and come up with a solution. The source code is available on my D2 site.

Yeah. I tried to phrase it in the "this isn't a fully solved problem yet, oh well" level, as opposed to the "zomg fixplz" level.

I'll take a look when I can, but I've got an awful lot of other stuff on my plate at the moment. If anyone else wants to swoop in and come to the rescue, I won't mind

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'
collect2: ld returned 1 exit status
make[2]: *** [d2x-gl] Error 1

I just compiled it w/o a hitch. Btw, I have made a small update to v1.5.132, so you may want to re-download it.

gunzip: d2x-xl-src-1.5.132.tgz: unexpected end of file

File size 593920 bytes

Not a partial download. I tried refreshing the webpage, redownloading the file, and downloading the file with another browser. But it was always the same file. I'm not using proxies.

Update - It's ok now! (the file - the linker error is still there)