OpenGL Core Context / Vulkan
Hi, 
After some research it appears to me that AppImage is the best way to support portable apps (apps that do not require any installs). The applications I would like to support are games made with a custom 3d game engi&hellip;
https://sjc6.discourse-cdn.com/standard10/uploads/appimage/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_32x32.png
AppImage
Hello @Yuri6037 and welcome to AppImage.

After some research it appears to me that AppImage is the best way to support portable apps (apps that do not require any installs).

Yes, this is exactly what it was designed for.

I plan to make an SDK tool that can auto package AppImages.

Great project. I suggest that you check out my work-in-progress GitHub - probonopd/go-appimage: Go implementation of AppImage tools. Still experimental; maybe it is useful for you?

On GitHub - AppImage/appimage.github.io: Given an URL to an AppImage, the GitHub action in this project inspects the AppImage and puts it into a community-maintained catalog we are using a bash script to download, run and test all submitted AppImages on the oldest still-supported Ubuntu system at any given time, which we consider to be the baseline. As part of the process a screenshot of the running application is taken (and is required in order to pass the test).

Here is the bash script that does it:

If so how do you deal with AppImages that requires OpenGL 4.0 core context only API for hardware acceleration or Vulkan API for hardware acceleration?

Quite frankly, I don’t have enough clue about how graphics acceleration works so I assume this stuff to be all broken. As a result, e.g., screenshots of some Qt applications are garbled (and I suspect it has something to do with OpenGL but am not sure). Since you seem to be knowledgable about it, do you have an idea on how to do it properly?

Are newly submitted AppImages required to run under sandbox?

It needs to be able to run like this:

firejail --quiet --noprofile --net=none --appimage ./Your.AppImage" &

as you can see in the script linked above.

This is used to disable any network access while the AppImage is being tested. It does not restrict the application’s ability to access any filesystem locations.

/proc/self/exe will point to the executable inside your AppImage. You can use it to construct a path to your assets inside the AppImage from there.

If you want to point to assets relative/next to the AppImage, then you need to use the $APPIMAGE environment variable and construct the path from there. Be sure to handle the case when an AppImage is extracted and hence $APPIMAGE is not available (in this case, fall back to /proc/self/exe). Hope this makes sense; feel free to ask if something is unclear.

Thanks a lot for all this information.

From your answer, I can consider /proc/self/exe will be available and will point to binary location, which is exactly what it is supposed to be (I have both read-only default assets and read-write modded assets given by the user in application data directory which is built from $HOME on linux and OSX, %USERPROFILE% under Windows, and local private app directory under android, and yes I know android will have poor mod support but well Google wants to restrict moddability).

As for GL this seem to be the greatest problem. Travis does not have a GPU that is compatible with CoreContext GL or Vulkan. The issue here is a lot of 3D based engines will need GPU access to even display anything.

The best I can think of to allow testing 3D accelerated applications would be to run them on a dedicated server which has a GPU like we would for deep learning based applications.

So the best plan I can think would be like:

Use gIthub actions which allows for custom runners to be used as testing servers.

Create a custom runner on a dedicated machine equipped with some kind of NVIDIA GTX or compatible GPU.

Create a virtual xorg framebuffer and run the GL/VK app under it (a bit like your current script).

Another solution which I’m not sure is possible and will require much more time and may not even run fast enough for take a screenshot or it will be bugged:

Create a software rendering driver which implements the VK API and GL 4 API so that the application can use the software based rendering driver instead of the NVIDIA driver or AMD driver. Biggest con to this approach is if it does work it is just going to be super but like super slow…

EDIT: It might be possible to allow people to run the test script on their own machines and then return the results…