Android ABI changes

[a1batross]

1. hardfp is now unsupported, using softfp is preferred for ARMv7.

Yes, it's bad to break the ABI, moreover it something that we cannot detect. But, let's look into truth's face, even if I know how to use hardfp in 2019 with modern compiler like Clang 9, most people don't. \ They don't know that before compiling their cool Half-Life mod they need to use NDK from 2015. \ They don't know that C++11 is mostly undone and newer standards are unsupported completely for outdated NDK. \ Instead of making development a hell for them, I decided to drop hardfp, so they can just fire Android Studio or what's popular now and just mod.

2. Intent to run engine is now renamed from in.celest.xash3d.START to su.xash.engine.START to not allow old mods that doesn't compiled for AArch64 run on AArch64 engine. That's something that we can't detect before firing up an engine.

It's better to have more time for engine and mod developers to upgrade their code. At least, users still can use the old engine, that's why 0.20 will be released with another package name to not conflict with old engine.

[mittorn]

I do not see any reason for breaking ABI for armv7. We just need to add check for libraries on engine side to prevent running mods without compatible libraries. And we need add new intents for new mods to launch engine launcher instead of engine itself, it will prevent new mods from running on old engine

[nekonomicon]

I think It would be better to save compatibility with old NDK and to drop old engine support for new mods. C++11+ sucks in portability anyway.

[a1batross]

C++11+ sucks in portability anyway.

It's actually better in portability. The only problem is the compiler support but it's on a mod developer. If they think C++11 is worth it, then who am I to stop them?

I think It would be better to save compatibility with old NDK

It's supported. But I want to give developers a chance to NOT use old NDK.

to drop old engine support for new mods

Changing intent also solves this.

[a1batross]

@mittorn

Instead of making development a hell for them, I decided to drop hardfp, so they can just fire Android Studio or what's popular now and just mod.

What part of it you didn't understood?

[mirh]

Why you would have to drop armhf altogether, as if there weren't other arm devices in the world. It's not like you can't ifdef __ARM_PCS/__ARM_PCS_VFP? (or __SOFTFP idk)

p.s. google claims that if you inline calls, there is no functional difference. Does it make sense that performance isn't even affected in this case?

[nekonomicon]

@mirh https://github.com/android/ndk/issues/1096

Does it make sense that performance isn't even affected in this case?

clang make more aggressive vectorization than gcc.

[a1batross]

hard-float is optional. We still can compile with soft-float and builds will continue work on any armv7 device.

I did some benchmarks and google codemonkeys are actually wrong about hardfloat and enabling it still gives performance boost.

But there is no way we can overcome the removed hardfloat support in NDK itself. Retards from Google are implemented hardfloat support by: adding libm_hard.a, adding inline versions of libm functions and set aapcs attribute to api calls that have float/double.

They removed it and even if you pass -mhard-float to compiler, it just would not work.

However, this is not the end.

I did a research on using 3rdparty clang builds and now we can use Clang 8/9/trunk(didn't tested everything else) with NDK r10e headers and get working hard float with modern compiler. So yay, we can use it for the engine but require softfloat mods dlls(client, menu, server) without potentially broken ABI and still have compatibility with newer NDKs, if anyone would like to use them!

But this is a subject of future development and of course, we are welcome for contributions.