Newpkg: Flightgear #1668
Newpkg: Flightgear #1668
Conversation
|
If you have to, you can try the tur-on-device folder instead of tur folder, right? Also, could you test Space bar for jumping in my luanti PR? if that also works for you, then maybe we can try to make a similar patch for SuperTux to fix the Space bar (and possibly other keys) in SuperTux when using hardware keyboard (and when using patches to fix the touchscreen buttons in SuperTux, jump works with the touchscreen button without hardware keyboard being necessary) |
Specifically, what I did was to rewrite CMake a bit so that I didn't have to use TUR-On-Device, but TUR specifically, which on my computer drastically reduced performance. The problem is in Plib, unfortunately it's a library that should be plowed, but a couple of games use it :(
Your fix works, ONLY I found another interesting case. Well, in the beginning almost no button worked almost. In the sense, WASD didn't work either and I couldn't move the character. I was able to turn on Chat (Y) and all the keys are responsive, they just don't work in the game. However, if you enable “Prefer scancodes when possible” in the Termux X11 settings under the Keyboard tab, WASD activates. Maybe it's a matter of bad scancode processing or something? In addition, what I noticed - the keyboard itself looks like it is being captured by the game (Luanti and Supertux), because in Luanti when you run Chat all the keys go through without a problem, and in Supertux when you bind the keys the reaction is correct. Maybe it's a matter of which library? I wonder if such problems are also in the Proot version (e.g. on Debian) |
I do not completely understand what you mean here, what kind of performance was reduced? The performance of the software at runtime, or the time it takes to build, or something else? Thank you for testing Luanti,
this is correct, actually to play Luanti using hardware keyboard at all, "Prefer scancodes when possible" On is required, there is no other way. In all my published documentation of the
If you are referring to Spacebar, this is good because, it sounds like very, very similar behavior to the problem of scrambled Spacebar keycodes in Luanti. If the exact same thing is really happening, then it should be possible to write a patch that works around it in SuperTux by swapping the keycode definitions of the Space key and the 9-Key within the source code of SuperTux. If we are going to try to time the release of the SuperTux package roughly for the release of SuperTux 0.7.0 upstream in order to get the official, merged and final version of their improved touchscreen buttons and CMake files (similarly to how I timed the initial publishing of my Luanti package roughly for the release of Luanti 5.10 upstream in order to get a similar set of upstream improvements), then we have some time before then still to do this, because their tracker has 0.7.0 marked at 80% completed. |
It's all about the speed of building the application locally. When creating a build script on x86 you prefer if the application can cross compile, as it doesn't require wasting a lot of time on QEMU emulation using TUR-On-Device. I'll be thinking about how to get around this in that case so that Plib builds and everything works.
It makes me wonder if it could be that there is an unimplemented feature in Termux X11 and then couldn't twaik check and correct it based on that? I don't know how realistically it works, but if such a bug is present in hundreds of programs, then you will have to patch each one. It is strange to me that the keys are detected but do not work. Maybe it's an issue with some function - I have no idea.
We can wait. It also depends how much, but I think probably a couple of months maximum. |
tur-on-device no longer uses QEMU for CI. Currently, it is now fully using GitHub Actions official ARM runner: tur/.github/workflows/package_on_device.yml Line 228 in d7792b3 however, I do understand what you mean because, for example, a package can more easily be migrated from TUR to x11-repo in github.com/termux/termux-packages if it is fully compatible with cross-compilation. I am going to try to fix your error anyway.
so far, it seems to only be present (the scrambled keycode of the Space key) in two known programs, Luanti and SuperTux, but I do not know what the true root cause is. It is possible that other games might have a similar problem too, but I don't know of any yet. It is reasonable to suspect that there is a library shared between both games which contains the root cause of the scrambled keycodes bug, but I haven't identified what library that could be yet. Twaik is aware of this bug I believe, but it is known not to be directly caused by Termux:X11 code itself, but rather X11 code in Termux generally somewhere, because alternative X11 server implementations like |
For your error, could you try this TERMUX_PKG_HOMEPAGE=https://plib.sourceforge.net
TERMUX_PKG_DESCRIPTION="Provides a Joystick interface, a simple GUI built on top of OpenGL, some standard geometry functions, a sound library and a simple scene graph API built on top of OpenGL."
TERMUX_PKG_LICENSE="BSD"
TERMUX_PKG_MAINTAINER="@termux-user-repository"
TERMUX_PKG_VERSION=1.8.5
TERMUX_PKG_SRCURL=http://deb.debian.org/debian/pool/main/p/plib/plib_${TERMUX_PKG_VERSION}.orig.tar.gz
TERMUX_PKG_SHA256=485b22bf6fdc0da067e34ead5e26f002b76326f6371e2ae006415dea6a380a32
TERMUX_PKG_DEPENDS="opengl"
TERMUX_PKG_BUILD_IN_SRC=true
TERMUX_PKG_EXTRA_CONFIGURE_ARGS="
ac_cv_lib_MesaGL_glNewList=yes
"
termux_step_pre_configure() {
export LDFLAGS+=" -Wl,--no-as-needed,-lOpenSLES,--as-needed"
./autogen.sh
touch ltmain.sh
} |
|
And the reason why I suggest changing the dependency from |
the code that is producing this error seems to me to be very, very old legacy code. It comes from this commit: What seems like a possible best solution to me is simply to apply this patch, --- /dev/null
+++ b/tur/simgear/simgear-structure-SGAtomic.hxx-i686-sgatomic-use-gcc4-builtins.patch
@@ -0,0 +1,12 @@
+--- a/simgear/structure/SGAtomic.hxx
++++ b/simgear/structure/SGAtomic.hxx
+@@ -21,8 +21,7 @@
+ #ifndef SGAtomic_HXX
+ #define SGAtomic_HXX
+
+-#if defined(__GNUC__) && ((4 < __GNUC__)||(4 == __GNUC__ && 1 <= __GNUC_MINOR__)) && \
+- defined(__x86_64__)
++#if defined(__GNUC__) && ((4 < __GNUC__)||(4 == __GNUC__ && 1 <= __GNUC_MINOR__))
+ // No need to include something. Is a Compiler API ...
+ # define SGATOMIC_USE_GCC4_BUILTINS
+ #elif defined(__GNUC__) && defined(__i386__)this makes the compilation error go away for me. Do you happen to have any 32-bit Android-x86 device to try testing the build that results from this at runtime on? If not, then I could try to test it for you. |
If you can :) I just have only my phone and laptop that will be obsolete, because I want to use phone as a computer only |
|
It might take a while because, I thought it is a good idea to check on a bare metal device for real for a patch like this just in case, to make sure it is actually going to work, and I was going to use a Pentium 4 Northwood, but I found out that it actually can't because it has a lot of illegal instruction errors and kernel panic when booting any Android-x86 ROM, and it's because Pentium 4 Northwood really can't run Android 7 because 32-bit x86 Android 7 requires SSE3 instructions at the absolute minimum and Pentium 4 Northwood does not have SSE3. I actually did not know about that before, I know about some other CPU requirements of Android but I did not know Pentium 4 Northwood cannot run Android 7. So instead, one option I have is to try to use my Intel Atom Z510. Intel Atom Z510 does support SSE3. However, Intel Atom Z510 is extremely slow, it might sound surprising but, it is actually much slower than a Pentium 4 Northwood, so if I use it then it will take much longer to set up and do anything. |
Sure :) In general I also just don't believe Flightgear works well on this hardware (32 bit). It's a pretty resource-intensive simulator and on a Snapdragon 865 I'm getting 7-8 frames on a Cessna 172p on minimum settings, but that could be (and probably is) due to Zink and Turnip. It is possible that it would run a little better on KGSL. BTW. can you set up automatic package updates? Because I don't know how exactly it works @hansm629 Can you try to run this sim on your Samsung phone with Exynos to check performance? |
I do not fully understand what you mean, do you mean automatic package updates from |
What I mean is that the TERMUX_PKG_AUTO_UPDATE function should work if it doesn't. I don't know how to set it |
|
ohh ok, well, actually I don't know how to make that either, but maybe you can set |
|
Ok, I have started testing on all architectures, and it turns out, currently when I run however, transferring a copy of I do not know what causes that error, but I will try to find it. If you want to try to debug it also, I can explain how to install termux-docker and |
|
Here is a backtrace of what happens And, the reason I know that this is consistently reproducible only on Android-x86 generally, both 64-bit and 32-bit, is because I have isolated it to Android-x86 specifically through process of elimination using the following set of test devices. I didn't end up actually being able to set up a device with a 32-bit x86 CPU yet that can run Android 7 or newer bare metal, but I have arrived at this conclusion using the following tests:
|
I don't know, unfortunately. It looks like a problem with Qt6, however I don't know if it's problems with Qt6 itself or the Launcher code. You could always try to build the Qt5 Launcher or not add the launcher at all, but in my opinion it should be there (and cool if on a newer version rather than an older one). If you have any ideas it's cool if you can implement them and fix the problem, if not I would try other people from the Termux world to ask them to do so |
|
This is TUR so I think (as far as I know) it is ok and fine to have the package built for x86 here even if it has a problem. If there is no solution yet, then maybe it is a good idea to add a postinst script with a condition into only the i686 and x86_64 builds of the package that prints "there is a problem with the Download button of the launcher, you will need to manually install the assets before launching" when users install it. You can see an example of how to make a postinst script with a condition here, basically you can put that, but instead of |
|
Also, there might be alternatively, a way to patch the x86 build so that it auto downloads the assets OR provides CLI command that does that. I am not sure but I might be able to look for that. In my opinion it does look like the problem has to do with the Qt button, so if a CLI command argument to the program is implemented somehow that can call the needed download function without creating the popup, then that will be good. |
|
Also, I think that there's a way to have the assets pre-available through Look at what Debian's package does, isn't that the needed assets? https://packages.debian.org/bookworm/flightgear-data-base It's 1 gigabyte though. I don't know if that is an acceptable size in TUR repo. the biggest one in TUR currently is probably |
Flightgear-data is the same collection that downloads Launcher. The difference is that Flightgear launcher can only download and install simulator data from the latest version (which is not yet available in Debian). Previously, it was up to the user to provide files to the simulator. We can supply them ourselves as a package, but it's a question of whether we want to, if the launcher can potentially do it. The question is whether this error what we have is a FlightGear error or Termux packages. If Flightgear you can always try to find out from them if they know something about it or have an idea. |
|
@IntinteDAO S24+(Exynos 2400) test results |
No problem, try
And wait ~60 secs, maybe it will go to the simulation I want it as a benchmark to see if cool this Exynos. |
|
@IntinteDAO |
Through the in-sim menubar: View > Display Options, tick the "Show frame rate" box How to start:
If you get 60 knots, you can type 3-4 times "down" button to climb. However you are in water, so you can't start. You need to set in launcher Download scenery and set DNS for Google in settings and FG will download a scenery |
|
@IntinteDAO |
Ok, but it's not a Termux bug, just it's hard to start a airplane :P But 17 FPS is playable IMO |
3 participants
@robertkirkman
The build works locally, but not here :( Maybe you can do something