[SOLVED] Basic JME3 Android Gradle Script

[adi.barda]

Thanks Pavl! I did faced that and set the emulator as you said and now it’s working. I wonder what is the percent of Android devices running GLES 3.1 is it depends on the Android version or the hardware? can the user simply install it regardless of OS ver?

[Pavl_G]

@adi.barda

is it depends on the Android version or the hardware?

Well, theoretically starting from Android 4.3 ICS "Ice Cream Sandwich", OGLES3.0 is supported (ie can be used), but also the device gpu must support that, GLES3.1 is supported starting from Android 5.0 API21 LP, but also gpu must support that…

@adi.barda

can the user simply install it regardless of OS ver?

yeh, only if the user upgrades the OS version, as an example a device of Android KK 4.4.2 like nivida shield tablet has got an update to Android 5.1.1 LP, so the OS would be shipped with GLES3.1 if the gpu supports that…

So, Android API version (API on the OS that runs the apps) restricts the features of the device, regardless of it’s HW capabilities…

Not all high android version device’s have good GPUs…

@adi.barda

I wonder what is the percent of Android devices running GLES 3.1

Yeh, i cannot estimate this ofc, but you can do this practically, if you release an app on google play, Play Console will let you know the device spec of people who reviewed & rated your app, which will give you also a good point around the GLES they use which may have been the cause of the crash on their device, if we are talking about game apps…, but generally almost all companies that release android > 5.1.1 would make it support at least OGLES-3.0

if you want to restrict the android devices that will download your game from google play, then specify a min GLES version via manifest, other unsupported devices would display “Your device isn’t Compatible”, it may also displays “package not installed” for devices not supporting if the user uses package installer :

<!-- Tell the system this app requires OpenGL ES 3.1. -->
<uses-feature android:glEsVersion="0x00030001" android:required="true" />

if you need more info, android developers have a good docs there :

OpenGL ES  |  Android Developers

[Samwise]

Im not developing for Android but it might be worth a try adding glsl100 to the list of versions supported in the PBR j3md and see what error the driver throws upon compilation, maybe it’s something that can be “fixed” and since the highest supported version is selected at runtime and desktop GL always adds caps glsl100 and glsl110 it would not affect desktop

[Pavl_G]

I don’t have a good background for jme3 rendering pipeline, if we need to test this, where in GlRenderer class should I add this check ?

EDIT : Android doesn’t use lwjgl classes like jme, they are directly bounded to openGL through Android Choreographer

[Pavl_G]

Oh, reading it again I seemed to get what you want to do, you want to provide support glsl100 for the default technique used by pbr.j3md ? Don’t you ? & test that

[Samwise]

Nowhere, the renderer does check what is supported by the hardware and adds appropriate caps to the set of caps that can later be used to see what is supported by the hardware (it’s based on the reported GL and glsl versions as well as available extensions)
The material system is setup to use the highest supported glsl version that appears in your caps as well as on the list of versions claimed to be supported in the j3md
So you would just need to add GLSL100 to the J3md so the system will find your hardware supports GLSL100 and use that version
(Don’t have the code available atm, might be it tries to add a #version directive for glsl100 which might be an error because for the lowest version there is no point in requiring stating a version, don’t remember exactly)
Edit: I’m not trying to say “add a line and it all works”, I’m more like trying to say “we might get an error which we might be able to fix, to get another error which we can fix too, hopefully”

[Pavl_G]

Yeah, I will see what I can do :

& also a topic from android developers :

OpenGL ES  |  Android Developers

States that :

• Coding Convenience - The OpenGL ES 1.0/1.1 API provides a fixed function pipeline and convenience functions which are not available in the OpenGL ES 2.0 or 3.0 APIs. Developers who are new to OpenGL ES may find coding for version 1.0/1.1 faster and more convenient.
• Graphics Control - The OpenGL ES 2.0 and 3.0 APIs provide a higher degree of control by providing a fully programmable pipeline through the use of shaders. With more direct control of the graphics processing pipeline, developers can create effects that would be very difficult to generate using the 1.0/1.1 API.
• Texture Support - The OpenGL ES 3.0 API has the best support for texture compression because it guarantees availability of the ETC2 compression format, which supports transparency. The 1.x and 2.0 API implementations usually include support for ETC1, however this texture format does not support transparency and so you must typically provide resources in other compression formats supported by the devices you are targeting. For more information, see Texture compression support.

EDIT : If we haven’t succeeded in doing what Sam proposed to do, we may provide a Provider class that the jme user can use to do realtime checks for GLES version & enable/disable techniques of shaders accordingly…so user would provide a min GLES version via manifest & will target a higher GLES version if only the GPU supports that, if the GPU doesn’t support the proposed technique, then keeps it disabled…

[Samwise]

The engine doesnt support GLES 1.0 / 1.1 because it’s the ancient fixed function stuff. “Fully programmable pipeline” just started with GLES 2.0 which is why at that point an actual programming language was needed to program that programmable pipeline, thus glsl 100 is the version that comes with GLES 2.0, you can basically just ignore anything GLES 1.0 / 1.1 related
It’s not entirely precise because glsl does not equal glsl, there is a difference between GL and GLES glsl and the versioning is a pain also
I’m just trying to say I’m optimistic with just 2 or 3 minor changes PBR can run on GLES 2.0

[Pavl_G]

@Samwise

It’s not entirely precise because glsl does not equal glsl, there is a difference between GL and GLES glsl and the versioning is a pain also
I’m just trying to say I’m optimistic with just 2 or 3 minor changes PBR can run on GLES 2.0

Yeh, i understand there’s GLES~GL feature equivalent versioning, i would try the changes within PBR shader & report here.

[adi.barda]

@Pavl_G / @sgold Is there a specific Minie implementation config for Android?
When I use this:

implementation 'com.github.stephengold:Minie:4.1.0+for33'

Everything compiles fine but the the application wont start on a physical device (Android 8.1). I’m getting SHELL_UNRESPONSIVE error.
Only when I remove Minie the application starts on that device.
When running on the emulation (either Android 10 / Android 8.0) it works fine.
So I wonder what is there in Minie that prevents the application to start on my physical device…

[Pavl_G]

@adi.barda

So I wonder what is there in Minie that prevents the applic

Its built using Android NDK, Native Development kit using JNI “jni.h”

Can you post the full error, probably this Minie version doesn’t use android NDK, or you need to do something like ‘extractNatives=true’ in Manifest.

EDIT : I have navigated Minie versions on git, found that you are using latest version for jme3.3 so we might have a new bug, I will test this version…

[Pavl_G]

I have tested Minie4.1.0+for33 on my physical device Android 10(Custom RR rom), no problems so far, @adi.barda make sure you have free space on your device, android:extractNativeLibs="true" in your application tag inside AndroidManifest.xml, so it forces Native libs to be extracted at runtime for higher API levels…

[adi.barda]

@Pavl_G

android:extractNativeLibs=“true”

Thanks!!! extractNativeLibs made it work

[sgold]

I’ll add a note to the Minie documentation about “extractNativeLibs”.

[Pavl_G]

Yeah, great, if you are searching for errors that may result from not extracting native libs, check this back & Adi’s report :

Minie for Androids

I donot know if this topic of testing Minie 3.0.0+debug is still valid or not , but i was testing it on Emulators & it works fine , but on physical device , it works the first 2 days , but its now disabling the apk from being installed on my physical device , i have tried Minie 2.0.1+debug also on a separate non jme blank android project & it didnot work either , when removing Minie implementation , the apk is installed successfully ! my gradle version is gradle:4.0.2 [image]

[Pavl_G]

@Pavl_G

at runtime

I have to correct something here, i am sorry about that mistake, it makes sure the native Libs get compressed when assembleDebug is executed for the apk, just for storage performance purposes, the extraction at the installation process not the runtime since android uses .DEX (Dalvik Exec) files converted from java files using dex, not jvm…

-So, if the application is installed properly, then breaks due to UnSatisfiedLinkError , that means the native lib isn’t actually found or dropped during the packaging procedures, so the linker didn’t find it on the runtime, then doing extractNativeLibs="true" won’t fix this.

EDIT :

[quote=“Pavl_G, post:56, topic:44583”]
So, if the application is installed properly, then breaks due to UnSatisfiedLinkError , that means the native lib isn’t actually found or dropped during the packaging procedures, so the linker didn’t find it on the runtime, then doing extractNativeLibs="true" won’t fix this
[/quote]

Or NDK is not actually there for you

-,But if the app didn’t actually install because native libs are not decompressed at the installation time (the error reported by Adi & me on another thread), so the linker didn’t find them, then doing extractNativeLibs="true" may fix this…

-extractNativeLibs="true" will work only if minSdkVersion >= 23 specified in android gradle.

Other <application> properties, Application is Base class for maintaining global application state :

 |  Android Developers

[Pavl_G]

So, you must be specifying minSdkVersion = 23 in build.gradle or higher per this android java module …aren’t you ?

[adi.barda]

I have minSdkVersion=26

[Pavl_G]

@Pavl_G

EDIT : i was to upload new android examples for jme3.4.0, but there was some disturbances with git & my network was limited, so those are the very simple examples if you want :

github.com

Scrappers-glitch/jme3-Simple-Examples

master

Jme Android Simple Gradle Examples. Contribute to Scrappers-glitch/jme3-Simple-Examples development by creating an account on GitHub.

@adi.barda just in case you want to build your own UI input, helloAndroidUi module would help you

This is my library, you may find some Ui-Components helpful like DrivingWheelView, GullWing, UTurnView, GameStickView, Speedometer, ControlButtonsView in which you can embed them inside a XML layout file, & use that XML layout file in activity with JmeSurfaceView or AndroidFragmentHarness inside FrameLayout inside RelativeLayout.

@Pavl_G

Check this :-

github.com

Scrappers-glitch/Superior-Extended-Engine

A GamePad

[tharg2]

Hi,
I’ve been trying to get the Superior-Extended-Engine working with the latest ‘everything’. Basically I run the project in intellij and update and add everything it tells me to (e.g. JME version is now 3.5.2). I have got the app deployed in the emulator but it fails with a fatal error. Has anyone managed to get it working lately?

I am trying to deploy a game which uses Minie and thought this would be a good starting point if I could get it working. Your apps seemed to be the latest examples of JME on Android using Minie, but maybe I am missing something…

I need to:

1. Run my app with Minie (it is working OK on windows)
2. Get input from the screen (gestures would be a bonus)
3. Display text and icons on the screen.

Am I following the correct approach?
Or it there a very simple Android alternative to inputManager and its listeners, and guiNode somewhere?

Thanks for any help,
Tom.

2022-10-30 10:23:47.373 10409-10803/com.scrappers.SEEDEMO D/AudioTrack: stop(25): called with 882 frames delivered
2022-10-30 10:23:47.529 10409-10716/com.scrappers.SEEDEMO E/emuglGLESv2_enc: device/generic/goldfish-opengl/system/GLESv2_enc/GL2Encoder.cpp:s_glTexImage2D:2614 GL error 0x502 condition [!GLESv2Validation::pixelSizedFormat(ctx, internalformat, format, type)]
2022-10-30 10:23:47.536 10409-10716/com.scrappers.SEEDEMO D/eglCodecCommon: checkFramebufferAttachmentCompleteness: tex not color renderable. format: 0x0 type 0xc07f3df0 maj min 2 0 floatext 0 hfloatext 1
2022-10-30 10:23:47.537 10409-10716/com.scrappers.SEEDEMO D/eglCodecCommon: checkFramebufferCompleteness: color attachment 0 not complete: 0x8cd6
2022-10-30 10:23:47.568 10409-10716/com.scrappers.SEEDEMO E/AndroidRuntime: FATAL EXCEPTION: GLThread 51
Process: com.scrappers.SEEDEMO, PID: 10409
java.lang.IllegalStateException: Framebuffer has erroneous attachment.
at com.jme3.renderer.opengl.GLRenderer.checkFrameBufferError(GLRenderer.java:1790)
at com.jme3.renderer.opengl.GLRenderer.updateFrameBuffer(GLRenderer.java:1963)
at com.jme3.renderer.opengl.GLRenderer.setFrameBuffer(GLRenderer.java:2113)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1150)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1248)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:278)
at com.scrappers.superiorExtendedEngine.jmeSurfaceView.JmeSurfaceView.update(JmeSurfaceView.java:188)
at com.jme3.system.android.OGLESContext.onDrawFrame(OGLESContext.java:352)
at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1573)
at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1272)
2022-10-30 10:23:47.569 10409-10716/com.scrappers.SEEDEMO W/JmeSurfaceView: Framebuffer has erroneous attachment.