AuthorTopic: AGS engine Android port (Read 175499 times)

You read right Snarky, if I understood, touch needs to be a click but still keep the state of the left mouse button pressed while the finger is pressed on the screen. At least this is how I understand the mouse works in AGS, it emits the mouse click event on click and not on release.

To trigger long click, you have to hold your finger and wait until the device vibrates, and then the longclick is processed. The idea would be that once the screen is touched, the mouse button is already considered down.:/ Also as is, to remove the finger, you have to click with the finger again. CW don't worry. (I really don't like how written text makes me sound like I am ungrateful...)

Having grown up in foster care I realize one thing. Good things are rare and should be treated with care..This thing that all of you do is a good thing. I'll be 50 in a few days and wanted to reflect the fact that I respect what all you guys do!!Thank you for allowing me to enjoy sincerely.

Hope this works out so everyone can enjoy.Either way, what each of you do is truly something special.All the personal time you each put into these games/engines, is something I myself am truly thankful for.Your selflessness truly lifts my spirits!So to everyone involved, you are appricated!!

EDIT2:I was able to find out that "configure: error: C compiler cannot create executables" was caused by gcc error "Unrecognized command '-mthumb'". That's all I can add at this point.

Alright, a bit of a progress here.

1) First of all, I managed to create standalone toolchains myself, although I had to modify the script that does that, because the existing one did not work for me. I honestly don't know why, maybe it refers to an old version of NDK.

What I had to do is open Android/buildlibs/makestandalones.sh and in the line -

That said, I am not sure whether this was even needed, since some toolchains were already included in NDK distributive.

2) Now, regarding actual library building.Apparently I misunderstood how the building script works. I thought it somehow refers to the toolchains explicitly, but no, I had to add all the necessary toolchain into PATH. I guess that makes sense (also documentation page mentioned this, albeit non-explicitly, which I missed).

Straight to the point, each toolchain you are using must be referenced in $PATH.For example, I created a toolchain in "~/ndk-standalone/android-9/arm". Then I had to add following path to $PATH: "~/ndk-standalone/android-9/arm/bin".Then, the building process will actually be using a gcc compiler from Android toolchain, rather than the one from your system.

3) After that I was even able to finally launch library compilation. Then it failed while compiling "lua" library (why does it need lua anyway... probably for lua plugin?).

Anyway, at that point I've stumbled into a problem with my virtual machine running out of disk space... which was unexpected. I will continue after fixing that...

UPDATE:

4) Had to install autoconf, automake, cmake, libtool utilities (required to build some of the libs).

5) So far managed to compile freetype, allegro and dumb libraries.Other libraries: lua and ogg failed with similar errors:

Quote

undefined reference to 'stderr'undefined reference to 'stdout'undefined reference to 'signal'undefined reference to 'rand'

Hey, I just built love2d for android today, Lua wouldn't build for armeabi because it's support has been dropped, but will build for armeabi-v7a. (in love's case)

I am looking into the project, and for some reason the ndkenv file inside each platform in buildlibs (x86, mips, ...) has the wrong root path. I think first you need to install the toolchains using makestandalones.sh and them use the paths to update ndkenv. Also the project expects Android-9, which is old as hell, I would try with at least 14. Unfortunately, I already spent a lot of time on love2d today, so I will probably only be seriously looking into this tomorrow. (I felt a lot of pressure from the forums, from 'the future of' discussions, so I had to be away for some time)

Right now I got until (even if I skip armeabi and go directly to armeabi-v7a, so it's not the same case as Lua for love2d apparently)

Edit4: Ok, now for some reason allegro.sh fails on line 17 saying it can't find cmake, but ndk has cmake, so I don't know yet what's wrong...

Edit5: I didn't have cmake, and NDK requires a newer cmake then the offered by Ubuntu repo. Installed newest cmake using pip install cmake . In allegro.sh, I also changed line 31 to use: -DCMAKE_TOOLCHAIN_FILE=~/Android/Sdk/ndk-bundle/build/cmake/android.toolchain.cmake

which points to my correct cmake toolchain for Android. Unfortunately, I now fail with the following

Add spoiler tag for Hidden:

Code: Bash

-- Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR)

CMake Error at CMakeLists.txt:962(get_target_property):

get_target_property() called with non-existent target "allegrogl".

CMake Error at CMakeLists.txt:962(get_target_property):

get_target_property() called with non-existent target "loadpng".

CMake Error at CMakeLists.txt:962(get_target_property):

get_target_property() called with non-existent target "logg".

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake files:

See also "/home/erico/git/ags/Android/buildlibs/armeabi-v7a/allegro-4.4.2/CMakeFiles/CMakeOutput.log".

See also "/home/erico/git/ags/Android/buildlibs/armeabi-v7a/allegro-4.4.2/CMakeFiles/CMakeError.log".

Edit6: Apparently, cmake looks the missign targets here : ~/Android/Sdk/ndk-bundle/platforms/android-14/arch-arm/usr/lib/ . I am not completely sure if this is true or either if the missing things are libraries. Question : which libpng version should be used with Allegro 4.4.2 ? Trying what is written here: https://stackoverflow.com/questions/14263016/adding-libpng-in-android-ndk-project . Tried. It doesn't change, it still can't find libpng. I removed the compiled libs from the Sdk directories because it doesn't seem to be the correct place. Tried placing in NDK_ADDITIONAL_LIBRARY_PATH but it didn't work too.

edit9: Nick confirmed the steps are indeed run the Android/buildlibs first, being 1) http://makestandalones.sh and then 2) http://buildall.sh . so I really don't know why it doesn't build for me. My machine is Ubuntu 16.04 64-bits so if someone ever reads this, this is all the info :/

Note: I think you can git apply my diff as a patch, but I haven't never actually tried. Since my experience with taking patches from html pages is poor, I also linked above a link to a copy of the diff in my github gist.

After applying the modifications in all files, you need to build things

Code: Bash

exportPATH=$PATH:~/Android/Sdk/ndk-bundle/

cd git/ags/Android/buildlibs/

./makestandalones.sh

./buildall.sh

cd ../library/

ndk-build

notice that doing that PATH export is very important. My environment is Ubuntu 16.04 and I used the Android Sdk and ndk installed through Android Studio 3.0.1

Edit1: The failing is atually related to SwapInterval and the fact that you can't (apparently) control V-Sync in Android. Below is a modification of ali3dogl.cpp that actually fails in glCreateShader. I just removed things related to V-Sync with if !defined (ANDROID_VERSION) so I am not sure this won't break anything.

Edit2: Right below the first if defined (ANDROID_VERSION) I added #include <GLES2/gl2.h>

This header should be included in ogl_headers.h, where <GLES/gl.h> is.

Firstly we need to find out whether gl2.h is enough, secondly if there are still functions that have different names (if there are) should be remapped using defines, similar to how other GL functions are remapped, e.g.

Code: C++

#define glGenFramebuffersEXT glGenFramebuffersOES

#define glDeleteFramebuffersEXT glDeleteFramebuffersOES

IDK if that is needed, so just mentioning FYI.

But not sure if that would be enough.I was going to try that out after I am able to build it.

What bothers me also is whether these shader functions are supported on all Android devices or not. And what will happen if we demand it inclusion into program. For instance, Windows version works with function pointers which it first tries to get from OpenGL's DLL. If it fails, it can simply check for that and skip some code during drawing.

There's an alternative solution, when the functions that are not found right now will be declared as ints = 0, and similarily skipped during drawing. This will disable tinting on mobile devices (at least with OpenGL means), but at least won't break anything that already exists.

PS. Ideally the OpenGL renderer should be rewritten, having some generic OpenGL API exposed, and the inner workings hidden in implementations, one for each platform. But that will take some time to do.