Devilutionx: Native Android port

[ivan89el]

The current status of this effort can be found here #267

The main roadblocks are that it uses a modified version of SDL that means we don't get a proper game data path and also no music.

Separately from this we also need to land controller support in DevilutionX itself. There exist two separate attempts at bringing DevilutionX natively to Android:

1. #277 This uses MK as the build system, it's a version of SDL appears less buggy and so some things should work better, but MK is being faced out and would cause and unessesery maintenance burdon.
2. #240 this is based on an older version of #267, it adds a virtual game bad and a workaround for the music issues. Unfortunately, it also introduces more issues and is not maintainable.

[licaon-kter]

@AJenbo @kkszysiu Can the libsodium lib be build during compile too instead of using prebuild AARs? Or pulled from some FOSS maven repo?

Thinking of F-Droid inclusion... ;)

/LE: would implementation 'com.github.joshjdevl.libsodiumjni:libsodium-jni-aar:2.0.2' be ok to replace those AARs?

[kkszysiu]

@licaon-kter , I think we can manage to build libsodium as part of the build. For me it was just be easiest way that time to use prebuilt packages.

About implementation 'com.github.joshjdevl.libsodiumjni:libsodium-jni-aar:2.0.2' I'm using his built binaries :P

[kkszysiu]

BTW. I'm not sure but maybe instead of doing buttons and virtual joysticks/dpads in the SDL/game it would be better to draw them as overlay over game?
I can try to make it using Java, the good thing would be that it will be totally scalable per various Android devices and handled by Android UI framework.

I also have branch where I started implementation of selecting a launch of full game or shareware version, so even users without full game can just select shareware version, wait until it will download then play the game.

[licaon-kter]

OpenMW/OMW has nice controls, using https://github.com/MyGUI/mygui ( eg. https://omw.xyz.is/controls.html )

That's over SDL2 as well, and they can be scaled and made transparent as the user wants them. ;)

Also you can control either the cursor, use touch directly or a hybrid mode.

[Jimmy-cell]

@kkszysiu I thought about redoing the buttons too, but something was already there and I didn't want to mess with it too much.

Is there a problem with it being in C ? One thing I am not sure will be a problem or not is the signaling is based on RECT which is defined in the C sections.

I think if you do this in Java you will need to have something to translate between?

The full screen thing sounds nice though. Will it maintain the same aspect ration or look torn?

[AJenbo]

Full screen ui could also be done by drawing to the window surface instead of the game surface.

If the Java controls just send game controller commands to the game then that might actually be a nice way to go about it.

This would allow us to focuse on bringing in the game controller code in a clean manner, which should also help with landing the Nintendo Switch code.

What's currently in #240 is just not ideal 😕

[kkszysiu]

If the Java controls just send game controller commands to the game then that might actually be a nice way to go about it.

Yes @AJenbo , exactly.
Dolphin emulator does just that for example and it works fine.
And this is what I want to try.

It will also allow us to keep the game source clean, while most of the weird Android-related logic would be implemented on launcher/overlay side.

[AJenbo]

The main blocker at the moment is that the build chain relies on a modified version of SDL2, especially SDL2_mixer is problematic as this is probably why music isn't working in the Android builds.

[licaon-kter]

Where is the HEAD APK build exactly?

And more importantly... which PR is the latest?

[AJenbo]

@licaon-kter this is the currently most relevant PR for the Android porting effort: https://github.com/diasurgical/devilutionX/pull/267

The version your using is not supported in any way shape or form it simply has too many bugs, hacks and workarounds. I know it has a better control scheme than the other options, but it's simply not in a state where we can continue work on it. There probably won't be any new builds until #267 is merged.

Edit: I'm going to clean up this topic a bit.

[AJenbo]

240 has not been replaced by #522

[licaon-kter]

@AJenbo what's up with https://play.google.com/store/apps/details?id=org.diasurgical.devilutionx ?

[AJenbo]

This is the first I hear/see of it, probably try writing to the email to find out who they are and what there feeling for colaboration is.

[licaon-kter]

Not so much about the collaboration but about the app id. It's common courtesy to modify it, if not official, but looks like they didn't. :(

Eg. When/If adding to F-Droid we'd have to change it.