Flatpak build

[LeandroStanger]

Please, consider supporting Flatpak and publishing Vita3K on Flathub.

[Doomsdayrs]

Second, An ubuntu-tar is irrelevant and a flatpak bundle can be used on more systems

[Doomsdayrs]

Here is the way https://docs.flatpak.org/en/latest/single-file-bundles.html

[qurious-pixel]

It is more than just bundling the app. flatpak has some read-only portions that Vita3K currently does not support. It will fail to launch.

[Doomsdayrs]

It is more than just bundling the app. flatpak has some read-only portions that Vita3K currently does not support. It will fail to launch.

What read-only portions?

[qurious-pixel]

https://docs.flatpak.org/en/latest/sandbox-permissions.html Sandbox permissions prevent the creation of shaderlog, config.yml, and vita3k.log The root folder of data, shaders, shaders-builtin and Vita3k are in a read-only sandbox when packaged as a flatpak.

[Doomsdayrs]

You can drop a payload into the user data directory.

That is how the flatpak for WarThunder works

[EXtremeExploit]

https://docs.flatpak.org/en/latest/sandbox-permissions.html Sandbox permissions prevent the creation of shaderlog, config.yml, and vita3k.log The root folder of data, shaders, shaders-builtin and Vita3k are in a read-only sandbox when packaged as a flatpak.

This could be implemented to go into ./config or ./local with the right permissions and PR, still its not very good to have the emularor "unbox" just for these files

[qurious-pixel]

This can be accomplished by placing the appropriate files/folders in $XDG_DATA_HOME and $XDG_CONFIG_HOME, but this will also affect Windows and MacOS. I prefer this for Linux (it follows the XDG standard), but would require Windows users to look in %LOCALAPPDATA%

[Doomsdayrs]

If there is a requirement for having it be portable for windows / MacOS, then there can just be a different variant with it set to portable mode.

[EXtremeExploit]

we could make the flatpak do symlinks automatically on install to XDG (https://github.com/flatpak/flatpak/issues/4109)

[Doomsdayrs]

Why would you use that when this is a case of a program not following specifications

[qurious-pixel]

Symlinks are not the issue, and not all file-sytems allow; ExFat for example. The issue is creating files and directories where flatpak expects read-only permissions. Then Vita3K will hard crash because the files don't exist or cannot be modified.

Unless someone creates a PR, it will not work as expected in its current form.

I have packaged an AppImage which has similar restrictions as flatpak, but hacked the config file to create and read the directories from ~/.local/share

[P-C-R]

+1 for a flatpak build. For all the SteamDeck users out there

[j8r]

Hello, I'm working on packaging Vita3K for Flatpak. Good news, I got the package built! However, work remains.

First, a few things regarding the compilation:

• libstdc++ is missing on the Flatpak SDK, which makes the final linking fail, and it is not mandatory if we remove it from https://github.com/Vita3K/Vita3K/blob/master/vita3k/CMakeLists.txt#L139
• the bundled boost compiles the atomic,chrono,exception,filesystem,headers,locale,log,program_options,regex,system,test,thread,timer libraries, but only filesystem,system are necessary for the compilation
• loads of things could be avoided to be compiled, like googletest and .a static archives, but this is not a big deal, they can be stripped away afterwards
• -DCMAKE_INTERPROCEDURAL_OPTIMIZATION could be considered to potentially improve performance. Some other emulators like Citra, DuckStation and PCSX2. It would be interesting to see what difference it will make, if any.

As already said above by @qurious-pixel Vita3K will have to be adapted a bit to run properly inside Flatpak, but at least it will be a starting point. When running Vita3K, I got this error:

flatpak run org.vita3k.Vita3K
File log initialization failed: Failed opening file /app/bin/vita3k.log for writing: Read-only file system

A solution is either outputting to the stdout directly, or writing to $XDG_DATA_DIR.

Here is the Flatpak, with the build instructions in the README for those wanting to help on making Vita3K running properly inside the sandbox.

[WingofaGriffin]

Awesome research @j8r! Is this something you have made a PR/official request to Flathub to add? Seems like this is a great way to improve emulation performance in general via Flatpak.

[j8r]

I haven't opened a PR because the application was not ready. It has to work before submitting to the store.

[WingofaGriffin]

Apologies, I was unclear. I was referring to a PR for the missing dependencies to be added to the SDK.

[WingofaGriffin]

Additionally @qurious-pixel I'm curious about the status of your AppImage fork. Are the steps outlined by j8r similar, or does AppImage have different requirements that should be outlined in a separate issue?

[DarkReaperBoy]

no new news? cries on fedora silverblue

[powerpuffboysz]

I haven't opened a PR because the application was not ready. It has to work before submitting to the store.

Any news on the vita3k flatpak?

[j8r]

If anyone has the time to work on making Vitak3K work with the XDG spec, it will unblock the packaging.

[j8r]

With the recent XDG changes, I have updated my Flatpak package but got this compiling error with GCC 13:

FAILED: vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o 
/usr/bin/ccache /run/ccache/bin/c++ -DBOOST_ATOMIC_NO_LIB -DBOOST_FILESYSTEM_NO_LIB -DBOOST_SYSTEM_NO_LIB -DONLY_MSPACES=1 -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_NO_THREAD_ID -DTRACY_ENABLE -DTRACY_NO_SYSTEM_TRACING -DTRACY_ON_DEMAND -DUSE_LOCK=0 -DYAML_CPP_STATIC_DEFINE -I/run/build/vita3k/_flatpak_build/vita3k/config -I/run/build/vita3k/vita3k/renderer/include -I/run/build/vita3k/vita3k/crypto/include -I/run/build/vita3k/vita3k/display/include -I/run/build/vita3k/vita3k/emuenv/include -I/run/build/vita3k/vita3k/mem/include -I/run/build/vita3k/vita3k/util/include -I/run/build/vita3k/vita3k/config/include -I/run/build/vita3k/vita3k/np/include -I/run/build/vita3k/external/yaml-cpp/include -I/run/build/vita3k/external/fmt/include -I/run/build/vita3k/external/spdlog/include -I/run/build/vita3k/vita3k/http/include -I/run/build/vita3k/vita3k/kernel/include -I/run/build/vita3k/vita3k/rtc/include -I/run/build/vita3k/vita3k/cpu/include -I/run/build/vita3k/vita3k/nids/include -I/run/build/vita3k/external/dlmalloc -I/run/build/vita3k/external/stb -I/run/build/vita3k/vita3k/shader/include -I/run/build/vita3k/vita3k/features/include -I/run/build/vita3k/vita3k/gxm/include -I/run/build/vita3k/vita3k/glutil/include -I/run/build/vita3k/external/glad/include -I/run/build/vita3k/vita3k/threads/include -I/run/build/vita3k/vita3k/vkutil/include -I/run/build/vita3k/external/Vulkan-Headers/include -I/run/build/vita3k/external/VulkanMemoryAllocator-Hpp/include -I/run/build/vita3k/external/VulkanMemoryAllocator-Hpp/VulkanMemoryAllocator/include -I/run/build/vita3k/external/ddspp -I/usr/include/SDL2 -I/run/build/vita3k/external/ffmpeg/include -I/run/build/vita3k/external/xxHash/cmake_unofficial/.. -isystem /run/build/vita3k/external/boost -isystem /run/build/vita3k/external/tracy/public -O2 -pipe -g -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -O2 -g -DNDEBUG -std=c++20 -Wformat -Werror=format-security -MD -MT vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o -MF vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o.d -o vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o -c /run/build/vita3k/vita3k/renderer/src/vulkan/context.cpp
/run/build/vita3k/vita3k/renderer/src/vulkan/context.cpp: In member function ‘void renderer::vulkan::VKContext::start_render_pass(bool)’:
/run/build/vita3k/vita3k/renderer/src/vulkan/context.cpp:298:5: error: ambiguous overload for ‘operator=’ (operand types are ‘vk::RenderPassBeginInfo’ and ‘<brace-enclosed initializer list>’)
  298 |     };

By the way, is it ok to compile Vita3K with GCC or would it be better - i.e. faster and/or more supported - to use LLVM?

[theofficialgman]

By the way, is it ok to compile Vita3K with GCC or would it be better - i.e. faster and/or more supported - to use LLVM?

@j8r just another user here but clang 15 is used in the official CI https://github.com/Vita3K/Vita3K/blob/master/.github/workflows/c-cpp.yml

[Macdu]

With the recent XDG changes, I have updated my Flatpak package but got this compiling error with GCC 13:

FAILED: vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o 
/usr/bin/ccache /run/ccache/bin/c++ -DBOOST_ATOMIC_NO_LIB -DBOOST_FILESYSTEM_NO_LIB -DBOOST_SYSTEM_NO_LIB -DONLY_MSPACES=1 -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_NO_THREAD_ID -DTRACY_ENABLE -DTRACY_NO_SYSTEM_TRACING -DTRACY_ON_DEMAND -DUSE_LOCK=0 -DYAML_CPP_STATIC_DEFINE -I/run/build/vita3k/_flatpak_build/vita3k/config -I/run/build/vita3k/vita3k/renderer/include -I/run/build/vita3k/vita3k/crypto/include -I/run/build/vita3k/vita3k/display/include -I/run/build/vita3k/vita3k/emuenv/include -I/run/build/vita3k/vita3k/mem/include -I/run/build/vita3k/vita3k/util/include -I/run/build/vita3k/vita3k/config/include -I/run/build/vita3k/vita3k/np/include -I/run/build/vita3k/external/yaml-cpp/include -I/run/build/vita3k/external/fmt/include -I/run/build/vita3k/external/spdlog/include -I/run/build/vita3k/vita3k/http/include -I/run/build/vita3k/vita3k/kernel/include -I/run/build/vita3k/vita3k/rtc/include -I/run/build/vita3k/vita3k/cpu/include -I/run/build/vita3k/vita3k/nids/include -I/run/build/vita3k/external/dlmalloc -I/run/build/vita3k/external/stb -I/run/build/vita3k/vita3k/shader/include -I/run/build/vita3k/vita3k/features/include -I/run/build/vita3k/vita3k/gxm/include -I/run/build/vita3k/vita3k/glutil/include -I/run/build/vita3k/external/glad/include -I/run/build/vita3k/vita3k/threads/include -I/run/build/vita3k/vita3k/vkutil/include -I/run/build/vita3k/external/Vulkan-Headers/include -I/run/build/vita3k/external/VulkanMemoryAllocator-Hpp/include -I/run/build/vita3k/external/VulkanMemoryAllocator-Hpp/VulkanMemoryAllocator/include -I/run/build/vita3k/external/ddspp -I/usr/include/SDL2 -I/run/build/vita3k/external/ffmpeg/include -I/run/build/vita3k/external/xxHash/cmake_unofficial/.. -isystem /run/build/vita3k/external/boost -isystem /run/build/vita3k/external/tracy/public -O2 -pipe -g -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -O2 -g -DNDEBUG -std=c++20 -Wformat -Werror=format-security -MD -MT vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o -MF vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o.d -o vita3k/renderer/CMakeFiles/renderer.dir/src/vulkan/context.cpp.o -c /run/build/vita3k/vita3k/renderer/src/vulkan/context.cpp
/run/build/vita3k/vita3k/renderer/src/vulkan/context.cpp: In member function ‘void renderer::vulkan::VKContext::start_render_pass(bool)’:
/run/build/vita3k/vita3k/renderer/src/vulkan/context.cpp:298:5: error: ambiguous overload for ‘operator=’ (operand types are ‘vk::RenderPassBeginInfo’ and ‘<brace-enclosed initializer list>’)
  298 |     };

By the way, is it ok to compile Vita3K with GCC or would it be better - i.e. faster and/or more supported - to use LLVM?

There is no ci running gcc for Vita3K right now, which can result in some of these errors. Pull request to fix Vita3K on other compilers are accepted without any issue tho. The difference in speed between gcc and clang shouldn't make too much of a difference, but indeed you for sure wouldn't get these errors using clang.

[j8r]

Gonna switch to Clang then, it is usually a good idea to stay as close from upstream as possible. Thanks!

[j8r]

Thanks, I'm able to compile Vitak3K with LLVM17 :slightly_smiling_face: When I run Vita3K, I got: "Could not create OpenGL context! Does your GPU at least support OpenGL 4.4", then "Emulated environment initialization failed". I've a HD 5500, and flatpak permissions should be properly set. It might also be a filesystem permission issue by looking at the last lines.

[03:45:12.132] |I| [init_config]: backend-renderer: OpenGL
[03:45:12.132] |I| [init_config]: log-level: 0
[03:45:12.195] |I| [main]: Vita3K v0.1.9 1-4ac8a41
[03:45:12.195] |I| [main]: Number of logical CPU cores: 4
[03:45:12.195] |I| [main]: Available ram memory: 15891 MiB
[03:45:12.197] |I| [init]: Base path: /app/bin/
[03:45:12.197] |I| [init]: Static assets path: /home/jrei/.local/share/Vita3K/
[03:45:12.197] |I| [init]: Shared path: /home/jrei/.local/share/Vita3K/
[03:45:12.197] |I| [init]: Log path: /home/jrei/.var/app/org.vita3k.Vita3K/cache/Vita3K/
[03:45:12.197] |I| [init]: User config path: /home/jrei/.var/app/org.vita3k.Vita3K/config/Vita3K/
[03:45:12.197] |I| [init]: User pref path: /home/jrei/.var/app/org.vita3k.Vita3K/data/Vita3K/Vita3K/
[03:45:12.197] |I| [init]: User cache path: /home/jrei/.var/app/org.vita3k.Vita3K/cache/Vita3K/
[03:45:12.273] |I| [create]: GPU = Mesa Intel(R) HD Graphics 5500 (BDW GT2)
[03:45:12.273] |I| [create]: GL_VERSION = 4.6 (Core Profile) Mesa 23.3.0 (git-1fbdd37d4c)
[03:45:12.273] |I| [create]: GL_SHADING_LANGUAGE_VERSION = 4.60
[03:45:12.273] |I| [create]: Your GPU only supports texture barrier, performance may not be good on programmable blending games.
[03:45:12.273] |W| [create]: Consider upgrading to a GPU that has shader interlock.
[03:45:12.273] |E| [load_shaders]: Couldn't open shader: /home/j8r/.local/share/Vita3K/shaders-builtin/opengl/render_main.vert
[03:45:12.273] |E| [load_shaders]: Couldn't open shader: /home/j8r/.local/share/Vita3K/shaders-builtin/opengl/render_main.vert
[03:45:12.273] |C| [init]: Couldn't compile essential shaders for rendering. Exiting
[03:45:12.273] |E| [init]: Failed to initialize screen renderer

[Macdu]

Do you indeed have a file render_main.vert in /home/j8r/.local/share/Vita3K/shaders-builtin/opengl/ ?

[j8r]

Indeed it works by copying this files! However read-only files should be in the Flatpak directly (/usr/share, or any other path), for ease-of-use and sandboxing, those shall be created at XDG_DATA_HOME.

With this changes i think we are close to something publishable to the Flathub store :slightly_smiling_face:

[j8r]

If anyone has an idea how to fix this path issue by using the XDG standard or using a system path, please go ahead!