Basic Linux Port for 1.0 #161
Conversation
|
Thank you for your efforts. I will go through this when I can, though it might be after the holidays. |
|
I plan on tackling Linux support after the holidays, so I will go through this and pick it up then. Thanks again for everyone's efforts. |
|
Nice work, @mlauss . I had no problem compiling it and music also plays with the software synthesizer. I didn't notice any issues so far, with exception of green colors caused by my Intel HD4000 I guess, even with the latest mesa driver, which can however be fixed with changing the values in fraq shaders files. But I get some issue with the mod. One more thing, when exiting the mod (via the game or TFE menu), I get the segmentation fault. |
|
Hi,
I don't see your problem with the Dark Tide 1 Mod -- in the Agent Menu,
after a lot of cutscenes, I see a single entry
"Wasteland Survivor", and it plays just fine. I suggest you start with a
fresh installation of DF, without any
changed file cases, etc. That's what I do tests on.
I know about the segfaults, I'll try to debug it with valgrind in the
coming days.
Manuel
…On Sat, Dec 24, 2022 at 5:23 PM spacekomet ***@***.***> wrote:
Nice work, @mlauss <https://github.com/mlauss> .
I had no problem compiling it and music also plays with the software
synthesizer. I didn't notice any issues so far, with exception of green
colors caused by my Intel HD4000 I guess, even with the latest mesa driver,
which can however be fixed with changing the values in fraq shaders files.
But I get some issue with the mod.
I've tried playing Dark Tide 1 mode, and there I've noticed I get agents
and mission list in the agent menu from the main game and not from the mod.
If I then choose mission one (Secret Base) the mod starts.
Strangely enough, correct agent menu is displayed using older linux port
(however, mod was not even playable with that one, because it just froze
when trying to pick first shield pack at the beginning, probably not all
files were loaded due the name casings).
One more thing, when exiting the mod (via the game or TFE menu), I get the
segmentation fault.
And during the gameplay I get a lot iMuse errors:
[DEBUG] [Error : iMuse] ERR: Illegal chunk in sound 984383974039136...
—
Reply to this email directly, view it on GitHub
<#161 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPAG5B7Y7J23OJQ2O5Z5H3WO4PO3ANCNFSM6AAAAAATGVFDQE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I can confirm that this is working in Linux Mint. Only problem I've had is my desktop will crash if I alt+tab while the game is running. Weirdly, Mint just kicks me back to the login screen after closing my apps. |
|
Wanted to throw in that I've also gone through and done a fresh 1.0 port using upstream, I'll take a look at this later and see how much parity there still is. One thing I did differently was extract ImGui and use a copy of that from the package repos. Worth noting that introduces a few caveats:
One curious matter is TheForceEngine uses the method linked here ocornut/imgui#1167 (comment) However, I can't seem to find this anywhere in the copy of ImGui in Debian's package system. That could point to Debian having an older version or otherwise this being non-standard, but just bringing this up as this does have implications for portability. Is there a reason all the dependencies are static by the way? As visible in the Makefile, I kinda stripped all those out of the Linux build, opting to shared libraries on the host machine instead, which at the time at least appeared to work. If there are any specific customizations to these external libraries, those would present portability blocks as well. |
Maybe we can use ImGui freetype support, that should work with almost any distro out of the box. |
|
Maybe you're right, the libimgui-dev package only seems to include a .a static library. Can't say I know much about the specifics, was just combing for what dependencies could be offloaded to shared libraries or distro packages. Looks like Debian, Red Hat, and Arch all have their own packages for this. I'm not sure what "standard" practice is out there in Linux-world with imgui, but the package managers seem to suggest there are at least some attempts to distribute this universally rather than it just being an internal dependency on stuff, but what with the .a library only, not sure what they're actually achieving. In any case, the imgui_markdown project linked has to be explicitly pulled in as it isn't part of upstream nor is it in any package managers. If the project is specifically dependent on a modified local copy of imgui, of course, this all becomes moot, but if the intent is to consume imgui as it stands out there in the world, then different distros may have different opinions on what revision they ship, custom changes, etc. Thus is the landscape in Linux-world... Edit: Just to add, I've got quite a bit of pruning to do on my fork of 1.0 before it's ready to even consider merging, I don't think I'm actually going to do all of that hubbub since this PR exists. Instead, once I get a working copy, I'm going to three-way compare all of them and anything that seems to have improved in my re-port I'll try and get in a place that can merge together with all of this. |
How's stability? The code compiles now fine with gcc and clang, but any optimizations higher than -O1 generate very crashy binaries on either compiler. The memory allocator code seems most fragile. I've started trying to eliminate a lot of warnings, and sometimes just moving variables around causes memory exhaustion ... |
|
Hey, mlauss, past weekend I took your TFE Linux 1.0 repo and build it for Windows XP x86 (=32 bit) with MinGW32. Just for curiosity. Thanks. (files on my website http://www.gb-homepage.nl/ in the back ports section) |
|
Maybe related to this? |
Clean installation helped, thanks for the hint. I suspect the issue was german patch installed over the english version of the game. which changed the mission names. However, I get dumps, when I try to load (quick or normal) a saved game in the mod (Dark Tide1, didn't try with others).
Loading otherwise works fine in the normal game. |
Windows and Linux/Posix have different opinions on the length of "unsigned long" and other C types on 64bit: Windows compilers keep 32bit and 64bit identical, while they differ on POSIX. Work around this by using the explicitly sized types, and letting the compiler sort it out.
Gcc-13 no longer implicitly includes a lot of "standard" cpp headers. Add them.
ptrdiff_t in C++ should use the std:: namespace.
GCC complains about an invalid explicit specialization outside a namespace scope: filestream.h:67:19: error: explicit specialization in non-namespace scope 'class FileStream' 67 | template <> This is apparently invalid C++ which MS compiler nevertheless accepts.
On startup, screenCapture will cause random crashed because of uninitialized m_capures member.
gcc-13 is picky about preprocessor macros and VA_ARGS.
clang-15 stops build with this error:
TheForceEngine/TFE_Jedi/IMuse/imDigitalSound.cpp:61:13: error: copying variable of type 'atomic_s32' (aka 'atomic<int>') invokes deleted constructor
atomic_s32 s_digitalPause = 0;
Remove the explicit initialization.
_itoa() is a windows-ism.
found by gcc lto due to ODR violation.
Add _strlwr(), _strupr(), and aliases for strcpy_s() and sprintf_s()
- Makefile - implementations for filestream, paths. The implementation does make an effort to find identical filenames with different cases. - add a crashhandler skeleton
|
I can reproduce your save-then-load crash (startup-then-load does not crash), it's caused by the archive freeing running into some member memory corruption, specifically the first Archive* in s_globalArchives contains garbage already. With -O2 or higher, these types of crashes become more widespread, i.e the crash when the grate lifts at the start of mission 1 is also caused by corruption of an "Allocator" structure when the INF code deletes this elevator. |
There are 2 BeginChild() that are close with End(), fix that. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
When freeing items with allocator_free, at some point all members of the Allocator become ALLOC_INVALID_PTR, then allcator_getHead crashes due to trying to derefence an invalid Allocator::head pointer.
|
I just pushed a small patch which practically fixes almost all runtime crashes when building the source with GCC and O2/O3 and clang at O1 or higher. I was able to complete SECBASE with all secrets just fine. LTO does not yet work, but I'm looking into it. |
ghost
closed this
ghost
deleted the
This is a basic linux port, tested with gcc-13 on x64. It contains a few commits to fix issues which were found during testing; most of them are compile fixes for gcc which should also work on windows.
Thanks to Matthew Gilmore for the initial version, I took some code from your version as well.
The game is fully completeable, with software and hardware rendering, and with digital sound and midi music using e.g. fluidsynth. Mods work as well (only tested the "tie defender base" mod though). There's still issues with reloading a savegame during play.