Ios gl3 and some improvements

[joliver82]

List of changes:

• Fixed proguard rules.
• Added openGLES3 initialization.
• Implemented native code of missing methods of gles2.
• Implemented native code of gles3 methods.
• Forced compilation using java 8.
• Added Dummy.storyboard to be used as "Launch Screen File" in xcode to avoid bad aspect ratio and being able to use the whole screen and the proper resolution.
• Updated iPhone target to 9.0.

I'm just missing one detail, if I do need to replace also ./src/com/jme3/gde/ios/ios-data.zip or is it regenerated on SDK build?

Topic at hub: https://hub.jmonkeyengine.org/t/ios-improvements-including-gles3-0/44332

** This PR needs the related engine PR: jMonkeyEngine/jmonkeyengine#1473

[MeFisto94]

Is this TODO solved?
jlong should be capable of 64bit, an intptr may only be 32bit on, well, 32bit systems.
On the other hand iirc, most recent iOS enforces 64bit only? Could have also been on macOS only, not sure about that.

Either way it depends on how the buffer is allocated, in theory it should be impossible, unless by manual interception, to get a > 32bit pointer from some buffer allocator on a 32bit system.

[joliver82]

This was a comment for myself not to forget to test it properly because lwjgl was casting indices to intprt_t instead of const void * like it's defined in https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glDrawElementsInstanced.xhtml and https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawElementsInstanced.xhtml

Anyway, I tested instancing and it's working as expected, so I'm removing the useless comment ;)

[MeFisto94]

Thanks for you contribution and sorry for the delay.
I cannot tell you much about ios-data, my guess is that upon build time it is zipped and then has been commited once, because I think I saw this one in my git diff occassionally, we'll see.

I'd like to make a "statement" about iOS support here, even if it's unrelated to the PR itself:
Currently, iOS is in a bad state and the fact that all this JNI code is on the sdk repo and not the engine repo, even more so.
Very very soon we need to save https://bintray.com/mefisto94/jme-sdk-storage/avian-openjdk-mac because bintray is shutting down.
Building this was very very painful, see https://github.com/jMonkeyEngine/sdk/blob/master/jme3-ios/build_avian.sh, https://github.com/jMonkeyEngine/sdk/blob/master/jme3-ios/GetClassLoader.patch and the related commits.

Bottom line: This is still using a java 7 jvm, so building with java 8 may fail. Also avian got deprecated in the meantime.
What it did was compiling a native jvm into an ios binary, that was then linked against the class code by the SDK.
For this, we've been using an unoffical jvm 7 and patched it.

So ultimatively we probably want/need a new way of deploying for iOS, but there wasn't much demand/activity on the iOS side though.
Also this code should all belong into the engine domain, it's just here because the SDK used to prepare/do the deployment, but again this is just for the future/not related to the PR.

On topic:

• The change to appResize was because there were some calls to resize when the renderer was not (yet?) present?
• We may have a problem with java 7/11 here. While it's true that the SDK updates the shipped JDK, I think one cannot compile for java 7 anymore with the java 11 JDK?

Besides that, the PR looks good (note the TODO though), however I couldn't really test if it works/compiles, which in the current state of not having any CI/CD for it anyway, is probably as good as it gets.

[joliver82]

Thanks @MeFisto94 for taking the time to review the PR

About the ios-data.zip, if it's not zipped automatically when the SDK is built, I don't mind creating a new PR to update it later if required

Yes, I changed the appResize because sometimes the renderer was null still, causing a weird rendering issue in ios13.0 but not in any other release I've tested and I wanted to be coherent among ios releases. You have an screenshot at this hub post: https://hub.jmonkeyengine.org/t/ios-multiple-issues-and-solutions-workarounds-trying-to-run-jme3-app/44304/25

All my tests were done using newest SDK (3.3.2-prev1) using my OS jdk8 and also the included jdk11 adding the --release option (Compile for a specific VM version. Supported targets: 6, 7, 8, 9, 10, 11) both worked. So still possible to compile for legacy java versions

About testing, it would be great if someone had the time to manually test the changes

Getting into the offtopics...

About avian, for the short term, we will need to move it from bintray to other site or even to the SDK repo itself. In the long term avian should be replaced by any other newer and supported jvm like graalvm or even minijvm. This will be a hard topic to address

The code could be moved to the engine itself but SDK will need to be modified to extract/copy the required template code files and most of this code being ios specific code won't get through CI/CD because it needs an OSX to compile. Maybe a task to be talked about in the future...

[Ali-RS]

Going to merge this in 24H if there is no objection.

[MeFisto94]

I don't know if we should wait for someone to confirm it works, which however may never happen.
Otherwise we'll just see if someone complains, much like it already is

[Ali-RS]

Ok, just noticed @joliver82 has already asked GTWhite for a feedback in forum. So let's wait a little more in case he wants to give this a try.

[joliver82]

I agree if anyone tests this would be great (apart from me) but it seems that there isn't many people working with jme3 on iOS. I hope GTWhite has some spare time for this.

[Ali-RS]

I am merging this as there was no response from GTWhite.

[joliver82]

Thanks for merging! GTWhite just answered on the forum. If any related issue is found we'll track it and create new PRs for them

[Ali-RS]

I see. Thanks so much for your contribution ❤️

Edit: Off topic

In the long term avian should be replaced by any other newer and supported jvm like graalvm or even minijvm.

Just in case, another alternative I just found recently is the RoboVM fork maintained by LibGDX guys here: https://github.com/MobiVM/robovm