Open ghost opened 6 years ago
It's been an archive + a binary since inception. That's pretty much what a flatpak is. Pull requests are welcome.
While I can appreciate a traditional archive, flatpak has several advantages.
You can include the required libraries to ensure the application can run on any current or future distributions. Imagine in many years when the Linux landscape has evolved someone could download a Forsaken flatpak and the game will just work. You can even run glibc applications on a musl libc system.
Also a flatpak is much easier to install and provides shortcuts to integrate better with your desktop environment. Flatpak sandboxes applications for increased security, and can be installed as a normal user without root privileges.
I'd give a shot at packaging it myself, but I'm having trouble getting the game to run or compile on Void Linux (exactly the kind of issue that a flatpak would resolve).
The binary is statically compiled to avoid issues like that so you don't need anything else.
On windows it's statically compiled using mingw so it doesn't need anything either except it bundles the sdl/openal dll files iirc which is ready to roll by just clicking the executable.
The game doesn't need to be "installed" just simple ran. If you want to run it in a VM or a container it should be pretty easy.
If the game doesn't run it's most likely something related to video auto detection / initialization which shouldn't really happen but can. If you run it with debug logging enabled you can go look at the log file and figure it out.
You can compile the game rather easily using https://github.com/ForsakenX/forsaken-libs which I would probably port to run in a container today making it even easier.
The command line options are in the code but also documented here:
There is a whole section on how to compile here:
I recently switched to Arch from Void Linux on my main machine, and I still couldn't get the "projectx-1.18.2546-LINUX64" binary to run. However, I was able to compile the game using the instructions under "Quick and easy dev setup" and now have a functioning game. Thanks for providing this level of documentation.
hm, can you double check that binary you were trying to use is not dynamically linked?
where you able to capture what kind of errors you were getting?
we should really figure out what the issue is so it doesn't affect others.
This is what happens on Arch Linux, when I was on Void Linux the error was a segfault.
$ readelf -d projectx-1.18.2546-LINUX64 | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libSDL-1.2.so.0]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libGL.so.1]
0x0000000000000001 (NEEDED) Shared library: [libGLU.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
$ ldd projectx-1.18.2546-LINUX64
linux-vdso.so.1 (0x00007ffc0d5cb000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00007f76d31dc000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f76d2fbe000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f76d2d33000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007f76d2ab3000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f76d26fc000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f76d23b0000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f76d21ac000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f76d1fa4000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f76d3473000)
libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007f76d1d73000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f76d1a34000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f76d1822000)
libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007f76d156c000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f76d11e5000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f76d0fce000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f76d0da5000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f76d0ba1000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f76d099b000)
$ ./projectx-1.18.2546-LINUX64
./projectx-1.18.2546-LINUX64: relocation error: ./projectx-1.18.2546-LINUX64: symbol __get_cpu_features, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
$ /usr/lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.26, by Roland McGrath et al.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.2.1 20171224.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<https://bugs.archlinux.org/>.
$ uname -a
Linux arch-ra 4.15.14-1-ARCH #1 SMP PREEMPT Wed Mar 28 17:34:29 UTC 2018 x86_64 GNU/Linux
I'll have to check the build because that seems like it's way more dynamic libs than I remember.
A few are expected like sdl, gl, etc because your system should provide them.
Going to +1 this request.
Flatpak makes getting this on the steamdeck 1000x... building this ON the deck would be alot harder....
Linux distributions can't package your project due to licensing issues, so why not release Forsaken as a Flatpak single-file bundle? I think it makes a lot of sense for open-source games like this one.
For more info: http://docs.flatpak.org/en/latest/