Skip to content
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

Updated Linux Port for 1.01+ #188

Closed
wants to merge 16 commits into from
Closed

Updated Linux Port for 1.01+ #188

wants to merge 16 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Jan 9, 2023

(this supersedes #176 )

With these changes, TFE runs smoothly on 64bit Linux, with digital Audio and MIDI support (tested with fluidsynth and timidity++), everything works: cutscenes, fullscreen/windowed, save/load, mod loading, finding TF and Outlaws in any
available Steam library. DF is fully completable, I tested both the german and english versions, also with the DF-21 community patch applied.

The first half of patches fix general issues found during testing, the other half is gcc/clang/linux-specific changes, which
I also verified they don't break the windows build.

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, as well as VC++

@ghost ghost mentioned this pull request Jan 9, 2023
@Agetian
Copy link

Agetian commented Jan 9, 2023

Tested on Linux Mint 21.1 with Timidity, seems to work well (music only works in the audio-next branch, there's no way to select the backend in the linux3 branch yet).

mlauss2 and others added 16 commits January 17, 2023 08:04
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.
@neuromancer
Copy link

I did a quick test of this branch in ArchLinux, please considering adding the GOB and EXE patterns when detecting the game from the GOG version, since otherwise, it won't allow to select the correct directory.

@SeongGino
Copy link

SeongGino commented Jan 18, 2023

FWIW, building from the Linux3 branch, the executable's built but nothing happens when launching (no output, just immediately returns to prompt like I entered nothing). Also running Arch.
The builds done on the same system off the branches from the last PR thread did work, so not sure what's different here.

@ghost ghost closed this by deleting the head repository Jan 18, 2023
@Agetian
Copy link

Agetian commented Jan 19, 2023

If you don't mind me asking, can you please clarify what happened to this effort? A little surprised to see all the work scrapped and the branch removed from existence completely, I hope this doesn't mean that the effort to bring The Force Engine to Linux is abandoned. From my personal testing on Mint, whatever was already done seemed to work very well, barring some minor issues which were largely resolved in the latter revisions of the code in the branch.

@neuromancer
Copy link

I have no idea what happened to this effort, but the user that created the branch was removed from github, so something fishy is going on.. 🤔

@Agetian
Copy link

Agetian commented Jan 19, 2023

Hmm, alright... Hopefully it will get clarified with time.
At any rate, if this is unintentional and (hopefully) not indicative of the fact that the effort to port TFE to Linux is no more, I have the archive with the Linux branch archived. It may not be the latest version, but I do have the January, 9 files if they could be useful to recover what was already done.

@neuromancer
Copy link

The diff is still available so this can be re-recreated, if this is useful. Perhaps @luciusDXL can clarify this.

@luciusDXL
Copy link
Owner

luciusDXL commented Jan 20, 2023

I have confirmed that this was closed because the author is no longer a GitHub user.

That said, I am setting up a dev environment so I can add "official" Linux support (i.e. not a branch, but in master) and I was planning on pulling from this effort. The diffs are still available, so I might still do that.

@Cheeseness
Copy link

That said, I am setting up a dev environment so I can add "official" Linux support (i.e. not a branch, but in master) and I was planning on pulling from this effort. The diffs are still available, so I might still do that.

Glad to hear this work likely won't be wasted. I was considering spinning up a new fork to continue the effort, but I am swamped with other work and it's a relief to know that it's in good hands :)

If porting/Linux porting is new to you, I have some experience, and there seem to be others with useful perspectives paying attention. Happy to share any advice that might be of value.

@Agetian
Copy link

Agetian commented Jan 21, 2023

Absolutely! You can count on me for testing the builds when they're ready :)

@mlauss2 mlauss2 mentioned this pull request Jan 21, 2023
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants