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 » Sat Jun 28, 2014 1:28 am

I am not speaking against bringing the cmake project up to scratch.

I am just warning you not to expect to get a fully working OS X version out of your efforts yet. Shouldn't get long though and the code will be final. ;)

Otherwise I really appreciate your efforts. :thumb:

Once the cmake stuff has its flaws ironed out, I will try to use it together with code::blocks on Linux (still going with Eclipse since that is working well enough for now on my Linux Mint installation).
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Sat Jun 28, 2014 2:16 am

Personally I can't wait, hence my enthusiasm. :)

I've been getting my descent fix through boxer (dosbox) for a while now.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Sat Jun 28, 2014 4:48 am

*read this post as almost a blog. mainly thought dumping here.*

Well, I still haven't got to the bundle stuff yet. Got started trying to get d2x-xl to compile through mingw32 on Fedora. First problem: Fedora doesn't ship mingw32-SDL_net... Okay, fine. Temporarily (or maybe permanently on my fork) ifdef all the SDL_net stuff with USE_SDL_NET. There isn't a whole lot and seems mostly to be the mission downloader stuff. Wouldn't dream of releasing a bin without it, but I want to fix the rest of the compile problems without custom compiling the lib. Got past that. Several of the _WIN32 defines assume visual studio (fastcall, etc). Fixed by appending && !defined(__MINGW32__) to the #if line. Almost there. A couple of the _WIN32 defines really should be HAVE_TRACKIR, currently used the previous define to bypass, but will likely introduce HAVE_TRACKIR into my fork and add it to cmakelists as a user option. Well, now it finishes compiling, but fails to link. Undefined references to things like compressBound and glewInit. Seriously? Those are in zlib and glew and cmake is giving you -lz and -l/path/to/libGLEW.dll already... Oh, well. I got a ways tonight. Guess I'll stash the changes to clean up next time I have time, then I'll commit them anyways. Cleaned up CMakeLists.txt a bit in the process. Won't hurt to have an additional compile path even if it doesn't finish correctly yet.

Side note: I forgot to directly mention earlier: d2x-xl does compile and run on clang under Linux, even on upstream. It just doesn't have openmp. It seems to run as well ingame as a gcc builld on my machine (FX 9370 @ 4.4 GHz / 16 GB ram @ 1866 / GTX 760 2GB), but that's not saying much with that much overkill. I cleaned up a bunch of warnings on my fork, but I'm still vetting the correctness and viability of all of them. It appears I broke effects somewhere along the way. I see light from the effects, but no effects such as lasers or shields or explosions. Works correctly on the equivilant upstream svn commit. At least the problem should be quick enough to find now that I scripted a way to see a useful diff between my fork and upstream. But it'll probably be a few days before I can sort through it.

Okay, now I'm really confused... Tried to compile with mingw64 and got different link errors... *tweaks a couple things* It linked... *tries 32 bit again* It failed. Ummm... Now I'm really confused. I installed the exact same libraries for 32 and 64. Like literally with regex. 'yum install mingw{32,64}-$lib'. :strange: Whatever. I'm going to bed. Poke at it more later. Though, I guess since it built, I'll want to borrow someones m$ box and see if it runs. And how many mingw dll's I'll want to change to static linking...

Steel01

Edit: So much for the going to bed part. Found the rendering bug and pushed a fix to my fork. Now I've got to find a way to handle that class copy correctly without a memcpy. By all rights, c++ code shouldn't ever use memcpy. That's what assignment and copy constructors are for. But I'll have to look at it later.

Edit 2: A clang build runs fine now. But it caused me to notice something really odd. And I confirmed it on a gcc build. D2L1 with multithreaded off loads for me in about 2 seconds. With multithreaded 6, it takes 15-20 seconds. I was thinking missions were loading too slow for my hardware, now I have a narrowed down place to look. I'll do some more tests when able and open a bug report if the problem is still around then.
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 28, 2014 8:51 am

Which class' instances are memcpy'd?

Iam using SDL_net for its TCP/IP functions.

D2X-XL once had all multi-threading implemented via SDL. I could make that work again.

Regarding physfs: I once tried to use it, but since my host dev OS is Windows, I couldn't find a useable windows lib for it.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Sat Jun 28, 2014 1:10 pm

CTranspItem in transprender header and source. In the header, it's the assignment operator. I haven't seen any adverse effects in just removing that and letting the built assignment work. The source file (around 870, memcpy (ph, item, item->Size ());) didn't work so well. I tried to replace the buffer alloc and that memcpy with a standard allocation (CTranspItem *ph(item);) and it broke effects horribly. Guess that's what I get for not seeing what allocItem actually does. *whistle*

So, if SDL_net was missing, would multiplayer still work, just without things like autodl? I'll see if I test that mingw build somewhere.

I don't know that it's terribly important. The largest use case would be the xcode builds where clang is the only available compiler like darklord42 says. If those macs are powerful enough to handle rendering single threaded, it might not be worth the time and effort. Then again, alternatives are nice for those random corner cases people (like me) tend to come up with.

The main reason I want physfs is better mod support. Are you familiar with fs2_open's mod system? Ingame has no concept of mods, it's all handled by a -mod $folder command line param. Physfs can take that and prepend it to the folder list and everything would automatically work. Having seperate mod folders changable at runtime would allow for mod chosen command line params such as custom wallpapers (Pumo Mines theme?), different intro videos, etc, etc. Plus the code checks for any single file would be so much simpler. Give me x.file instead of x.file in mod folder, mod hog, cache folder, static folder, etc.

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 » Sat Jun 28, 2014 1:23 pm

steel01 wrote:So, if SDL_net was missing, would multiplayer still work, just without things like autodl? I'll see if I test that mingw build somewhere.
[/quote
Yes it would.

steel01 wrote:The main reason I want physfs is better mod support. Are you familiar with fs2_open's mod system? Ingame has no concept of mods, it's all handled by a -mod $folder command line param. Physfs can take that and prepend it to the folder list and everything would automatically work. Having seperate mod folders changable at runtime would allow for mod chosen command line params such as custom wallpapers (Pumo Mines theme?), different intro videos, etc, etc. Plus the code checks for any single file would be so much simpler. Give me x.file instead of x.file in mod folder, mod hog, cache folder, static folder, etc.

The problem is that the same file can be present in different folders, and certain folders take precedence over others.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Sat Jun 28, 2014 2:16 pm

That's the purpose of physfs. It's a virtual filesystem. The virtual texture folder could have the mod, cache, and static real folders mounted to it. If files overlap, the one from the highest priority folder will be exposed. The only nonstandard handling would have to be the hog files versus hires. Everything else will be handled by physfs.

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 » Sat Jun 28, 2014 3:11 pm

I have briefly read into the physfs doc - not enough though to find out about the possibility of prioritizing folders.
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 » Thu Jul 03, 2014 1:29 am

steel,

it looks like you broke the tracker detection with your type cast patches. :rage:
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Thu Jul 03, 2014 1:54 pm

Oops. Well in my defense, I did say I couldn't test the multiplayer stuff when I mentioned the patch. Was the problem in the is_tracker parameters? I remember having to twist those a bit more than the rest. Now I need to go find your fix and see what I did wrong...

I haven't had much time to even think this week, much less play or work on games. Earlier, I cleaned up the cmake lists file a lot and started to verify the mingw changes and splitting out the HAVE_SDL_NET ones. I'm leaning toward making those a compile time patch in one of my scripts instead of actually committing it since I don't have the time to find out how to truly disable the functionality that could remove. So yeah, one of these days I'll have you an updated cmake file, but it might not be this week or next. The one you merged works perfectly fine for Linux, though, if you want to poke at it and code blocks. Warning though, the cmake generated project looks like a generated project, fine for quick fixes and referencing, but not well suited for multi-target development. If you like it and continue to use it, you'll probably want to manually create a project with proper targets and all.

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 » Thu Jul 03, 2014 3:37 pm

I think you omitted a "+ 4" in one place.
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Thu Jul 17, 2014 8:22 pm

Finally made time to get back to this. I think I have the cmake osx and mingw stuff about ready to submit a patch. I spun my own SDL_net mingw rpms for fedora, so I don't have to do those ifdefs anymore. It compiles fine for 64 bit but still linker errors on 32 bit. I'm not convinced that's not Fedoras fault at this point. If darklord42 is still around, I'd like to make sure my fork still compiles on osx. Still don't expect it to run, but as long as it compiles, the fixes for the xcode project should slip into place for a cmake build as well. How is that osx support going? I saw a few commits that direction.

In other news, I've greatly simplified my merge from upstream process and my upstream vs. fork diff script. I might post the whole diff for karx to glance through later. I think there might be a few things in there you'll want to apply, though most of it you won't care about.

Steel01
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 12:05 am

Hey steel, nice to have you back. For some reason it's asking for the windows.h again when I type in make. I thought we added the apple deff to the cmake file..
[EDIT]
Ah i see you have it as.

if (!IS_WIN32)
add_definitions(-DKALINIX)
if (IS_APPLE)
add_definitions(-D__macosx__)
add_definitions(-D__unix__)
endif ()
endif()

since it's not win32 that part must be ignored..

But on the plus side, once i put it in myself it finishes compiling. The binary throws up the error on missing d2x-xl files, which is definitely a good thing. (little large, bigger then my screen) I wonder where it expects these files, and if i can put it in a app bundle. I'll have to play with it later.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 1:27 am

Hmmm... I'm too spoiled by things like bash that parse like c/c++. (!IS_WIN32) isn't the proper syntax apparently. I want (NOT IS_WIN32). Good catch. Try my master branch now.

Oh, I forgot about the app bundle stuff. :? Oops. I'll poke around that before I submit a patch upstream. If it lists the files it's looking for, can you post a list, so I have an idea what the resource builder should be pulling in?

Can you compile the xcode project from karx's svn? His post here makes it sound like something should work in OSX now. But it still needs testing. If you can compile that, you can help him test and get me a list of all the files that end up in the resource bundle.

Steel01
Last edited by steel01 on Tue Jul 22, 2014 2:39 am, edited 2 times in total.
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 2:29 am

I'll give a try for jokes, though I'm sure it isn't done yet :)

As to creating a bundle, it's more then bringing in all the files into an organized bundle. we will have to use the install_name_tool (which comes with xcode) to relink the binary to the copied frameworks (libraries) in the bundle.

Should all be pretty easy to do with a shell script.

I'll give a crack at it tomorrow see where we stand.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio

Return to “General Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest