New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux Bits for 1.02 #201
Linux Bits for 1.02 #201
Conversation
Hey, what did you do with the Music? It's a lot more full and richer now. :) However, in the TFE Sound menu, I can see and select only one midi device. There is also this annoyance still with the browse functionality in the TFE Game menu. For me (Manjaro, KDE Plasma) nothing happens, when the browse button is pressed. |
Try my "linux3-audio-next" branch. You can switch midi devices on the fly there, I regularely test with timidity and fluidsynth side by side (timidity sounds much better, tbh).
Huh, the version of Portable File Dialogs shipped with TFE probably doesn't know how to handle this on Manjaro. |
With the same soundfont timidity indeed sounds slightly better (btw: I simply running it with -iA parameters) And with linux3-audio-next I'm able to change the audio ports, great. I should mention also there is this old annoying shader issue, which it seems I'm the only one having it. Workaround for me is, to change the fraq files in Shaders folder (walls, sprites and quad), otherwise I get green walls, stormtroopers and also rocketlauncher and fist weapons. Not really related to the linux port, more to my hardware it seems. |
I had to read the the code to get this information. It should be mentioned in the README that either "zenity" or KDE are required for file dialogs as a runtime dependency once TFE has official linux support.
Excellent,
This looks like an issue with mesa driver for GT7 and older hardware. I suggest you open a bugreport on Mesa and give as much information as possible (I do have a Haswell (GT7.5) machine to test on, and it works well there). |
Seems the same situation as the last PR is still happening with this branch on my system, so I can't really say much by virtue of it not even exiting with a message. |
Happy to see a renewed branch! |
@Agetian executable As mentioned in previous PR to this one, the program output worked before in the first Linux draft PR. |
That is strange, it means it's already erroring out somewhere in the first 10 lines if main(). |
please apply the following patch so we can narrow it down a bit: diff --git a/TheForceEngine/TFE_FileSystem/paths-posix.cpp b/TheForceEngine/TFE_FileSystem/paths-posix.cpp
index fd92141d..e1001446 100644
--- a/TheForceEngine/TFE_FileSystem/paths-posix.cpp
+++ b/TheForceEngine/TFE_FileSystem/paths-posix.cpp
@@ -58,7 +58,7 @@ namespace TFE_Paths
if (!home) {
// whoa, how did that happen?
- TFE_System::logWrite(LOG_ERROR, "paths", "$HOME is undefined! Defaulting to /tmp");
+// TFE_System::logWrite(LOG_ERROR, "paths", "$HOME is undefined! Defaulting to /tmp");
home = strdup("/tmp");
}
diff --git a/TheForceEngine/main.cpp b/TheForceEngine/main.cpp
index 66df02dd..946d28a4 100644
--- a/TheForceEngine/main.cpp
+++ b/TheForceEngine/main.cpp
@@ -513,11 +513,16 @@ int main(int argc, char* argv[])
TFE_CrashHandler::setThreadExceptionHandlers();
#endif
+printf("1\n");
// Paths
bool pathsSet = true;
+printf("2\n");
pathsSet &= TFE_Paths::setProgramPath();
+printf("3 %b\n", pathsSet);
pathsSet &= TFE_Paths::setProgramDataPath("TheForceEngine");
+printf("4 %b\n", pathsSet);
pathsSet &= TFE_Paths::setUserDocumentsPath("TheForceEngine");
+printf("5 %b\n", pathsSet);
TFE_System::logOpen("the_force_engine_log.txt");
TFE_System::logWrite(LOG_MSG, "Main", "The Force Engine %s", c_gitVersion);
if (!pathsSet)
@@ -525,6 +530,7 @@ int main(int argc, char* argv[])
TFE_System::logWrite(LOG_ERROR, "Main", "Cannot set paths.");
return PROGRAM_ERROR;
}
+printf("6\n");
// Before loading settings, read in the Input key lists.
if (!TFE_Input::loadKeyNames("UI_Text/KeyText.txt"))
|
So I think I found the issue, at the very bottom of the output:
For some reason, it's parsing the local data directory as /home/username/home/username/.local/share/TheForceEngine. I made a home folder inside my user's home directory, then seong, and so on. Launched it again, and now it's booting. FWIW, I had put these exports in my
So just as a test, I blanked out just the first one as so:
then removed the redundant nested home-inside-/home, launched So I'm guessing somewhere the code is defaulting on $HOME and then also adding the value of EDIT: With the variable disabled, the main files are being dumped into
Sorry about all that, I'm too caught up in work at the moment to followup on things as much as I'd like. |
Ah interesting. Yes, the code is using XDG_ DATA_DIR if it's defined; I
was going by the description on fdo which states that its supposed to be a
relative path.
My Gentoo install doesn't define any of the XDG_ envvars so I didn't notice
anything.
Maybe I'll just drop that part and go with .local/share directly.
Opinions?
That One Seong ***@***.***> schrieb am So., 22. Jän. 2023,
20:24:
… tfe.txt
<https://github.com/luciusDXL/TheForceEngine/files/10475210/tfe.txt>
So I think I found the issue, at the very bottom of the output:
read(3, "\"libraryfolders\"\n{\n\t\"0\"\n\t{\n\t\t\"pa"..., 8191) = 3733
close(3) = 0
newfstatat(AT_FDCWD, "C:/Program Files (x86)/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "C:/Program Files/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "C:/Program Files (x86)/GOG.com/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "C:/GOG Games/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/Program Files (x86)/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/Program Files/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/Program Files (x86)/GOG.com/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/GOG Games/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine/settings.ini", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine/settings.ini", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
getpid() = 29082
getpid() = 29082
exit_group(1) = ?
+++ exited with 1 +++
For some reason, it's parsing the local data directory as
*/home/username/home/username/.local/share/TheForceEngine*. I made a
*home* folder inside my user's home directory, then *seong*, and so on.
Launched it again, and now it's booting.
(Tried with the linux3-audio-next branch, was crashing, so am using the
linux3 branch now and it is in fact working and I can get to the menu)
FWIW, I had put these exports in my ~/.bash_profile for some applications
to use XDG paths:
# Set XDG aliases
export XDG_DATA_HOME=$HOME/.local/share
export XDG_CONFIG_HOME=$HOME/.config
export XDG_STATE_HOME=$HOME/.local/state
export XDG_CACHE_HOME=$HOME/.cache
So just as a test, I blanked out just the first one as so:
$ export XDG_DATA_HOME=
then removed the redundant nested home-inside-/home, launched tfelnx, and
sure enough it boots fine now.
So I'm guessing somewhere the code is defaulting on $HOME and then *also*
adding the value of XDG_DATA_HOME, which is why it's making that weird
nested home-in-/home when the value's defined. No other app on my system
has issues finding files, so that's the only conclusion I can come up with.
Sorry about all that, I'm too caught up in work at the moment to followup
on things as much as I'd like.
—
Reply to this email directly, view it on GitHub
<#201 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5MF3PVG3C7FQIXDWAQ6WK3WTWCP5ANCNFSM6AAAAAAUCJS3GQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Just my $0.02, I'm not really aware of any big distros that deviate from EDIT: seems that declaring |
Yeah you need to really unexport XDG_DATA_DIR; even an empy XDG_DATA_DIR will change behavior. As for imgui.ini.. I don't want to touch imgui code, but I think a chdir() to ~/.local/share/ at app startup should suffice. |
That is by design: if you want to store your TFE Data somewhere else (or, maybe, have a second "profile") then set this to a relative path (i.e. export TFE_DATA_HOME=/p1 will expand to /home/user/p1/TheForceEngine/). Please pull the branch again and give it a test, it should fix your 2 issues. |
On Sun, Jan 22, 2023 at 8:24 PM That One Seong ***@***.***> wrote:
(Tried with the linux3-audio-next branch, was crashing, [..]
Can you narrow down where? Or provide me with a log and backtrace?
Thanks!
Your setup seems to be quite good at finding all the corner cases :)
… Message ID: ***@***.***>
|
TIL Anyways, pulled in the branch fresh and built, does seem to resolve my original issue.
I think that was my problem: I was not aware that the relative directory needs a backslash for this variable. Usually having a backslash at the start of a variable denotes that it's an absolute path (because out-of-context, it sounds like you're telling it to start from / (root)).
And it makes said folder in current working directory. Maybe consider clarifying this (either don't require a backslash for relative path, or documentation)? |
I will take that as a compliment! Console output:
tfe's log ( stack trace: tfe.txt |
I'm having a bug in mod Dark tide 2 #203 . I'm not sure, if this is only related to the linux port, my hardware or it's a general problem. Perhaps someone can confirm? |
Nah I meant: |
It doesn't happen with software rendering, I'm inclined to believe its a general (non-linux-related) bug, or even a bug in the map itself. |
You are right, that was completely counterintuitive. I fixed this up now: an absolute path is now handled as an absolute path, while a relative path is now handled relative to the current directory. If "TFE_DATA_HOME" is set and not blank, the path information in it will be used without the added "TheForceEngine". Give it a try please. |
It was intended that way.
So somewhere in usable api detection. I pushed a tentative workaround to the branch, please repull and test. |
On startup, screenCapture will cause random crashed because of uninitialized m_capures member. 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. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The GobMemoryArchive does not define an ARCHIVE_GOB type anywhere. To fix this, add a new constructor to the base class to set the archive type at instantiation time. This fixes a crash on Linux with Mods (quitting while running a mod, or loading a savegame away from a mod, where the memory gob freeing causes a crash). Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
TFE sends 3 bytes for every MIDI message; however there are some, among them PROGRAM CHANGE (to define instrument to use), which only have 1 argument byte instead of 2. The Linux ALSA midi parser gets confused by the 3rd byte. So adhere to MIDI and only send 2 byte messages for PROGRAM CHANGE. (there are other midi messages with only 2 bytes, but TFE doesn't use them). This fixes the piano-only output on Linux. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
There are 2 BeginChild() that are close with End(), fix that. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
gcc and clang complain about the 2nd parameter to ImSetSoundTrigger(); Fix with a reinterpret_cast<> Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
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. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- _strlwr()/_strupr() are Windows CRT only, roll our own and use them throughout the codebase. - replace the windows-oly *_s() string functions with portable equivalents
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 is picky about preprocessor macros and missing arguments in place of VA_ARGS. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
unlike previous versions, gcc-13 does no longer implicitly include a lot of c++ header files. Add them to the files that need them. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Fixes fullscreen on Linux Window managers.
GCC complains about an invalid explicit specialization outside a namespace scope: filestream.h:67:19: error: explicit specialization in non-namespace scope 'class FileStream' Work around by explicitly implementing the template. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Implement missing pieces for Linux support: - CMake buildsystem - posix/linux specific file- and pathhandling bits. this implementation also takes case-sensitivity of unix filesystems into account. - add infrastructure to look up system files (shaders, doc, fonts, ...) independently from the main binary (for distro packaging). - fix up the linux thread implementation. - fix up 32bit target build. - crash handler skeleton. - can look for game data files in local Steam installation on multiple libraries. (GOG linux games do not leave trails about their installation paths in any central location, so gog detection is missing). based partly on previous work by Matthew Gilmore. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
On some Linux DEs, the native file dialog does a case sensitive search for file extensions. Add the uppercase extensions LAB and GOB as well to fix at least Gnome/GTK file dialogs being unable to select the DARK.GOB file. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Sorry for the wait. Backtrace says:
|
Oh cool: |
Could you please try this little test program? It's a distilled version of what is in your backtrace. https://gist.github.com/mlauss2/8a7be0f6c8bc15693fdff6330b4c71bc |
Would it be pertinent to mention that I'm using PipeWire and not normal PulseAudio? Because this is Arch otherwise, and that'd be a pretty glaring incompatibility to have with such a major distro (FWIW, Arch + PW is a combination also found on Steam Deck). I also wouldn't know where to report this to, aha. |
I too run pipewire + libpulse and don't see your problem (bluetooth headset, displayport audio and analog audio devices). Does Arch not have a bugtracker? Run the test program under gdb, attach it and the backtrace to the bugreport and maybe they can find out what they are doing differently. in the meantime, edit the TheForceEngine/settings.init file, under the [Sound] section add "audioApiId=1" to force ALSA. |
Unfortunately this is something that is simply beyond my capabilities that I'm unable to do myself for the time being. FWIW, the workaround of forcing audio backend does work with the audio-next branch (1 was JACK, which didn't actually seem to work; 3 was ALSA. Selecting Pulse and restarting does indeed cause segfaults on next launch). |
Oh too bad, though. I'm going to try to install Arch and see if I can reproduce it locally.
I'll change the setting from an integer to a string, so that you can write "alsa" as setting which is much more intuitive. |
(this supersedes #188 )
Linux Bits for TFE:
Big thanks to Matthew Gilmore, I took a few patches from your initial port, and all the testers
who commented on #176
Source build tested with gcc-11, gcc-12, gcc-13 and clang-15 and VC++ on x64, as well as i686 and mips32el.