Just tested previously posted API16 and API21 builds and to my surprise both worked quite well, I am on Android 7.0, OxygenOS 4.0.3, OnePlus 3T, game version is from GOG. Few things did irk me though:
[ul]
] While intro plays perfectly well, there is some significant lag after skipping it, like solid 4-8 seconds. Didn’t happen at all with xyz’s version but hey, that one instantly crashes when trying to load a game from the menu so what do I know. /:m]
] The way controls are implemented seem awful to me, I much more preferred xyz’s way of doing things, he made so your finger upon touching the screen would act as a mouse and controlled the cursor in that way which was really accurate and felt pretty good. If you’re still wondering the way he made right click work was that if you had one finger on the screen dragging the mouse around and put a second one anywhere it would instantly stop and hold right click. It’s really intuitive and is easy to figure out even if you don’t know it beforehand./:m]
] I know it was in the second point but for the love of god implement right click in some way/:m]
] Resolutions higher than 1280x768 might as well not exist for phones since stuff gets ridiculously small and hard to see, but I am guessing you can’t fix this without redrawing everything./:m]
] Whole menu, loading, displaying maps and that stuff in general is significantly laggier and slower than xyz’s version./:m]
] After you choose your options and start the game there is like 1/10 chance a random very slim flashing bar appears on the very right of your screen, no idea what the hell could that be about. Just something I noticed, doesn’t really impact gameplay in any significant way./:m]
] I know you said that the hero movement coding is complex and you don’t wanna mess with it but if you could find a way to fix it, it would make the game nearly indistinguishable from the desktop version, could easily be an android store release if you’d do that./:m][/ul]
That’s it for now, still hadn’t had the chance to properly test it all out but will prob often turn it on when I have free time and report if I see anything acting up. Thanks for making this btw, really cheered up my day, hope you don’t give up on the development, wish I could help in some way.
@SomeGuy147 Most of the differences probably come from the fact that xyz used unofficial sdl 1.2 port (github.com/pelya/commandergenius) and I used official sdl 2.0.
I installed xyz version to check how it works because I haven’t seen it for a very long time. I don’t have any old devices on me to check in-game, but menus worked correctly. So…
I think that in xyz’s version, actual loading is done before the intro starts (splashscreen + some black screen afterwards). Ideally I just need a change that doesn’t freeze the main thread after skipping intro. Optionally displaying a progress bar in that case. It would look “correct” then. This shouldn’t be too hard, but again, I’m slightly hesitant to change vcmi code too much because it makes merging the changes harder.
This input handling is done in SDL port. Feels quite good and I thiiink I could port it. (few weeks ago I added a bandaid method to send right-clicks through extra button in gui, but this would probably work better).
Well, tablets have bigger screens so I assume it could be used there.
Probably nothing I can do. Either SDL2.0 is more CPU-heavy than SDL1.x, or VCMI 0.99 needs more resources than 0.97 (or both).
@Kiiro
I meant desktop vcmi version, not OH3. No idea how resources are loaded in the original. 
@HarryPhoon
Yeah, basically “random” stuff from memory is displayed outside of the 4:3 game screen area. This is definitely a problem in SDL, because the app itself doesn’t even know if the bars are present. It might be fixable.
Edit next day ~ okay, so I added right-click support + changed intro so it looks better. I might build/upload apks later today.
Awesome, just wondering though, are you gonna try fixing movement animations at some point, or will you leave it as it is?
I’ll try to build apks tomorrow. I tried to do it, but currently the app seems to crash on older devices (and it looks like some android build system bug).
I’ve done some testing on the movement animations/logic. I think that the issue here is that
- movement logic uses some custom/manual rendering loop (with manual frame delays etc); I’m not sure if that’s a problem but certainly the rendering hero movement works differently that all other rendering
- there are lots of full map redraws during the movement and android can’t really keep up.
I made a small change/hack (basically added a frameskip during movement rendering so that it doesn’t do full redraws every frame) which helped (at least on my phone). I wouldn’t call it smooth, but definitely looks better than previously.
Yes. In fact I tried to remove map redraw altogether, but it lead to some crashes - couldn’t figure out why. Probably only original author knows why it’s implemented this way 
Could someone explain to me instalation step by step? What i must download? api16 or api21?
api21 is for android 5.0+. If you have 4.1-4.4.x, you can only use api16. “Installation” instructions should be displayed in the launcher, but rough description is in the post with the first version [forum.vcmi.eu/t/vcmi-for-android/784/164)
Maybe it would be possible to change these forced full redraws into partial draws (redrawing only hero tiles + neighbors(?)) because nothing except hero animation changes there. I might try looking into it (at some point).
–
Sooo I built new packages, but they’re quite weird this time and I’m not sure if they work correctly (honestly, compiling them feels very random). It works correctly on my 7.1 device, but I was unable to start the app on any emulator (tested on three different ones and each one is broken in a different way…). I don’t know, I might need to downgrade sdk/ide or something if it doesn’t work for others.
If you feel lucky, you can try it.
github.com/Fayth/vcmi-android/r … 3-debug.7z
github.com/Fayth/vcmi-android/r … 3-debug.7z
Changes:
- right-clicking support (two modes, switchable in launcher; personally, after some testing I find relative cursor very weird but I’ll leave it there),
- intro doesn’t appear frozen anymore (after interrupting intro, screen is cleaned + progressbar is displayed); this might also possibly fix HarryPhoon’s problem with artifacts on the sides, buuut I don’t know,
- hack that might make hero movement animations slightly smoother.
I just updated from the previous version of vcmi that I had and everything went smooth. On my device, Lenovo P2 with Android 6.0.1, the game works absolutely amazing. The right click is working very well and the hero movement is so smooth now. I’ve played for a few minutes with no crashes and bugs at all. Thanks for the excellent release, Fay!
Few things I noticed:
[ul]
]Relative cursor mode doesn’t seem to work very well, literally disappears after trying to press right click and you can move it off screen as much as you want, to the point where you completely lose it, thanks for adding it so fast though, if you’re gonna fix it and don’t mind working a bit more on it add sensitivity too, would be useful./:m]
]While intro seems much nicer now it seems to take longer time to load (might be just a psychological thing) and the sound of it disappeared (Actually now that I think about it, it may have not ever been there, if so dismiss this one), not something essential to the game but I think it worked previously./:m]
]Right clicking is pretty nice, takes a few clicks initially to get used to since one of your fingers always cover the information table but just moving fingers while you don’t have them released solves the problem./:m]
]Walking seems a little bit smoother now, but further optimisation would go a long way./:m][/ul]
Will edit if I find more stuff, thanks for the update! Oh also meant to ask, are there any performance differences between 16 and 21 API versions? And if not, what’s the point of making two different ones? Also why does this update take up three times as much space compared to the last one?
Okay, you’re right. That’s because I wanted to do it without adding more java<=>c communication so I didn’t have any reliable info about an actual cursor position and had to guess sometimes. I changed it to get the cursor directly from SDL an it works substantially better. Still can go offscreen though; not sure if I can limit it to actual game bounds.
The only things I changed there is clearing screen + displaying progressbar. Definitely nothing that could affect the loading speed.
I’m not sure about the sound because I always have it turned off. If it was there previously, it should still be there.
Okay, so the short answer is “it’s complicated”. I could probably get away with building only one package. I’m not sure about some details but generally:
- android device can have one of 5 architectures (arm, arm-v7a, arm64-v8a, x86, x86_64); 64-bit ones require api21 (android 5.0+) and I think x86 needs api18 (android 4.3+),
- all arm-based archs should work “normally” with applications built for normal arm, but x86-based devices will probably not,
- I assume when the arch doesn’t match, the performance is works becuse there needs to be some translations,
- running arm application on 64-bit device is probably the similar case as running 32bit applications on 64bit pc (slower, more limited, but usually not really noticable).
Currently the api16 package contains only arm arch and api21 contains all 5.
Because, for some reason, the apk file has no compression. I assume this is some kind of bug in android build system, because I can’t see any settings to change it and previously it was compressed normally. You can test this by unpacking the apk file (it’s just a zip) – both packages have ~313MB after unpacking.
Actually… never mind. That’s definitely not possible, because the screen follows the hero during movement.
VCMI4Droid working nice, but performance on Galaxy Note 2 sucks. Ofc. game is playable 
Fervi
Another release. Yay.
github.com/Fayth/vcmi-android/r … elease.apk (160MB)
github.com/Fayth/vcmi-android/r … ase.apk.7z (the same file as above but 40MB)
Some technical changes:
- the biggest change (but not very important from the player’s perspective) is that I gave up on gradle-experimental build and returned to stable gradle (+external cmake), because it felt really unstable and required some nasty hacks to work “correctly”; additionally I changed ndk to newest version (r15 b1) and replaced libc++ with gnustl, because it’s more stable and “default” in ndk
- at the moment, due to the previous point, the application doesn’t work correctly on armeabi (compiler crashes during SDL build) or api <21 (runtime crashes, probably due to some boost<>ndk conflicts); oh well, according to google, ~70% of phones are 5.0+ already; I’ll be monitoring ndk/gradle updates, hopefully it gets fixed at some point
- you need to uninstall previous version before installing this one (different app signing because of release mode and stuff)
Functional changes: - everything is compiled in release mode and should work much quicker (haven’t played enough to see big difference in-game, but app startup on my phone was ~12s previously and is ~3s in this version)
- app should no longer crash/hang when it goes into background or screen is turned off (hopefully),
- due to the fact that android can kill application in background at any time it wants to, vcmi now tries to make autosave when the app is about to be killed (_Android_Autosave file); not guaranteed to work, because it’s not very elegant solution for now,
- better relative cursor mechanics (as discussed in previous posts) + relative pointer speed multiplier setting in launcher,
- added adventure map swipe support (as an alternative to relative pointer); doesn’t feel very smooth but should be functional (launcher -> pointer mode -> “normal with map swipe”)
- added sound/music settings in launcher (because it’s irritating that these can’t be changed right away after starting the game ),
- launcher should correcly preserve all vcmi config settings (previously launcher would drop settings that it didn’t understand (everything except resolution and codepage))
- back button should now work like alt+f4 (closes app if in menu, displays exit confirmation if in-game)
Awesome!
Can you post it on Google Play? Did you try to contact xyz recently?
I don’t have any private google dev account so I can’t. I could provide an unsigned package if anyone wants to put it there (or provide signing info to vcmi team). I never really contacted xyz.
I registered developer account in Google Play for that purpose and paid fee some time ago.
I’ll try to contact XYZ and ask if he can transfer package ownership to me.
PS: I sent developer console invites to Fay, Warmonger and AVS.
Also sent Slack invite to xyz and hopefully he can help us. Shouldn’t be too hard:
support.google.com/googleplay/a … 0247?hl=en
And of course I sent to to xyz to in case he need some account credentials for transfer.
Ok. @xyz sent request to transfer app to my developer console.
There also signing keys for app that I’ll need grant to Fay.
Okay, I accepted the invitation.
Things to consider:
- I’m not very good with legal stuff, but I’m pretty sure I’ll need to add some info about 3rd party libraries and possibly a privacy policy as well (google has recently become way more strict about it)
- keep in mind that the app is currently build against vcmi/develop (b7a19fd); wouldn’t it be better to wait for stable version?
- I didn’t test the last version extensively (only my device + few emulators) so it’s hard to say if it works correctly everywhere
If we plan to update the existing app, it becomes more complicated.
- app will still need to use id “is.xyz.vcmi” – I’m pretty sure it’s not possible to change it for already-published apps
- at the moment I’m not certain what to do about the update process; I use slightly different way of handling OH3 data files so the new app won’t detect previously added files
I’ll try to look into it and and ping some Android developers I know and in IRC.
No good answer for this. One important point: is all code changes merged in develop?
If no this is what you need to start with. We’ll also benefit if you join our organization on github and move build system repository here.
And for building stable version I really not sure if it’s worth to wait since this would be quite long waiting probably. Like I wish to have tons of time to test and merge everything, but I only have so much… 
In same time we don’t have any working version for Android at all so I don’t think we’ll make it worse.
Is that a problem at all? I don’t think anyone care what package name is and if xyz going to get some weird credit for his previous work that not problem too.
That’s better to be solved one way or another.
Is there any way to detect when application was updated from older version? If there is then it’s would be enough to notify users who updated it that path files changed and they need to move assets. I doubt anyone seriously playing older version since it’s wasn’t really playable at time, many might have it installed.
Also once we get new version I want owner of this one to get it unlisted:
play.google.com/store/apps/deta … vcmi&hl=en
Or if he agrees he can transfer ownership too. Then we could update it once and suggest to install another app instead and then unlist it so it’s not confusing anyone.
Well, technically I am an android dev.
3rd party licenses definitely should be placed somewhere in the launcher.
Don’t know about policy, because vcmi doesn’t really do anything with user data – the only thing that could qualify is probably sdcard reading/writing.
Do you mean my changes in vcmi? Currently they’re here github.com/Fayth/vcmi/tree/android-support – I can start a pull request to vcmi/develop if that’s what you mean… probably not today though. I tried to wrap all android-specific logic in VCMI_ANDROID define so hopefully the won’t be any problems, but currently I don’t have any environment installed to check if the desktop version complies correctly.
Sure. I think it’s a good idea that vcmi team has the ownership over this.
If you feel that the current vcmi/develop version is stable enough to be published then there’s no problem on my side.
No technical problems. Only the fact that google suggests that your app’s id should reflect the domain that you own. But it’s not really a problem, because it’s not a hard rule, just a guideline.
No built-in mechanism. Usually apps just save previously launched version number and check it on startup.
In our case, we should probably try to detect datafiles in the old location and move them if possible. Should be doable.