WIP Android Port

[Stommm]

Work in progress Android port. Still needs touch controls and mouse turning (if that's even possible on android) and file saving and SoundSystemSL. You control the camera and movement with your controller for now. You can navigate the gui using touch. Options.cpp,LocalPlayer.cpp,Minecraft.cpp is configured to use controller on android. Blocked out some code in ControllerTurnInput.cpp,Controller.cpp that didn't make sense for android. Fix clang compiler error in Mth.cpp. Using zlib that ships with android. Create visual studio project and implement AppPlatform_android

[TheBrokenRail]

Why not use SDL's Android support instead of writing a whole new backend?

[iProgramMC]

Honestly I'd do the same thing. To be close to the original source layout I guess

[BrentDaMage]

Why not use SDL's Android support instead of writing a whole new backend?

Are we sure SDL even supports older versions of Android? It seems like typically native backend implementations tend to be more compatible with older versions of platforms.

[iProgramMC]

That would be reason 1. Reason 2 is what I stated above.

[TheBrokenRail]

SDL's minimum Android version is API 19 (v4.4). This means it suppirts 99.64% of devices.

[BrentDaMage]

SDL's minimum Android version is API 19 (v4.4). This means it suppirts 99.64% of devices.

In that case I think SDL2 would be best suited for use on desktop Android machines (depending on how we implement the mobile-friendly UI). Usually we can get the most out of a platform by using its native APIs, so if someone's already attempting this, I don't see a reason not to go along with it. Additionally, it seems as though SDL 2.0.8 or below actually supports API 12 which is from around early 2011. Unfortunately iOS isn't at all similar. The oldest version SDL2 seems to support is iOS 8, and maaaybe iOS 6.1 at best.

[iProgramMC]

I support creating a separate project because it's more faithful to the original code base, first and foremost. The rest are just details.

[SanyaSho]

I remember when someone compiled source engine for android with NDK r10e and it didn't run on android 14. But when he updated NDK to r20* it ran without any problem.

[TheBrokenRail]

My opinion is still that faithfully recreating every AppPlatform for every target just isn't worth it. Especially, since each AppPlatform also tends to require its own build-system.

I'm a little biased (since I wrote the SDL backend), but I think it would be way nicer to just use SDL when possible instead of having dedicated Windows/Android/iOS(?)/Linux backends. Less code is usually better in my opinion.

[BrentDaMage]

We get more control over the platform if we write platform-specific AppPlatform classes. Doing one large AppPlatform_sdl.cpp file with a shitload of #ifdefs is not a viable solution to wanting more control over the platform either.

[TheBrokenRail]

How much platform-specific control does MCPE even need?

Anyways, just like SDL does currently, it doesn't have to be just one SDL AppPlatform, there can be one base-class with multiple sub-classes. Also, unlike WASM, which is just kind of weird, Android/Linux/Windows are all fairly similar with regards to how MCPE interacts with them. If I'm not wrong, you've actually already ported the SDL backend to Windows and you can barely tell.

[BrentDaMage]

If I'm not wrong, you've actually already ported the SDL backend to Windows and you can barely tell.

Correct. I've already gotten the SDL2 app running under Windows. Only problem is, managing libraries (such as SDL2) under Windows is horrible. So we prefer to keep the option around to use built-in libraries.

[iProgramMC]

Good news, I've added in the touch screen support. Please rebase and integrate my changes.