I think I could just cherry-pick it, but would be handy if you can add some argument to Android build scripts that Travis trigger. So in future we can just create new branch in vcmi-android with modified Travis config and it’s will make build for us.
E.g like:
# Now we have
python3.5 ./build.py build-app
# But we can do
python3.5 ./build.py build-app HEAD
python3.5 ./build.py build-app develop
python3.5 ./build.py build-app experimental/sdl-color-fix
OR even better. Expose that argumnent and I’ll implement travis script that let us trigger build by creating new branch in vcmi-andoid like:
buildForMe/feature/ambientSounds
And it’s will build “feature/ambientSounds” branch from upstream.
Also in future we can just make Android builds on every commit / branch / PR just like we do for Linux GCC, Linux Clang, MXE and Mac. Sadly that would take time to implement and I have tons of other tasks on project right now.
Now I just no longer sure git submodules is right tool for the task there.
So probably this need to be changed at least for Travis builds…
So I don’t want to disrupt your workflow. Should we just implement cloning of actual VCMI develop instead of using submodule when it’s build by Travis?
I just not sure it’s actually worth to use submodule in this situation.
Probably I missing something, but most likely they not intended for that kind of use. E.g there no way to make git automatically grab latest commit. I’ll check how we can solve this.
Ok updated it and your patch actually fixed problem with red color on my device. Now only visual glitches I have is misplaced into video and some 1-2pixel line at bottom whee some weird white pixels could be flickering at times. I actually even managed to screenshot both line and intro glitch. I sent them through slack, please download one with line so you can see it.
Also one question there. Is internalData actually override assets from VCMI directory? Like “config” directory.
I understand you wanted to include some mods that are not in repository here, but really we cannot ship “extraResolutions” to Google Play. I not sure, but it’s might be made using H3 assets as source.
Other than that we’ll need to find out how to ship default mods after I’ll change how we distribute them.
Yay.
(actually, this might need some confirmation if it doesn’t break anything: the fix changes pixel mode chosen by gl to hardcoded RGB565 with 0 depth buffer)
You can add a call to “python3.5 ./update_internal_assets.py” on travis and assets will be recreated. Basically internalData is zipped content of Mods and config on repo. (the update_internal_assets script also tries to pack ./…/data/vcmi_submods folder, where I have templates + extra resolutions – recreating assets on travis won’t include them).
Edit ~ actually, some more explanations about overriding: I tried to organize the files like in the desktop version:
“internal” data that normally is in executable folder is placed in private, application-scoped folder (unpacked from internalData when starting the application for the first time)
“public” user data that normally is in “$appdata-like” location (config/settings.json, saves, maps etc) are in public folder that user can modify/delete
Downloading these submods on startup shouldn’t be a problem (but we probably should ask the user if he wants to; I’m not sure how common users without data plans are ).
@Intro: Do you mean that there’s some unused space on the top/left? It looks the same for me AND these black margins are also present in the desktop version as well. @bottom line: this will be much harder to debug. Honestly, this looks like some problem in SDL. Might also be connected to this post [forum.vcmi.eu/t/vcmi-for-android/784/199) where sdl displays random junk in the letterboxed space on the sides.
Problem is that we absolutely shouldn’t include mods with unclear licensing to our Google Play packages. After all it’s should be doable to rework them with free assets instead (extraResolutions at least).
build android package without them (rebuilding internalData without submods),
after starting the app for the first time (or basically any time when submods are not detected) ask user if he wants to download them -> download&unpack them to internal data folder.
Well, assuming that this method would be legally possible.
Issues:
Doesn’t load next scenario of campaign after showing introduction video of it. Hang on main picture - in my case third from [forum.vcmi.eu/t/vcmi-for-android/784/199).
Auto fight crashes VCMI right before showing results (creatures lost by attacker & defeater, …). Does in release version, doesn’t in latest develop.
Fight is something like “tap-action-tap-action-tap-…” or LONG wait for actions with pointer mode set to “Native with map swipe”. In dev.
Android keyboard could be made more usefull (hide,show,arrows…) when saving scenarios? something like in JuiceSSH during session.
I could upload saves. HMM III Complete, Android 7.0 & Android 6.0
Related to:
VCMI-1.4-api21-20170515-release.apk
VCMI-branch-develop-01e5f99-fb57108.apk
Do you mean “next scenario” as in moving to the next mission after winning the previous one? I guess I can check that, but it doesn’t look like android-specific problem.
Yeah, this was the vcmi problem at the time I built the app last time. Use automatic builds if possible, they’re the most up-to-date.
I’m not sure what you mean… pointer modes shouldn’t affect the performance (and even if they did, it’s relative mode that would be slower, as it needs some extra calculations). And if you mean the performance in general, then there isn’t much that I can do from android side.
Currently keyboard handling uses default SDL android implementation and I never really analyzed the logic. But honestly I’m not sure what to do there. Waiting for ideas.
One thing I can think of (not strictly about the keyboard) is to add the button to open the chat/console, because I don’t think there is a way to do it in the gui.
@SXX
I found out that the fix for the “red background” won’t behave correctly on all devices and will crash the app if that device doesn’t support the surface type that I forced. In this case I’ll probably need to add some better egl capabilities detection (a simple solution would be to check if RGB565/Depth0 is supported, otherwise fall-back to the gl-chosen default values – not sure if it’s possible to implement without messing up SDL config).
BTW today I played short game on Android and so far only problems I seen is battle machines tend to appear in army (though I guess this could be problem with outdated bundled config files) and also battle end tend to crash game for some reason.
Small note. I dropped VCMILIB_ADDITIONAL_SOURCES from CMakeList and instead added “ifdef” for Android-specific code. I hope this won’t break something since I really hope to at least share CMake configs.
Hello, Fay.
I’ve findout that issue not in “next scenarion” but even on second loading after one game was already loaded without complete exiting (to “desktop”) from game.
I’ve recorded videos with issues.
Next scenario hang - youtu.be/6Ev4pwCwzBE
Second load hang - youtu.be/qrPXmB2SEZ0
Slow fight - youtu.be/O867LD377Qs
Large keyboard vs keyboard use in JuiceSSH - youtu.be/Tc0ET_YVZMk
Hello SXX,
Where I should report not android related issues?
Because i’ve tried to switch to “next scenario” on PC (Linux) and one campaign scenario (Clearing the Border) loaded “next scenario” (After the Amulet) and i saved it to continue on android, but other campaign scenario (Graduation Exercise) crashed vcmi on PC on loading next scenario of campaign.
