Hello,
Following up on topic at https://forum.simutrans.com/index.php/topic,21054.0.html (https://forum.simutrans.com/index.php/topic,21054.0.html).
I have setup a github action workflow at https://github.com/krosk/simutrans-android-docker-build/actions/workflows/nightly-android.yml (https://github.com/krosk/simutrans-android-docker-build/actions/workflows/nightly-android.yml)
- On push, it builds the latest svn trunk; as of today it is hitting the r10015, which has a clang compilation error from code introduced days ago (https://github.com/krosk/simutrans-android-docker-build/runs/3345530926?check_suite_focus=true (https://github.com/krosk/simutrans-android-docker-build/runs/3345530926?check_suite_focus=true) and the likely commit of interest https://github.com/aburch/simutrans/commit/446284d85e8df07fffc73bfb200a23086d562388 (https://github.com/aburch/simutrans/commit/446284d85e8df07fffc73bfb200a23086d562388)), so it does not pass at the moment.
- As a result, I had to introduce a build on dispatch so as to target and release a given revision (example https://github.com/krosk/simutrans-android-docker-build/runs/3345540040?check_suite_focus=true (https://github.com/krosk/simutrans-android-docker-build/runs/3345540040?check_suite_focus=true)). Useful for checking earlier versions since this android target is new, but ultimately this should be a temporary measure.
The workflow generates an APK, patches the configuration file with the version number reported by SVN revision, and overwrites the Nightly release APK, the same way as it is done today for the other builds. Note also that the manual dispatch will still overwrite the Nightly.
The attached patch covers the yaml of the workflow above + a patch on top of pelya repository that fix a video glitch fix and change default resolution.
Sorry, I am a little unsure, I correctly understood. This means this will not run out of a native repo, but needs to be run from pelya? I.e. putting this into the simutrans workflow it will not work?
On the other hand, I would not mind downloading the nightly from some other place, since the building server downloads and repack and pushed the mac also from github. Thus just using your github address would work for me too.
My apologies, the wording was probably confusing.
This is absolutely a workflow meant to run from github actions, on simutrans repo. The patch I provided is to be applied to simutrans trunk and will add a nightly build for android. I made a fork of the github simutrans repo to demonstrate.
https://github.com/krosk/simutrans/actions (https://github.com/krosk/simutrans/actions)
About the sentence 'a patch on top of pelya': the patch I provided, aside the nightly build definition, also adds a file, that is a patch on top of pelya's repo; the workflow is, in addition to simutrans repo, pulling from their repository for building reasons but it needs a patch to work.
Not sure when and to what purpose a docker container is added here. Also I added your fluidsynth changes. But I do not understand the chnage to mx/cx. cx contains the first point when clicked and mx the current position when releasing. Why are they assigned?
Anyway I submitted it and I am waiting to see it build (or not). That will take a while, since I do not control the guthub repo (only my svn server).
prissi, sorry for the confusion.
1/
Only one commit is relevant for you:
https://github.com/krosk/simutrans/commit/06bdb66428312326f5ccf3b291cbf1f0e710658e (https://github.com/krosk/simutrans/commit/06bdb66428312326f5ccf3b291cbf1f0e710658e)
This is simply the patch I attached above.
Everything else is me playing around with the source on my terms, on this fork, and has nothing to do with the topic ! I sent a link to my fork as an example of adding the build pipeline, but not saying the whole fork is relevant. The stuff with cx/mx is indeed irrelevant.
2/
Not understanding your comment of the purpose of docker container. Anyway, no docker is involved in my fork of simutrans repo.
However, in the repo of the dockerfile I spoke about in the other topic, I made another github action pipeline that makes use of the dockerfile instead of putting every single step in the github action workflow. But this is not the approach used for this patch either.
3/
https://github.com/krosk/simutrans/commit/25c021e8aced153479407a1f767749734ac48fb9 (https://github.com/krosk/simutrans/commit/25c021e8aced153479407a1f767749734ac48fb9)
To clarify, the change of fluidsynth is a revert of a previous commit because it makes clang not passing compilation for Android, so this arguably is required to make the Android build pass; I did mention this build problem at the very top, but this is not part of the patch I provided. In git it would have been more proper to revert the target commit in its own commit so we don't mix things up; I am not sure what is your workflow with svn.
Bottom line: there are two set of changes to do:
a/ this adds the nightly build https://github.com/krosk/simutrans/commit/06bdb66428312326f5ccf3b291cbf1f0e710658e (https://github.com/krosk/simutrans/commit/06bdb66428312326f5ccf3b291cbf1f0e710658e)
b/ this reverts a previous commit incompatible with clang used for Android https://github.com/krosk/simutrans/commit/25c021e8aced153479407a1f767749734ac48fb9 (https://github.com/krosk/simutrans/commit/25c021e8aced153479407a1f767749734ac48fb9)
1) The patch file in a patch has my patch program spit out nonsense. I need to download this manually.
In the link given, you are forcing a revision number for the nightly. This is very wrong, it should use the current nightly revision number. So I removed these lines.
2) There were some lines
Quotesudo chown -R runner /opt/android-sdk-linux
sudo chgrp -R docker /opt/android-sdk-linux
sudo chown -R runner /android-sdl
sudo chgrp -R docker /android-sdl
So I wondered about docker. But the github action systems have all kind of surprises ...
3) Since passing compilation is a very good reason to have this in fluidsynth (with was a recent addition I know next to nothing since I do not like the midi and disable it as default) it is better to use defines to succeed compiling with Android and leave the rest as it was. But I can revert it.
I thought I have put your yaml (minus forcing a revision). Also the current Simutrans version is in simversion.h, so I wonder if one can use this to make an correct patching. I then submit everything to the svn which get then pushed to github
prissi, thanks for the answers.
1/ Sorry for the akward 'patch in a patch' thing.
About the lines for the revision:
revision:
description: 'Target revision number (SVN), empty for latest'
Guthub actions allows running a build on-demand (so called workflow dispatch). So:
- if the build is executed as part of a new commit, these lines are ignored and the workflow checkouts the newest version of the repository <<< this is what is intended for a nightly build, and this is the default behavior
- if the build is executed manually via the github actions interface (there is a button 'run workflow'), these lines are taken into account; Now, the meaning of these lines is to checkout a particular target version of the svn repo; useful for debugging, or getting back an APK of a previous version. Arguably, this second mode is not what you expect of a "nightly" and would have been more appropriate for a different, build-on-demand workflow. So you will want to remove everything related to it. I attached a patch.
2/ Github actions is running a clean, ubuntu-based (or windows-based), docker container each time a build is performed.
The steps in the yaml file are executed within this container, as user 'runner' with the group 'docker'.
Those lines you quoted are to assign the correct permissions to the folders I create, so that following steps are permitted to work within them.
3/ The approach of using defines is appropriate, and you were right to do it this way. Reverting was never the true option, which is why I merely raised the issue without forcing this in the patch.
Now there is a compile error for android and macos, complaining about not matching #if and #endif. I believe the line 212 in the file music/fluidsynth.cc is an endif that breaks what you intended to do. Removing it would make it compile. Still, I suggest a simpler refactoring and attached a patch.
Thank you, I learned another new thing by this.
I wonder why there is a .patch file in the github repository?. ???
https://github.com/aburch/simutrans/blob/master/.github/android/0001-ADD-patch-simutrans-122.0-compatibility.patch
Yona-TYT,
pelya repository for libsdl-android contains a set of configuration files and building scripts customized for simutrans. The configuration that pelya provided is today incorrect (it makes the screen flicker).
I submitted a PR on pelya repository to correct the issue, and until that PR gets accepted, I still have to make changes on top of pelya's repository so the APK built is functional.
The build pipeline clones pelya repo, and applies the patch you point out to correct the mentioned issues. It is awkward, but it is temporary (until pelya patches the issue) so we get a functional APK. An alternative would have been to fork pelya's repo, patch the fork, and clone from the fork.
prissi,
I have seen the line I mentioned being removed, but that is not the only compilation issue as some code was duplicated on the commit https://github.com/aburch/simutrans/commit/4a13eef290f9fd9c13b1432a1fa1465c5da31ed0 (https://github.com/aburch/simutrans/commit/4a13eef290f9fd9c13b1432a1fa1465c5da31ed0).
Please consider the 2nd patch I provided; it is an simpler alternative to the linked commit, because it reduces the whole change in fluidsynth to only 2 lines of code.
r10019
Quote...
2021-08-18T15:26:38.8126422Z ===> HOSTCXX bauer/fabrikbauer.cc
2021-08-18T15:26:38.8576048Z /opt/android-sdk-linux/ndk/23.0.7599858/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi16-clang++ -g -ffunction-sections -fdata-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mthumb -Wformat -Werror=format-security -Oz -DNDEBUG -fPIC -isystem/android-sdl/project/jni/application/../sdl-1.2/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../ogg/include -isystem/android-sdl/project/jni/application/../flac/include -isystem/android-sdl/project/jni/application/../vorbis/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../bzip2/include -isystem/android-sdl/project/jni/application/../fluidsynth/include -fpermissive -frtti -fexceptions -g -ffunction-sections -fdata-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mthumb -Wformat -Werror=format-security -Oz -DNDEBUG -fPIC -isystem/android-sdl/project/jni/application/../sdl-1.2/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../ogg/include -isystem/android-sdl/project/jni/application/../flac/include -isystem/android-sdl/project/jni/application/../vorbis/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../bzip2/include -isystem/android-sdl/project/jni/application/../fluidsynth/include -fpermissive -O1 -DNDEBUG -DUSE_FREETYPE -I/android-sdl/project/jni/application/../freetype/include -DUSE_FLUIDSYNTH_MIDI -Wall -Wextra -Wcast-qual -Wpointer-arith -Wcast-align -I/android-sdl/project/jni/application/../sdl-1.2/include -D_GNU_SOURCE=1 -D_REENTRANT -DCOLOUR_DEPTH=16 -c -MMD -o build/armeabi-v7a/bauer/fabrikbauer.o bauer/fabrikbauer.cc
2021-08-18T15:26:38.9478993Z music/fluidsynth.cc:199:2: error: unterminated conditional directive
2021-08-18T15:26:38.9481309Z #ifdef _WIN32
2021-08-18T15:26:38.9482549Z ^
2021-08-18T15:26:38.9924298Z ===> HOSTCXX bauer/goods_manager.cc
2021-08-18T15:26:38.9990093Z 1 error generated.
2021-08-18T15:26:39.0482872Z make[1]: *** [common.mk:51: build/armeabi-v7a/music/fluidsynth.o] Error 1
2021-08-18T15:26:39.0495669Z /opt/android-sdk-linux/ndk/23.0.7599858/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi16-clang++ -g -ffunction-sections -fdata-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mthumb -Wformat -Werror=format-security -Oz -DNDEBUG -fPIC -isystem/android-sdl/project/jni/application/../sdl-1.2/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../ogg/include -isystem/android-sdl/project/jni/application/../flac/include -isystem/android-sdl/project/jni/application/../vorbis/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../bzip2/include -isystem/android-sdl/project/jni/application/../fluidsynth/include -fpermissive -frtti -fexceptions -g -ffunction-sections -fdata-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mthumb -Wformat -Werror=format-security -Oz -DNDEBUG -fPIC -isystem/android-sdl/project/jni/application/../sdl-1.2/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../ogg/include -isystem/android-sdl/project/jni/application/../flac/include -isystem/android-sdl/project/jni/application/../vorbis/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../jpeg/include -isystem/android-sdl/project/jni/application/../png/include -isystem/android-sdl/project/jni/application/../freetype/include -isystem/android-sdl/project/jni/application/../bzip2/include -isystem/android-sdl/project/jni/application/../fluidsynth/include -fpermissive -O1 -DNDEBUG -DUSE_FREETYPE -I/android-sdl/project/jni/application/../freetype/include -DUSE_FLUIDSYNTH_MIDI -Wall -Wextra -Wcast-qual -Wpointer-arith -Wcast-align -I/android-sdl/project/jni/application/../sdl-1.2/include -D_GNU_SOURCE=1 -D_REENTRANT -DCOLOUR_DEPTH=16 -c -MMD -o build/armeabi-v7a/bauer/goods_manager.o bauer/goods_manager.cc
2021-08-18T15:26:39.0506047Z make[1]: *** Waiting for unfinished jobs....
2021-08-18T15:26:40.5118481Z make[1]: Leaving directory '/android-sdl/project/jni/application/simutrans/simutrans'
2021-08-18T15:26:40.5128036Z make: *** [CustomBuildScript.mk:54: simutrans/libapplication-armeabi-v7a.so] Error 1
2021-08-18T15:26:40.5133744Z make: Leaving directory '/android-sdl/project/jni/application'
2021-08-18T15:26:40.5141465Z ##[error]Process completed with exit code 1.
2021-08-18T15:26:40.5252244Z Post job cleanup.
2021-08-18T15:26:40.7506555Z [command]/usr/bin/git version
2021-08-18T15:26:40.7561484Z git version 2.32.0
2021-08-18T15:26:40.7625083Z [command]/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
2021-08-18T15:26:40.7658499Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
2021-08-18T15:26:40.7933682Z [command]/usr/bin/git config --local --name-only --get-regexp http\.https\:\/\/github\.com\/\.extraheader
2021-08-18T15:26:40.7955997Z http.https://github.com/.extraheader
2021-08-18T15:26:40.7966172Z [command]/usr/bin/git config --local --unset-all http.https://github.com/.extraheader
2021-08-18T15:26:40.8002461Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :
2021-08-18T15:26:40.8316190Z Cleaning up orphan processes
Talking about fluidsynth, does the music work on Android? I don't have an Android to test. The audio driver used is sdl2 (sdl1.2 is enough?) and a recent version of fluidsynth is needed (>=2.1.0, early 2020) for this driver. If such versions are not available, a different driver (https://github.com/FluidSynth/fluidsynth/wiki/Audio-Drivers) for Android may be used.
P.D.: Thank you very much for your work on this, krosk. I'm very happy to see Simutrans working on a mainstream mobile OS finally, even if there are still a lot of adjustments to be done to be playable.
@Krosp The patch for fluidsynth could not directly applied to the head. So I tried to extract that changes manually, an error prone process. Please provide a patch to either a certain revision (and state that revision) or to the head, because I cannot use github commit codes in my workflow. Sorry.
@Roboron, thanks for the kind words. As of now, i hear no music. The fluidsynth version it is using is also too old I believe, and making the android version use SDL2 is not yet within reach, so switching to a different driver for android would be a good option? I will look into it.
@Andarix, thanks for pointing out the remaining compile error.
@ceeac, thanks for fixing it !
@prissi, I own the mistake and caused additional work for you guys, sorry. The patch I provided that was incomplete. This mistake is pointing out glaring flaws in my setup and development process (manual steps prone to mistakes), so I take measures to streamline this. Future patches will state which revision they apply to.
In any case, it is building now so here you have it, nightly for Android ! Thanks everyone.
I am very grateful for your work. I had Android on my radar for a long time (this is why I even asked Pelya in May again) and I am very happy that this was sucessful.
please test the apk
https://github.com/Andarix/simutrans/releases (https://github.com/Andarix/simutrans/releases)
pelya has updated his repository and merged the video glitch patch, so we do not need to patch it ourselves.
Below is a patch applicable for r10031 that removes the android patch on /.github/android folder.
THanks, comitted in r10033
r10033 not compile
Quote2021-08-20T18:52:54.2602977Z ##[group]Run if [ -f $GITHUB_WORKSPACE/.github/android/*.patch ]; then cp -r $GITHUB_WORKSPACE/.github/android/*.patch .; fi;
2021-08-20T18:52:54.2604154Z [36;1mif [ -f $GITHUB_WORKSPACE/.github/android/*.patch ]; then cp -r $GITHUB_WORKSPACE/.github/android/*.patch .; fi;[0m
2021-08-20T18:52:54.2605020Z [36;1mif [ -f *.patch ]; then git apply *.patch; fi;[0m
2021-08-20T18:52:54.2606272Z [36;1msed -i "s/^AppVersionCode=[0-9]\+/AppVersionCode=$(svnversion project/jni/application/simutrans/simutrans)/" ./project/jni/application/simutrans/AndroidAppSettings.cfg[0m
2021-08-20T18:52:54.2608436Z [36;1msed -i "s/^AppVersionName=\"[0-9]\+.[0-9]\+\"/AppVersionName=\"r$(svnversion project/jni/application/simutrans/simutrans)\"/" ./project/jni/application/simutrans/AndroidAppSettings.cfg[0m
2021-08-20T18:52:54.2653884Z shell: /usr/bin/bash -e {0}
2021-08-20T18:52:54.2654285Z env:
2021-08-20T18:52:54.2655349Z DEFAULT_PAKSETLINK: https://downloads.sourceforge.net/project/simutrans/pak64/122-0/simupak64-122-0.zip
2021-08-20T18:52:54.2656505Z DEFAULT_PAKSETFILE: simupak64-122-0.zip
2021-08-20T18:52:54.2657172Z ANDROID_HOME: /opt/android-sdk-linux
2021-08-20T18:52:54.2657805Z ANDROID_SDK_HOME: /opt/android-sdk-linux
2021-08-20T18:52:54.2658458Z ANDROID_SDK_ROOT: /opt/android-sdk-linux
2021-08-20T18:52:54.2659267Z ANDROID_SDK: /opt/android-sdk-linux
2021-08-20T18:52:54.2659817Z ##[endgroup]
2021-08-20T18:52:54.2780634Z error: patch failed: project/jni/application/simutrans/AndroidAppSettings.cfg:74
2021-08-20T18:52:54.2781920Z error: project/jni/application/simutrans/AndroidAppSettings.cfg: patch does not apply
2021-08-20T18:52:54.2802840Z ##[error]Process completed with exit code 1.
prissi, the patch I provided removes the file in .github/android, but on the SVN trunk / git mirror, the file is still there. Maybe you have to remove it manually?
Yes, I have to. Thank you.
r10034 works
Quote from: krosk on August 19, 2021, 06:37:49 AMThe fluidsynth version it is using is also too old I believe, and making the android version use SDL2 is not yet within reach, so switching to a different driver for android would be a good option? I will look into it.
It is just a matter of adding an extra ifdef for Android with the driver. Not sure if the attached patch works, since I can't test it. Please do so.
One note: I see Pelya added previously a soundfont for Android (https://github.com/aburch/simutrans/commit/b5d46e5bf087318ef8c3f6e191239b5473739086#diff-df72854a6bd7c93a0632db453e323a8cab4212fe5664607191b16252c62f905a), but I don't think this comes bundled with Android OS. In such a case, the game will inform you that a soundfont is missing (and you'll have to bundle one).
Following @Roboron post, I investigated the issue of music, and manage to enable it for Android. Thanks Roboron for the direction.
This time instead of embedding a patch, I pointed to a fork of pelya repository for simutrans at https://github.com/krosk/commandergenius/commits/sdl_android_prebuilt (https://github.com/krosk/commandergenius/commits/sdl_android_prebuilt). The important updates done on that forked repo are:
- embedding a prebuilt fluidsynth 2.2.2 library and dependencies (downloaded from https://github.com/FluidSynth/fluidsynth/releases/tag/v2.2.2 (https://github.com/FluidSynth/fluidsynth/releases/tag/v2.2.2))
- changing the location of the downloaded soundfont so it appears in the simutrans options (putting the sf2 file in the /music folder)
The patch below, applicable to r10048:
- change the build pipeline to use the forked repo
- remove the exception case in fluidsynth code (ifndef __ANDROID__) we introduced because the function we excluded is now available with the updated fluidsynth
Upon game start, there will be a warning that no soundfont was found; just go to the options/sound and select the included soundfont from there.
For the curious minds:
- pelya repository includes fluidsynth 1.1.3, a version too old to have any android support (in particular, the oboe driver)
- pelya repository includes libraries by source code to be compiled, but not prebuilt libraries
Compiling an updated fluidsynth source code was too complex due to the 3rd party dependencies (toolchain, libs, etc...). Fortunately, fluidsynth team provides prebuild libraries for Android, that I plugged into pelya repository. I had to replace a few libs too, so the changes in my fork of pelya probably won't go upstream. For now, the android build will depend on my fork.
Thank you very much. Now we are close to a next release with also Android on board!
Quote from: krosk on August 25, 2021, 10:24:29 AM
- changing the location of the downloaded soundfont so it appears in the simutrans options (putting the sf2 file in the /music folder)
Upon game start, there will be a warning that no soundfont was found; just go to the options/sound and select the included soundfont from there.
To make this more straightforward to the end user, we could split the default soundfonts we search for on paths and soundfonts names. This way we can look for those soundfonts names also on the music directory first (then repeat with system paths), and the user wouldn't need to set it manually if they are bundled with Simutrans instead of installed system-wide. Proposed patch attached.
Heyo, weird question, maybe I've missed it, but can you tell me where the Pakset is stored and how to swap it?
@Roboron, +1 for your patch.
@Flemmbrav, after install you should have a folder akin to /storage/emulated/0/Android/data/com.simutrans/files/ (the part not in bold will depend on your smartphone). The paks go into that folder. For instance, the default pak64 is Android/data/com.simutrans/files/pak. Upon running the next time, you will be prompted for choosing among the installed paks, like on PC.
EDIT:
@prissi, additional patch, that ties in-game logging to Android logcat. Android redirects stdout and stderr to /dev/null, and introduces different logging functions for logcat, The patch below applicable to r10049 makes use of them. For those who want to capture the logs, add the command line parameters -debug x at the beginning (SDL config), and capture logs via adb logcat -s com.simutrans.
If the Unix command line works in Android, one could install paks with the builtin dialog. To see this dialog, Simutrans nedds to be started without a pak, or if two paks are installed, Googling tells me that this could work, but it may choke on wget or curl trougles or write protected directories or no unzip etc. I will try to test this this evening.
@Flemmbrav
I would very much like to have a dumbed down starter pak like once discussed for steam in the pak192 forum. For small screens like a smartphone pak192 seems very good. pka64 is rather small.
@prissi agree! I got a bit more than just a bit irl in the past years, but I still do follow that thing. Lucky us, I'm sick these days so I could take a look at that again
Rather get well first ...
Quote from: prissi on August 27, 2021, 02:39:30 PM
Rather get well first ...
I agree with @Prissi, I hope you recover soon. ;)
Friendly reminder that there are two patches waiting on this thread, the log patch (https://forum.simutrans.com/index.php?action=dlattach;topic=21062.0;attach=29819) from krosk and a fluidsynth patch (https://forum.simutrans.com/index.php?action=dlattach;topic=21062.0;attach=29819) by myself.
@prissi
Quote from: Roboron on September 09, 2021, 05:42:54 PM
Friendly reminder that there are two patches waiting on this thread, the log patch (https://forum.simutrans.com/index.php?action=dlattach;topic=21062.0;attach=29819) from krosk and a fluidsynth patch (https://forum.simutrans.com/index.php?action=dlattach;topic=21062.0;attach=29819) by myself.
@prissi
Well, those of us who have spent a long time in the forum know that our dear @prissi is usually somewhat forgetful hehehe :D ... but of course with so many things on his agenda it must be difficult for him to remember everything.
Greetings to all !.
--
Quote from: krosk on August 25, 2021, 09:54:51 PM
@prissi, additional patch, that ties in-game logging to Android logcat. Android redirects stdout and stderr to /dev/null, and introduces different logging functions for logcat, The patch below applicable to r10049 makes use of them. For those who want to capture the logs, add the command line parameters -debug x at the beginning (SDL config), and capture logs via adb logcat -s com.simutrans.
This patch could use cbuffer_t to get rid of fixed size char buffers. Then it could be included.
submitted the fluidsynth patch in r10084.
@Dwachs
As instructed, the attached patch (applicable to r10084) has switched to cbuffer_t.
I am very happy with this project!
There is something very important that I think we are overlooking.
Zoom in and out with two fingers, and it is that inplementing this in android would greatly improve the playability on touch screens. :C
It would be a shame if we don't have this in the first official version released for android.
What do you think of this friends? .
submitted the logging-patch in r10085.
The zoom gesture is only supported with SDL2 ... And then it was not working. I submitted something that makes SDL2 useful with finger on my touchscreen under window in r10087/10088
@Yona-TYT
Libsdl android has a handy feature which is able to map pinch gestures to a command.
In this case, I mapped the pinch gestures to emulate mouse wheel, which achieves map zoom in/out via pinch.
However this is not an optimal fix; for example mouse wheel also controls list scrolling, and pinching a list will make it scroll up/down; definitely an incorrect behavior.
Nonetheless, I will submit the patch later since the pros are bigger than the cons.
@prissi
Good news; I make it a goal to move the android port to SDL 2, so it will benefit from native touch support with SDL2 from other platforms.
Since windows also trnslates pinch to scroll wheel events, also SDL2 will behave the same ... i.e. scrolling in lists with pinch.
Quote from: prissi on September 11, 2021, 02:47:15 PM
The zoom gesture is only supported with SDL2 ... And then it was not working. I submitted something that makes SDL2 useful with finger on my touchscreen under window in r10087/10088
Thank you very much, I will try as soon as it is available. :D Edit.
Ah wait! ... :police: :police: :police: This is just SDL2, and the android version is not ported yet, therefore it is not possible for me to test. ::'(
Quote from: krosk on September 11, 2021, 03:03:48 PM@prissi Good news; I make it a goal to move the android port to SDL 2, so it will benefit from native touch support with SDL2 from other platforms.
This is great! I'm happy to hear this!. ;D
Patch applicable to r10089.
This patch configures libsdl-android to map pinching touch events to mouse wheel (they were previously mapped to keyboard + and keyboard -); the cfg file change is on the libsdl-android repo fork.
Thanks, submitted. in r10092.
For some reason it no longer works on my device, it closes right after stop loading.
Patch applicable to r10103.
The github actions pipeline is again silently passing upon failure to download the soundfont (occasional 502 Bad Gateway reported by wget, https://github.com/aburch/simutrans/runs/3583126278?check_suite_focus=true#step:14:25170), which broke the apk reported by @Yona-TYT.
Previous patch was not exhaustive enough, so this one will retry for any reason except success and ensure build failure upon any error.
Additionally, as a bonus background work, the libsdl-android now downloads prebuilt openssl binaries, which should reduce building time by 10 minutes.
Commited, thank you
Well the above problem seems to be fixed.
Now I have a new problem, this time with the resolution of the screen, before it looked better on my device, now it does not allow me to do anything. :-[
Look at the image as it looks:(https://github.com/Yona-TYT/imgs/raw/main/Screenshot_20210915-004541.jpeg)
@Yona-TYT
- What is the model of your device? This will let me know about your device native resolution and screen size for reference, to check if code behavior is expected.
- On the SDL prompt at the start on top of the screen there is a button "Change device configuration". Click on it, then on "Command line parameters, one argument per line":
* if you remove the line "-autodpi", it will switch to the native resolution with the correct aspect ratio.
* If the above is too small, you can customize resolution by typing "-screensize" in one line, and "800x600" in the next line; change the numbers for the resolution you want to have. Let me know also which resolution looks nice.
Quote from: krosk on September 15, 2021, 06:16:48 AM- What is the model of your device?
Alcatel one 5033E.
screen: 5" 18:9
@Yona-TYT
I had a look; your device native resolution is 960x480.
So removing the -autodpi argument in the command line options should be fine for you, even without setting a screensize. The resolution is low enough to display a big enough UI.
480 is a little bit too low to display most dialogues. So maybe oversize resolution to 1200x600
I'm not sure if "-screensize" is taking effect, as I can't tell the difference.
-screensize 1200x600
@Yona-TYT,
you need to write it on two separate lines:
-screensize
1200x600
Try it, but I think it won't work because it is above your smartphone resolution...
I have a gambling problem using a tool other than inspection.
The problem is that I cannot scroll the map while selecting a tool so I have to switch to inspection and this is very tedious.
I would like us to have a small box in the upper right corner that when dragging the cursor allows you to move around the map, no matter what tool is used.
@Yona-TYT
Point taken. Some other options exist to handle this, like drag the map with two fingers when a tool is enabled, etc. It is a matter of implementation I suppose.
@prissi
The attached patch, applicable to r10121, is:
- SDL2 (version 2.0.13) for Android
- An adjustment of the target DPI on mobile devices. 96 for computer screens (retina screens) is OK, for mobile devices it is too big; I put 192 for now. But now the game should be adaptative to each device screens.
99% of the work behind this patch is on my fork of pelya repository. https://github.com/krosk/commandergenius/tree/sdl2_android_prebuilt_2 (https://github.com/krosk/commandergenius/tree/sdl2_android_prebuilt_2)
Quote from: krosk on September 27, 2021, 01:13:04 PMPoint taken. Some other options exist to handle this, like drag the map with two fingers when a tool is enabled, etc. It is a matter of implementation I suppose.
And what would happen with "Zoom in and out with two fingers", or are they different touch gestures? .
You could also open the minimap without all the buttons and zoom in and use it as some kind of touchpad together with the tools. Also SDL2 opens up the possibility of using own gestures like three finder scrolling ...
@Krosk And thank you very much for this highly appreciated work. Incorporated in r10122.
Looking at the commits, I see that debug builds are the default. I wonder if this makes sense for most of the users might never see the debug messages on a smartphone and debug builds eat quite a lot more ram and CPU. (They also usually never look at them on the PC either ... )
@prissi, I see 2 drawbacks with using the minimap:
1- The displacement is opposite to that of the general map, that makes it confusing to move with it.
2- It is not good for practical uses since you have to be opening and closing the window, not to mention that the drag area changes in size depending on the zoom or the size of the map.
Hence my idea of a small drag area fixed in a corner where it does not obstruct visually, also you can use transparency to make it less of a visual obstruction.
For the different scroll direction in the minimap, you should switch off the inverse scrolling. For some reason it is the default in pak128, and since no other pakset set it explicitely, it stay default later on. Go to setting display and the inverse scrolling.
But as said, not three finger dragging as default option would be possible too. Please test r10123
There is a little problem here, I can't go back to the previous window if I accidentally hit the install pakset button.
(https://scontent.fccs1-2.fna.fbcdn.net/v/t39.30808-6/fr/cp0/e15/q65/244208954_4307783065965478_94496451297784393_n.jpg?_nc_cat=110&ccb=1-5&_nc_sid=110474&efg=eyJpIjoiYiJ9&_nc_ohc=RYCtQPHYRtIAX-29Fu9&_nc_ht=scontent.fccs1-2.fna&oh=34bfa3a213e9b82ef85fe436e3a132a1&oe=615BA05E)
@prissi
(I will disable the debug in my next patch; it was enabled for development convenience reasons...)
I tested the 3 fingers drag and dropping. When 3 fingers touch the screen, the scrolling works. But the number of fingers will naturally decrease from 3 to 2, from 2 to 1 as we drag the map. If a tool/building is selected, there will be a very short moment when only 1 finger touches the screen and the tool will activate (and build).
I don't have better suggestions at this time for enabling both a tool and a scrolling.
@Yona-TYT
Indeed, a cancel button would be welcome here.
Quote from: krosk on September 30, 2021, 08:48:43 PM@Yona-TYT
Indeed, a cancel button would be welcome here
It would also be good if the arrow button (back) of the android system did not return until the first window. ;)
I have a problem with the on-screen keyboard, it unfolds for no reason at startup.
Test the fingerhandling in r10125. It should no longer generate spurious event when using three finger scrolling. (However, I have no test device currently.)
With SDL2 Is it possible to have on-screen keyboard support on Android? .(https://scontent.fccs1-3.fna.fbcdn.net/v/t39.30808-6/fr/cp0/e15/q65/244459798_4318992721511179_652465534984115225_n.jpg?_nc_cat=103&ccb=1-5&_nc_sid=110474&efg=eyJpIjoiYiJ9&_nc_ohc=7z8zyCNOrgoAX-iUDxK&tn=MpjIkBwJAdgqjTSb&_nc_ht=scontent.fccs1-3.fna&oh=b776821594a7d81329696428633d57ec&oe=6160BF64)
Try to set "hide_keyboard=1" in simuconf.tab
Quote from: prissi on October 05, 2021, 05:45:20 AM
Try to set "hide_keyboard=1" in simuconf.tab
That should hide the keyboard, but I meant to automatically hide and show only if you are editing an input box for text or numbers.
Is this supported in SDL2? .
The setting does exactly what you want.
Quote from: prissi on October 07, 2021, 03:42:13 AM
[]The setting does exactly what you want.
[]that's great!
Edit.
I have activated the option but it is not working I'm afraid. :(
There was an error on closing the keybord, when the windows was just closed. But the call to SDL_StartTextInput() is there. Does the keyboard appear on opening the load dialoge?
If so, then maybe r10133 will correct open and close it again.
Quote from: prissi on October 08, 2021, 01:55:03 AM
There was an error on closing the keybord, when the windows was just closed. But the call to SDL_StartTextInput() is there. Does the keyboard appear on opening the load dialoge?
If so, then maybe r10133 will correct open and close it again.
exactly, the keyboard appears and it is difficult to hide it.
r10133 should hide it again then. Until then, you must finish text input with "RETURN" key, that should hide the keyboard again.
He asked me if it is possible to distinguish between text and numeric inputs, this would be nice.
Quote from: Yona-TYT on October 08, 2021, 02:14:27 AMHe asked me if it is possible to distinguish between text and numeric inputs, this would be nice.
[]For example, if I click on a numeric entry, the keyboard should look like this:
(https://scontent.fccs1-2.fna.fbcdn.net/v/t39.30808-6/fr/cp0/e15/q65/244594276_4328903920520059_468883133798645884_n.jpg?_nc_cat=109&ccb=1-5&_nc_sid=110474&efg=eyJpIjoiYiJ9&_nc_ohc=U68DZCU4yPgAX8llIey&_nc_ht=scontent.fccs1-2.fna&oh=66661cbb3b1c12699838b8d4d7429cf9&oe=6164774E)
There is no function in SDL for this, as far as I know.
Quote from: prissi on October 08, 2021, 01:43:08 PM
There is no function in SDL for this, as far as I know.
Maybe not implementing. :(
In JavaScript it is done with a simple "type = number" attribute.
I'm afraid the last review gives me more problems.
Buttons do not respond to touch sensor and keyboard still appears at startup. :(
The keyboard appearing at startup is likely an oddity from the Java part in Android, so it could be some code to correct on the Android side, not on the game side.
That said, arent you supposed to be able to hide the keyboard with a press of the (on screen) back button? This is a generic Android behavior. (Making the back/menu/jump buttons appearing is normally possible by sliding fingers to show the notification panel)
EDIT: There was one SDL_TextInput too much. Fixed in r10142.
I am handling all the proper finger handling code. Are you using the emulator or a real device?
@prissi
I am using a real device.
Well, on my windows touchscreen, I get the right finder events.
I can barely get here.
(https://scontent.fccs1-3.fna.fbcdn.net/v/t39.30808-6/fr/cp0/e15/q65/245167014_4333410680069383_3489564524790227387_n.jpg?_nc_cat=105&ccb=1-5&_nc_sid=110474&efg=eyJpIjoiYiJ9&_nc_ohc=i-W5PsxD4F4AX8H7k4x&_nc_ht=scontent.fccs1-3.fna&oh=34b5035e9680dd2e19d82c41d3ec11f2&oe=61672AAF)
r10142, The touch response is still broken I'm afraid :(.
I like to listen to the midi of simutrans on my mobile, but now the touch does not respond. :'(
Please try r10160. I have made a lot of effort the better filter events.
Unfortunately, the problem is still there, I can't press the buttons in the welcome window, and in the package selection window somehow progress is made. :(
The last time the touch worked for me was in r10123.
if I remember correctly, from r10133 the touch sensor stopped working for simutrans.
I run simutrans from github in blustacks. The button event coord is registered, but on a different position than the actual one on the screen. The scaling for finder event is different than for mouse events. Should work as intended again for r10165.
@Prissi, I'm going to test, that downloading 134mb consumes my data plan a lot.🤪
Finding this, maybe it can serve as a reference: 😎
https://forum.simutrans.com/index.php?topic=13947.0
Rhater wait then for Wifi access ... it is not that urgent.
When testing in the emulator, anz savegame will not be restored after quitting.
Quote from: prissi on October 17, 2021, 07:37:28 AM
Rhater wait then for Wifi access ... it is not that urgent.
There is no other way I'm afraid.
Quote from: prissi on October 17, 2021, 07:37:28 AMWhen testing in the emulator, anz savegame will not be restored after quitting.
That is correct, apparently it had been broken when ported to sdl2, I was about to report it but I got stuck with the touch inputs.
I have been trying to download the apk, but unfortunately my network is very unstable and the github server is very cruel in not allowing to resume downloads. :-[
You can download to your computer and use the USB connection to transfer to your phone (needs to enable debug mode, I think). That should also reduce your data plan usage.
Quote from: prissi on October 18, 2021, 03:20:47 AMYou can download to your computer and use the USB connection to transfer to your phone (needs to enable debug mode, I think).
I use something called "qrcp" in linux to transfer the files to my phone using the wifi network. 8)
(https://raw.githubusercontent.com/Yona-TYT/imgs/main/test-yona.png)
Quote from: prissi on October 18, 2021, 03:20:47 AMThat should also reduce your data plan usage.
We don't have unlimited internet service I'm afraid.
Great, the keyboard works fine and is already responding to the touch sensor.
Two problems:
The settings are not saving, at least they are not on my device.
When using both fingers to zoom in on the minimap for some reason it stops responding to the touch sensor.
Thank you, good news. Does the touch come back after a three finger scroll? Or after touching somewhere (may in the menu?) In my tests, I had mostly trouble buying engines, first touch activate the engine and then I needed a double tap rather. Anyway, I think that can be done via the simulator.
I think the saving is probably something general with Android, and occurs also in the simulator. So I should able to test this. It is probably related to the not saving on quit, since it would save to the same directory as the settings.
Quote from: prissi on October 18, 2021, 06:35:15 AMThank you, good news. Does the touch come back after a three finger scroll? Or after touching somewhere (may in the menu?) In my tests, I had mostly trouble buying engines, first touch activate the engine and then I needed a double tap rather. Anyway, I think that can be done via the simulator.
When zooming in with two fingers in the minimum, the touch is trapped there and no longer allows you to release more, neither using 3 fingers nor touching anywhere.
Hmm, the way the touch is implemented in SDL2 on Android sucks. Either I get too many finger up messages, or, apparently I can also get none. Hmm. I will try something.
Quote from: prissi on October 19, 2021, 12:15:51 AMHmm, the way the touch is implemented in SDL2 on Android sucks. Either I get too many finger up messages, or, apparently I can also get none. Hmm.
[]I apologize, I said minimum, but I meant mini-map, I hope I haven't confused you with that silly translation error.
No, the finger event (at least under windows) have a long delay compared to related mouse and actual finger state. That makes suppressing multi-touch event difficult. I tried something, but I would be more patient with another download, as I will play around more at home.
@prissi, Before porting to SDL2 you could use the Android "back" button to close the last open window, can you make this work again? It is very useful.
THere seems now a special keycode for this. Maybe it works in r10181
Regarding themes, I would like to increase the drag area to resize windows as it is very tedious to focus with my device.
The "gui_gadget_width" parameter does just that, but I don't think it changes the size of the resize area (or if it is?). ???
Android need some more patches to the simuconf.tab, like to activate the roboto TTF in 17 points and maybe using the large theme as default (and teh large them need indeed larger corners.
Quote from: Yona-TYT on October 19, 2021, 03:28:22 AM
Regarding themes, I would like to increase the drag area to resize windows as it is very tedious to focus with my device.
The "gui_gadget_width" parameter does just that, but I don't think it changes the size of the resize area (or if it is?). ???
https://forum.simutrans.com/index.php/topic,21181.0.html (https://forum.simutrans.com/index.php/topic,21181.0.html)
Quote from: Dwachs on October 16, 2021, 12:22:06 PMShould be better in r10159. Size is taken to be maximum of the resizer-image and scrollbar sizes.
I think that if the size of the scroll bars is increased, then the resizing corners should increase as well. 8)
Quote from: prissi on October 19, 2021, 06:48:28 AMpoints and maybe using the large theme as default (and teh large them need indeed larger corners.
The large modern theme works decent for me, my only complaint is the corners I mentioned earlier.
@Prissi, can you make the windows roll up? On PC this is done with a secondary click on the title bar but ... What do you think about holding down the title bar for a few seconds on Android?
Holding down a few seconds is unfortunately not something done easily with the event system. Holding down with two gingers is possible, in principle.
Quote from: prissi on October 21, 2021, 03:22:56 AM
Holding down a few seconds is unfortunately not something done easily with the event system. Holding down with two gingers is possible, in principle.
And how about double clicking?.
EDIT: Double tap will be recognised by Simutrans already, but only if the finger is is the exact same position. So about every 5th to 20th trial ... It will also change the rollup state in r10186.
The double click is also used in depots, so buying vehicles there has the same difficulties.
Quote from: prissi on October 21, 2021, 07:45:13 AMThe double click is also used in depots, so buying vehicles there has the same difficulties.
It is not that difficult for me, maybe it will work well. 8)
The icons in the title bar are still a challenge for me, they are very difficult to target and it is very frustrating.
In some android browsers they implement a small preview box that shows the area of the touch but on a more enlarged scale, this allows to press the button comfortably.
(https://github.com/Yona-TYT/imgs/raw/main/tes-android.png)
Quote from: prissi on October 21, 2021, 07:45:13 AMEDIT: Double tap will be recognised by Simutrans already, but only if the finger is is the exact same position. So about every 5th to 20th trial ... It will also change the rollup state in r10186
This is great! ... I will update and test tonight. 😎
I have tried the latest changes:
The configurations are still not saved, it seems that when the closing process is executed from the process manager, the android system does not give simutrans time to save anything (forcibly closing apparently). If instead we close from the "Quit" button, simutrans only destroys the map, it closes and immediately a system window appears indicating that "Simutrans has stopped" (This exits if an app has a malfunction).
I finally tested it on a Fire tablet. The first test was fine, it could start the keyboard was hidden, the game was like when left. Only the mid played one (chopped and did not stopped even when youtube played.
Second time, I could not hide the keyboard.anymore. I think somehow the hide keyboard feature is overwritten.
I have made some progress, and I think the keyboard handling is more like it should be, as well as the finger usage.
I am using bluestacks (and emulator) for testing, but it might happen on any device:
11-03 23:23:06.616 3514 3537 D com.simutrans: Debug: action_triggered libcurl initialized
11-03 23:23:07.884 3514 3537 D com.simutrans: Debug: action_triggered pak target https://downloads.sourceforge.net/project/simutrans/pak64.japan/120-0/simupak64.japan-120-0-1.zip
11-03 23:23:07.884 3514 3537 D com.simutrans: Debug: action_triggered download successful to /storage/emulated/0/Android/data/com.simutrans/files/pak64.japan-120-0-1.zip, attempting extract
11-03 23:23:07.885 3514 3537 D com.simutrans: Debug: read_zip cannot open zip archive "/storage/emulated/0/Android/data/com.simutrans/files/pak64.japan-120-0-1.zip": Seek error: Value too large for defined data type
11-03 23:23:07.885 3514 3537 D com.simutrans: Debug: read_zip zip archive opened
--------- beginning of crash
Quote from: prissi on November 03, 2021, 02:24:23 PM
I have made some progress, and I think the keyboard handling is more like it should be, as well as the finger usage.
I am using bluestacks (and emulator) for testing, but it might happen on any device:
11-03 23:23:06.616 3514 3537 D com.simutrans: Debug: action_triggered libcurl initialized
11-03 23:23:07.884 3514 3537 D com.simutrans: Debug: action_triggered pak target https://downloads.sourceforge.net/project/simutrans/pak64.japan/120-0/simupak64.japan-120-0-1.zip
11-03 23:23:07.884 3514 3537 D com.simutrans: Debug: action_triggered download successful to /storage/emulated/0/Android/data/com.simutrans/files/pak64.japan-120-0-1.zip, attempting extract
11-03 23:23:07.885 3514 3537 D com.simutrans: Debug: read_zip cannot open zip archive "/storage/emulated/0/Android/data/com.simutrans/files/pak64.japan-120-0-1.zip": Seek error: Value too large for defined data type
11-03 23:23:07.885 3514 3537 D com.simutrans: Debug: read_zip zip archive opened
--------- beginning of crash
That's great, I'll try what I have time.
By the way, you were right with the double click, it is very difficult to get it to minimize / roll the windows. 😒
THis is currently only on my playground branch: https://github.com/prissi/simutrans/actions
r10219 should finally have Android support that is mostly working. It should hide the keyboard, install paks, mute midi in background and saves settings on exit. Unfortunately, it still does not save games on exit.
En la última revisión tengo problemas con la resolución de la pantalla. ☹️
https://www.mediafire.com/view/0g89xqlbwli974p/Screenshot_20211110-134824.jpeg/file (https://www.mediafire.com/view/0g89xqlbwli974p/Screenshot_20211110-134824.jpeg/file)
(https://www.mediafire.com/view/0g89xqlbwli974p/Screenshot_20211110-134824.jpeg)
I think this is a problem with Autodpi. It probably needs to enforce that at least 600 pixcels are seen in vertical resolution ... All my test devices had higher resolution though
Quote from: prissi on November 11, 2021, 03:03:23 AMI think this is a problem with Autodpi. It probably needs to enforce that at least 600 pixcels are seen in vertical resolution ... All my test devices had higher resolution though
Well I think I will try again with the last revision.
Another detail, the automatic detection of the language for SDL2 does not seem to be working well in android, since the language in my device is "Spanish", but the selected one is "English". ???
Now the Android package weighs 77.4mb, that's a big relief for me. 😎
Is it possible to use an svg as an icon in android ?. 8)
I would love for us to use a more modern image like the one attached:
I have no idea, this is quite complicated, since I have only very indirect control on the actual building process.
Unfortunenately Google does no longer accepts apk for Upload to google play. Since the building of abb is very complex using the current github, the next release will not have an official Android version on Play Store anytime soon. (There will be one on Sourceforge).
Maybe here is a working play store link (for the first 100 users) for simutrans aab
https://play.google.com/apps/internaltest/4699671641439592866
I'm not "invited", does that mean we have 100 users already? That's awesome!
We could also consider distributing Simutrans on F-Droid, since we are open source. But I don't have much knowledge about the process, I only know that build instructions must be specified so that F-Droid can run their own builds (so one doesn't actually submit the apk nor any binary).
Maybe I need to get your Email for your google account via pm or email to invite.
nightly-android-bundle.yml
Quote...
2021-12-31T08:14:01.9443744Z > Task :app:bundleRelease
2021-12-31T08:14:01.9444208Z
2021-12-31T08:14:01.9444718Z BUILD SUCCESSFUL in 16s
2021-12-31T08:14:01.9446107Z 35 actionable tasks: 9 executed, 26 up-to-date
2021-12-31T08:14:01.9833409Z ##[group]Run svenstaro/upload-release-action@v1-release
2021-12-31T08:14:01.9833961Z with:
2021-12-31T08:14:01.9835271Z repo_token: ***
2021-12-31T08:14:01.9835862Z file: /android-sdl/project/app/build/outputs/bundle/release/simutrans.aab
2021-12-31T08:14:01.9836483Z asset_name: simutrans.aab
2021-12-31T08:14:01.9836872Z tag: Nightly
2021-12-31T08:14:01.9837231Z overwrite: true
2021-12-31T08:14:01.9837555Z env:
2021-12-31T08:14:01.9837982Z ANDROID_HOME: /opt/android-sdk-linux
2021-12-31T08:14:01.9838520Z ANDROID_SDK_HOME: /opt/android-sdk-linux
2021-12-31T08:14:01.9839079Z ANDROID_SDK_ROOT: /opt/android-sdk-linux
2021-12-31T08:14:01.9839624Z ANDROID_SDK: /opt/android-sdk-linux
2021-12-31T08:14:01.9840078Z action_state: yellow
2021-12-31T08:14:01.9840441Z ##[endgroup]
2021-12-31T08:14:02.6308344Z ##[error]ENOENT: no such file or directory, stat '/android-sdl/project/app/build/outputs/bundle/release/simutrans.aab'
2021-12-31T08:14:02.6370188Z Cleaning up orphan processes
2021-12-31T08:14:02.6743308Z Terminate orphan process: pid (40841) (java)
Since the r10219 it is impossible for me to test, the performance is very bad, just 3fps.
I am concerned that other users will present this performance problem, I assume that hardware acceleration is needed to improve this, right?
The optimised builds should have better performance. I admid, I could not test it on the old Huwei (Android 9) I got, Simutrans did not start.
Quote from: prissi on January 02, 2022, 11:57:24 AM
The optimised builds should have better performance. I admid, I could not test it on the old Huwei (Android 9) I got, Simutrans did not start.
Where do I get the optimized builds?
The one I have I downloaded from GitHub.
My device is an Alcatel One, Android 8.
There were no SDL2 display related changes in recent releases, thus the github should work as before. I will ivestigate.
Group is full? So I have to play with the Nightly build apk and a stable version comes not in the near future?
@prissi
About the double click, is it possible that it is fulfilled if the second click is not exactly in the same place?
For example, when minimizing / rolling windows I have problems with touch, since it is difficult to click twice in the same place.
But in my humble opinion, I think the second click would be valid if it is done in the same title bar (other than in exactly the same place).
In principle I totally agree, but the realisation is not trivial at all.
Simutrans 123.0.1 is now available in open testing under
https://play.google.com/store/apps/details?id=com.simutrans
Link does not work ...
Google is a nightmare. I have been just clicking somewhere until it seemed to work. Back on trying.
no, not found, and if you search for simutrans in google play there is none. Only OpenTTD and a lot of others.
You should test it with a other account.
It seems to have to pass internal tests at google, which can take up to a week for the first upload.
Thanks to the screen scaling now I get 14 fps (it's not much but with my mediocre device I should not wait long).
Now I can do tests.
I have problems using the scroll bar in the windows, it is very tedious.
It would be great to be able to move like it from the web browser pulling up or down, what do you think about this? .
(https://raw.githubusercontent.com/Yona-TYT/imgs/main/Screenshot_20220220-194556.jpeg)
I agree, and dragging scrollpanes is quick to implement, see r10498. Unfortunately in will not work on all scrollbars, but a good lot of them. The minimap works differently, so there you have to use the scrollbars.
Very grateful to you, this will be very helpful .😎
Quote from: prissi on February 21, 2022, 05:40:19 AMI agree, and dragging scrollpanes is quick to implement, see r10498. Unfortunately in will not work on all scrollbars, but a good lot of them. The minimap works differently, so there you have to use the scrollbars.
I did some tests on my device but unfortunately scrolling doesn't work in any window. :'(
The axis were swaped (i.e. up and down) but somehow it only worked with the GDI version, not SDL2. I am away, so I have to rely on blustacks for testing after the github built, so lets progress will be slow.
Quote from: prissi on February 21, 2022, 11:53:10 PMThe axis were swaped (i.e. up and down) but somehow it only worked with the GDI version, not SDL2. I am away, so I have to rely on blustacks for testing after the github built, so lets progress will be slow.
Quote from: prissi on February 21, 2022, 11:53:10 PMThe axis were swaped (i.e. up and down) but somehow it only worked with the GDI version, not SDL2. I am away, so I have to rely on blustacks for testing after the github built, so lets progress will be slow.
I've tried r10512, the panels are now responsive to drag, but scrolling seems to hang with large panels (large scrolls).
I found this problem in the debug tab of the tutorial scenario and in the help window.
(https://github.com/Yona-TYT/imgs/raw/main/Screenshot_20220225-072726.jpeg)
(https://github.com/Yona-TYT/imgs/raw/main/Screenshot_20220225-081304.jpeg)
Edit.This changes to affected to the desktop version.
In the Help window the cursor captures scrolling creating "Up and Down" scrolling when the cursor is moved.
When the cursor is captured, the mouse wheel no longer responds to scrolling.
r10513 should have the help window and mouse wheel working again. Did not note any slowness though
In the scenario window there is a small detail when dragging up (where the tabs are), there is an inadvertent tab change.
This happens in android and on the desktop because when the click is released on a tab it is considered as a normal click.
I wonder if it's okay for tabs to ignore the click release event. ???
Edit.
Quote from: prissi on February 26, 2022, 03:37:32 AMr10513 should have the help window and mouse wheel working again. Did not note any slowness though
It works very well!. This is another step in the adaptation to touch screens, this is very nice!. 8) 8) 8) 8)
Regarding the slowness, I would not know how to answer you since my device is a snail that barely reaches 14 fps (if I move the interface it drops to about 5 fps), so I am always going to notice extreme slowness I am afraid.
The problem is that the tab's events are processed before the scroll area's events. Hence the tabs catch the up event. Not sure how to take care of that.
A while ago I noticed an update that limited 1 window for city buildings, however this was removed for some reason.
I find it a good idea to use this on android as we have limited screen space.
I see no reason to have multiple object windows like: terrain objects, trees, buildings, tourist attractions, roads/ways, power grids...
A while ago I noticed an update that limited 1 window for city buildings, however this was removed for some reason.
I find it a good idea to use this on android as we have limited screen space.
I see no reason to have multiple object windows like: terrain objects, trees, buildings, tourist attractions, roads/roads, power grids...
What do you think of this exclusively on android?.
It is possible on compile time. One would give the info window an individual magic, so there would be only one such window.
On the performance: Disable midi. Midi rendering really sucked a lot of resources on my tablet when testing.
Quote from: prissi on February 26, 2022, 02:38:44 PMIt is possible on compile time. One would give the info window an individual magic, so there would be only one such window.
The expected behavior would be:
If there is an active window, it will be replaced by the next window (by clicking on another object), so the user doesn't have to close windows to open another one, right? .
Quote from: prissi on February 26, 2022, 02:38:44 PMOn the performance: Disable midi. Midi rendering really sucked a lot of resources on my tablet when testing.
If that frees up some performance, it's still slow... but it's my device's fault... I've tried it with another 2d game and the performance is lousy.
I've tried the new scrolling and it works great now! Thank you very much, this will make life easier for Android gamers 😄
Quote from: prissi on February 26, 2022, 02:38:44 PMIt is possible on compile time. One would give the info window an individual magic, so there would be only one such window.
It would still be necessary to one limit the windows, but I think I became very demanding hehehehe. 😅
You inspired me with the new pinned toolbar feature... https://github.com/aburch/simutrans/commit/4a5a1759237730a9d74e308e134fe0c4c1a4017e
This can be a very good idea to improve android experience with some windows.
For example informational windows (pop-up messages, buildings, trees...) can be fixed in a top corner.
Popup message shoudl disappear after some time. Also a popup in the wrong position may be ignored first.
Anyway, this thread got very long and the title was no longer matching, so I made a new thread for discussion.