A downstream Linux fork of d2x-xl

All other topics around Descent and D2X-XL

Moderators: Frustikus, simX, Aus-RED-5

User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: A downstream Linux fork of d2x-xl

Postby karx11erx » Mon Jun 09, 2014 5:42 pm

I have my d2x-xl Eclipse project up and running on my fresh Linux installation, and I have fixed a huge bunch of warning message there, but when I tried to commit them using Eclipse's Subclipse plugin, I got an authorization error, and I just cannot make Subclipse ask for the proper credentials. So I may be forced to use the svn command line to commit the changes from my Linux box. :wallbash:

I have already asked about that on Stackoverflow.

Linux really is a PITA. I am fighting for every inch here for three days already. :rage:

...

As far as you liking my idea goes: When I do something, I tend to do it right. ;)
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Mon Jun 09, 2014 8:28 pm

My response to the general Linux comments is in the other thread.

An semi-offtopic question. But kinda on topic since I'm packaging (albeit only locally atm) it. I'm pulling all the assets I can find and putting them in rpms. Originally this was based on the Linux install script in the svn repo. Now, I'm pulling meta archives, but not certain if they have everything. Relative to your download folder, I'm pulling:

models/hires-models.7z
models/ship-phantomxl.7z
models/ship-wolf.7z
textures/D1-textures-512x512.7z
textures/D2-textures-512x512.7z
sound/hires-sounds.7z

Is that a full set of assets? Then some cleanup comments. The data package needs updated for the new sound directories. The models archive has the bullet model which is part of the main data archive. Same with sounds and afbr_1.wav and the d2x-xl folder. The sounds archive also has several empty folders that shouldn't be there. And one last question. Can the 256x256 textures be used without the 512x512 being installed?

Steel01
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: A downstream Linux fork of d2x-xl

Postby karx11erx » Mon Jun 09, 2014 10:01 pm

The hires models archive has the additional player ships already.

I updated the data package today.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Crash cause found

Postby karx11erx » Tue Jun 10, 2014 12:50 am

I found out why d2x-xl crashes in FastRender on Linux. An important buffer only got allocated when the program was compiled with Oculus Rift support. The updated source code is in the repo. I was still having problems with lightmap based lighting (very dark), and the program hung in a multithreaded part of the code.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 10, 2014 1:00 am

I did miss that the phantomxl is in the models archive, but the wolf is not. Looking through the texture stuff, the old general textures are not in either of those (the archives not previously prefixed by D#-hires-), eg effects, recticles, keys, etc. Also, the new data archive is awol. The link I presume has a typo pointing to 1.16.34 instead of 1.17.34, but the latter doesn't resolve either.

Yeah, I was wondering if it was supposed to be that dark. Was starting to think that was part of the experience. :P I just pulled your latest code and it recalculated the lightmap for D1L1 for some reason, then segfaulted. Will report back after tracing (doing several things at once atm). I don't think you meant to commit the merge conflict in sixense.h :wink: But stuff still runs in my branch. After merging stuff from upstream too. I'm really starting to get curious as to what I changed that fixed all that. I probably did have the rift part fixed due to warnings, so that was that part.

I have some sound problems right now in d2x-xl as well. Saw this earlier, then it went away. When the volume passes a certain threshold, sound get crackly, then cuts out. When things quite down, sound comes back. I'm not certain that's not a problem with pulseaudio, though. So, I'll be keeping an eye on that. Hopefully it is just something my side.

Steel01

Edit: Yeah... for some reason I didn't pull the change where you #ifdefed out the renderdata::create. Difference 1 figured out. Now to figure out what else is different on level load...

Edit 2: Couple more things to note. I should have remembered to mentioned this before , but I forgot. The fx sounds aren't scaling to the volume slider. Whether the slider is at 1 or 9, it's always the same (9, I believe). That could be why the sound is clipping for me, it really is too loud... Haven't tried to track that part of the code down yet, though. Second, the last mission field in descent.cfg is too short now with the prefix on them. Descent: First Strike or Descent 2: Counterstrike won't fit and thus don't get autoselected in the new game menu.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: A downstream Linux fork of d2x-xl

Postby karx11erx » Tue Jun 10, 2014 8:45 am

Sound not working right is a typical sign of hires sounds not being loaded (maybe not even present). That's why installing them is mandatory. D2X-XL tries to resample the original sounds when loading them, but at one point in time this stopped working: The resample code hadn't changed, but SDL_mixer suddenly didn't like the resampled sounds.

sixense_wrapper.h fixed. Funny that this compiled on my Win7 system.

Fixed the data archive link.

Hires textures archive fixed and updated.

Hires models archive fixed and updated.

I think D2X-XL will now recalculate lightmaps with every new program version. That might be a bit too restrictive though.

Afaik d2x-xl doesn't use descent.cfg (need to check though).

Please try to build d2x-xl as a single threaded application on Linux. I dimly remember having changed my build system to do that too because of problems with the g++ generated OpenMP code.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 10, 2014 7:12 pm

Wow, busy morning. First chance I've had to post.

I'm fairly certain all the sound files are available. The 44khz dir is detected as $staticdir/sounds/d2/44khz. That dir has all the files from your recent hires-sounds.7z upload. I'll do some more checking as I'm able. I still think the digi volume thing is a problem, though. I'd like to turn that down so I can more precisely control the volume through pulseaudio.

The data archive link is still broken. The models archive still has the bullet model. The D2 textures archive has most tga's in the mid level textures folder. It also has the textures contained in the data archive. The D1 archive has random BMPs and the D2 one has a jpg. The sounds archive hasn't changed, so comments from last post still apply. Of course, all but the first only really matters if you want to keep files unique between the archives. I can fanangle my script to clean stuff up as I'm packaging.

Yeah... That is extreme. Makes packaging light maps nigh infeasible.

I don't know about cfg. But i do know a longer name doesn't get preselected in the new game selection. Vertigo works, Counterstrike doesn't.

Hmm... I'll try single threaded, but I really hope that isn't an issue. I know plenty of openmp programs working on Linux. And outside of the aforementioned sound problem and some cosmetic things, my branch is running fine. With openmp enabled.

Steel01
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: A downstream Linux fork of d2x-xl

Postby karx11erx » Tue Jun 10, 2014 7:34 pm

I completely recreated the D2 512x512 texture archive from the partial D2 texture archives (rock, metal, etc.), so it should be complete. It's actually considerably bigger than the old one (200 MB vs. 166 MB). The add-on are in the game archive because unlike the other textures they are required by d2x-xl. Same goes for the bullet model. Having them will help rather than hurt.

Program bugs belong to the bug tracker of the d2x-xl project on SF.net, not here.

Fixed the data archive link. Actually it had been working, both the archive and the link just had a wrong version number in the name.

You are having a way of making me spend way to much time with this.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 10, 2014 8:50 pm

*shrugs* I was saying they were duplicate in the addon archives. I'm packaging everything in the data archive as part of the main executable package. The addons are in separate upgrade packages and I don't want any conflicts with the main package. But like I said, I can do cleanups in my script as long as those archives don't change very often. Just thought you might want to clean the archives up upstream.

Okay, I'll do that for the sound and mission preselect problems sometime. I'm mentioning stuff here first because I can't guarantee it's not a Linux specific problem or something I caused myself.

Here's where I hate to sound like a broken record, but... If I click the data archive link on the d2x-xl page, I still get sent to the downloads page.

Heh, sorry. Any time you want to call it, go ahead. I'll continue on my branch. Until then, I'll keep reporting stuff and trying to improve the Linux experience. At least until I run out of steam. Which I guarantee will happen, just can't tell you when.

Steel01
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: A downstream Linux fork of d2x-xl

Postby karx11erx » Tue Jun 10, 2014 9:23 pm

Accidentally uploaded a rar instead of a 7z file ... :away:
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Fri Jun 13, 2014 3:41 am

And finally got a chance to get my hands on my gaming machine for a few. Yay, back to testing. Oh, and all the archives are available and I can use them after a bit of scripted scrubbing to generate rpms.

Found part of my sound problems. The hires_sound param doesn't default quite like I expect it to when the param isn't given. Somehow on D2 levels, it defaults to on. Looking though the code, I'm not really certain how. But on D1 levels, it defaults to off. So, added the param and let it default to 2. Sound seems to work as expected now. But now I don't think hires textures are loading on D1 levels. Not 100% sure on that though, might be textures missing from the pack in the opening hallway of D1:L1.

I'm getting loads of model texture errors now. Like:

Code: Select all

pyrogl.ase: error in line 50 (texture not found)

Could be related to:

Code: Select all

looking for folder '/var/cache/models/' ...failed
trying to create folder '/var/cache/models/' ...failed
looking for folder '/home/klingac/.d2x-xl/models/' ...found

But I doubt it, since the textures are in the static dir.

Okay, I can fix the folder errors. In gamefolders.cpp on lines 352 and 353, var.szCache gets clobbered if the check above succeeds. Then on line 369, mod.szRoot gets primed from var.szRoot instead of var.szCache. However, I still get the texture not found errors. Even though it appears the model texture gets loaded. :crazy: I'm also getting animation errors in groups like:

Code: Select all

loading mod data (state 1)
couldn't find animation for 'misc060#0'
couldn't find animation for 'misc060#1'
couldn't find animation for 'misc060#2'
couldn't find animation for 'misc060#3'
couldn't find animation for 'misc060#4'
couldn't find animation for 'misc060#5'

The texture is there and animating fine, though. And I don't have any mods for D2 and the box isn't checked. So, maybe the last one is part of the memory problems because it's trying to overload stuff? *shrugs*

Side note/question: Is the shader dir needed anymore? I removed it in my branch since it didn't seem like it ever got used. Now the folder check and creation complains every time because the dir isn't there and can't be created.

And that's it for me tonight. It's getting a lot closer. Upstream doesn't exit out on level load anymore for me, that's a plus. Still not certain what caused that. The new logs help track down missing files (like one I missed in packaging). Good work, keep it up.

Steel01
User avatar
Weyrman
D2X-XL Expert
D2X-XL Expert
Posts: 579
Joined: Tue Sep 25, 2007 7:47 pm
Location: Brisbane Australia
Contact:

Re: A downstream Linux fork of d2x-xl

Postby Weyrman » Fri Jun 13, 2014 5:10 am

steel01 wrote:I'm getting loads of model texture errors now. Like:

Code: Select all

pyrogl.ase: error in line 50 (texture not found)



Just as a side note I also got these errors in the windows .35 log
-SYSTEM SPECS-
MBoard:"GigaByte Z68X-UD3H-B3" Motherboard
CPU: Intel i7 E2600 3.40GHz
RAM: 8GB DDR3 2133MHZ
HD: WDC 10EARX 1TB SATA
Video: GigaByte 1G ATI 4890
Monitor: Asus VS428 LCD 24"
Sound: Onboard - now with connected 5.1 sound system
OS: Windows 7 x64 Home Premium
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: A downstream Linux fork of d2x-xl

Postby karx11erx » Sat Jun 14, 2014 6:20 pm

That bug should be fixed now.

Regarding the cmake file: I am having a .cproject file for Eclipse. Isn't that what your CMakeList.txt / cmake would create? If so, shouldn't my .cproject file work for code::blocks, too?
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Mon Jun 16, 2014 3:43 pm

And one crazy busy weekend later, I'm able to reply.

Cmake will generate project files for whatever you tell it to. A list is here. Codeblocks uses it's own project file format, not anything eclipse or any other program would use.

Steel01
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Thu Jun 19, 2014 3:57 am

Wow, it's been busy of late. I didn't have a whole lot of time to test stuff at my gaming box, but I did notice one thing. Since the last time I updated my branch (circa 1.17.35), custom ingame music stopped working. Menu and briefing played my flac's fine, but in mission it fell back to game01.hmp, instead of using my -playlist parameter. I confirmed it against a quick build from your svn as well. And consequently, I'm very grateful for the prerendered flacs. That midi rendering sounds terrible in comparison... If you don't find the problem before I have time, I'll hunt down the bug and submit a patch. That could well be well into next week, though. It also seems my D1 hires textures aren't loading still. I'll have to track that down too.

In other news, I finally sorted out the strict aliasing warnings. I don't know if unions is the best way to fix that, but I couldn't find any other way to make gcc happy. The commit to my branch is here, if you want to take a look. I haven't had time to package it into a svn patch yet. The problem is gcc doesn't like to dereference a cast pointer. After some googling and stack overflow reading, I see that appears to be undefined behaviour according to the c++ standard. I didn't notice any problems related to the changed files loading into a mission tonight, so I think the concept works. Don't have anyone to test multi with, so I'm not certain of that part. In any case, I believe the first change to network/multi.cpp is a typo correction. GET_INTEL_* appears to only work with pointers and that passes a dereference.

Steel01

Edit:
I suppose I should make some comments like this. All needed folders loaded right up perfectly. The only folder that failed was the static shader folder which I don't create. Like I mentioned above, I haven't seen where it's needed. Have I missed something there? I do like the change where the log is now in the user folder instead of the home directory. Makes more sense there. And saving the last log is also useful. The blinking loading menu popup is different, but I think I'll grow to like it. The usabilty on Linux has come a long ways in the last month or so.

Just noticed that I'm still getting the couldn't find animation block of errors. Have you seen those or am I the only one?

Return to “General Discussions”

Who is online

Users browsing this forum: No registered users and 4 guests