A downstream Linux fork of d2x-xl

All other topics around Descent and D2X-XL

Moderators: Frustikus, simX, Aus-RED-5

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

A downstream Linux fork of d2x-xl

Postby steel01 » Mon Jun 02, 2014 3:04 pm

Most if not all people here won't have a clue who I am, so I'll give a bit of introduction first. I'm Steel01. I've been a fan of Descent for just about longer than I can remember. Been following the code since D1X and D2X were getting ported to Linux. Haven't had much reason to post anything outside of a few random things on dbb. When karx announced a few days ago that he was done with the project and not fixing bugs, I decided to try and make it more stable and standardized on the only OS I use, Linux. Now that karx is fixing bugs again, that original purpose is bunk. But I still had personal preference changes and a couple extra features I like, so I'm keeping the fork. And if anyone else plays on Linux, you might be interested in the code. I'll try to keep it up to date with upstreams bug fixes.

https://github.com/webgeek1234/d2x-xl

Main changes not upstream:
Cmake build system
Data in /use/share/descent2
RPM spec file for Fedora
Bug fix for possible rendering issues when not passing -multithreaded to an openmp build
Uses a static window title instead of changing per mission. Allows window manager rules and pulseaudio doesn't make a new profile for each mission, resetting volume for each.
FLAC support for custom music playlists and song flags
Very preliminary work on a launcher based on fs2_open's wxLauncher. Doesn't handle model or texture quality levels yet.

All this is stuff I find useful. If someone likes it, great. If not, I'll still poke at it for personal benefit. But like I say in the repo readme, this is built on the shoulders of giants. Many thanks go to karx for all his hard work. It was all worth it in my book.

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 02, 2014 8:27 pm

Hi steel,

welcome and thank you for your support already. :)

I would love to incorporate your fixes and improvement in the program's trunk, including your much improved build system.

:cheers:

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

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Mon Jun 02, 2014 8:47 pm

Cool. I'll see about splitting the more useful changes into patches tonight (this side of the pond), then you can accept or reject them on an individual basis.

The build system done properly will be a larger patch. I ripped out all the config.h references and moved the version defines. I don't know if any other OS used config.h, so I'm not certain if that's safe upstream. The version change should be safe as those are ifdef'ed already and the non-cmake builds would use the preexisting defines. It's possible to generate VC and xcode projects with cmake, but since I have neither of those OS'es, I cannot test those outputs.

But the biggest patch by far will be the warning cleanup. I don't know if I'll be able to pull those into a patch from my repo or if I'll have to redo them based on trunk. And it touched a lot of files. Even then, I had to disable the strict aliasing checks because I couldn't figure out what the aliasing was supposed to be doing...

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

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 03, 2014 12:51 am

So I can't attatch a file with extensions patch, txt, or log; but I can tar them, then attatch? :crazy:

Anywho, here's the first few patches. Got other things to do tonight and the next few nights, so I won't get to the build system or warning cleanup for a bit.

caption.patch: Don't change the window caption every time the mission changes.
flac.patch: Add flac support for -*song and -playlist. I wasn't able to figure out how to get the mod dir to load a flac file in the short time I dedicated to it. Seeing as sdl mixer already supports it and how easy the other support is, that part shouldn't be difficult. Maybe you can figure it out more easily than I can.
lightmap_folder.patch: Add support to read light and lightmap precalc data from $datadir/lightmaps. Packaging lightmaps that take forever to calculate would be nice.
thead_type.patch: Fix ugly results when not passing -multithreaded ? to an openmp build. Like earlier tonight, I was getting floating point exceptions when d2x-xl was trying to calculate something off those uninitialized variables. Then I remembered the debug build reads a different ini...
userdir.patch: Fix -userdir to work on non-Windows platforms. Makes the launcher idea more feasible when the data dir can move.

Side note: I'm getting sigsegv's on level load from 12704 that I'm not on my fork which I just merged in up to 12704. GDB says it's happening in AddFaceListItem in fastrender.cpp (84 gameData.render.faceList [i].nNextItem = -1;), but looking at the last changed date of the file, that's not the problem. Don't have time to bisect it right now, though. And the problem could very well be something with my setup and differences with the data structure of my fork.

Steel01
Attachments
patches.tar
Patches
(20 KiB) Downloaded 118 times
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 03, 2014 8:09 am

Please put the patches on SF.net; The d2x-xl project has a patches tracker there.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 03, 2014 1:39 pm

I still can't open tickets in the patches tracker. I tried to post my compile fixes there, but there wasn't a create button. I figured it was legacy and kept around for preexisting tickets. Once the permissions are fixed, you want this batch in one ticket or split?

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 03, 2014 4:36 pm

That is weird, because other people didn't have any problems with the patches tracker in the past. But you are right: The permissions for the patches tracker had been reset. Don't ask me why. It's open for authenticated SF users again now.
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 03, 2014 6:18 pm

You cannot just completely remove code features or behavior from D2X-XL just because you don't like it, like e.g. the variable window caption. It's ok for me to make it fixed on Linux, since you gave good reason to do so, but I want to keep it the old way on Windows and OS X.

The flac patch modifies the windows specifix midi.cpp. I kept that modification and modified the linux specific file accordingly.

What's the point of an extra lightmap folder? Lightmaps are created at program runtime and can change as a level changes. That's why they are in D2X-XL's cache folder, and that's what D2X-XL has the cache for. I have modified your proposition to store the lightmaps in a subfolder of D2X-XL's cache folder, and as I was on it, I have changed the program to save light data, meshes and mission states in appropriately named subfolders of D2X-XL's cache folder as well.

I cannot see the problem you are trying to fix with the thread typo patch. There are no mismatched #ifdef - #endif pairs for me.

I will modify this and other patches as I see fit.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 03, 2014 8:26 pm

Hey, I did say say much of what I have in my fork is personal preference. If you don't want those patches upstream, fine. Reject what you don't like. Likely, I'll keep them downstream, though.

The midi file in the Linux directory is not used. The make files pull in the win32 one. The Linux one won't even compile. That gave me a couple hours of trouble...

Does lightmap data change? I was under the impression that once it was precalced, it was static. It would only be be recalculated if the light map quality level was changed and that file didn't exist. So, my idea there was to precalc all D1 and D2 lightmaps and package them. So that every time I reinstall, I don't have to wait twenty minutes for a mission to load.

Mismatched was the wrong word, sorry. Misplaced is correct. Look at the openmp code path. Where is the else on the flag check conditional? That's what this patch is for. Currently the threading variables are undefined if that flag isn't passed.

I'm a big believer in open source. Hack and slash the patches however you see fit.

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 03, 2014 8:32 pm

Lightmap data will also be recalculated if a level (structure, lights) or the lightmap calculation or storage format change. However, the chances for this to happen are low.

Understood your multithreading related now patch after having taken a second look at it. Actually the threading variables aren't undefined though, as they get set in an earlier initialization stage. Your fix is nonetheless the way to go.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 03, 2014 8:39 pm

Hmmm... Okay, so how about this? I presume that the code knows how to invalidate the lightmap data. So, make the load order user cache then system lightmap folder. If the packaged file is invalid, it will get recalculated and will override the old file. But for levels that don't change much or at all (retail), packaged files could be used, greatly reducing initial load time. Would that be acceptable?

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 03, 2014 8:55 pm

steel01 wrote:When karx announced a few days ago that he was done with the project and not fixing bugs, I decided to try and make it more stable and standardized on the only OS I use, Linux.

I should probably say that on a regular base ... :think: ... looks like a good way to bring new people into the project and have a lot of bugs fixed. :mrgreen:
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 03, 2014 9:06 pm

karx11erx wrote:I have modified your proposition to store the lightmaps in a subfolder of D2X-XL's cache folder, and as I was on it, I have changed the program to save light data, meshes and mission states in appropriately named subfolders of D2X-XL's cache folder as well.

Did you happen to miss this?
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jun 03, 2014 9:15 pm

The cache folder (on Linux at least) is in the users home directory. You can't install files from an rpm there. Which user will be running the game, could be multiple users, just several problems there. I wanted a folder in the gamedir so it would be guaranteed static and installable.

The cache subfolders will be useful for sorting out all the generated files. Easier to glob out the lightmaps for packaging.

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 03, 2014 9:32 pm

This means that D2X-XL should actually have two cache folders: A game cache folder in the game data for computed data that is the same for all D2X-XL users on that machine (lightmaps, light data, meshes), and a user cache folder in each user's home folder for user specific computed data (mission states).

I need to look into this tomorrow. I am too tired right now, and that folder detection and creation code is rather complicated, plus I haven't looked into it for ages.

Return to “General Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest