iOS enabled: Error extracting avian-openjdk

Thanks for the good news.

Does nifty gui now work correctly? For jME 3.0 I had to do some workarounds.
Yeah, sorry. I’m a lazy bone and didn’t try it out myself. Shame on me… but I’m very curious… :grin:

Actually it doesn’t render anything in the guiBucket correctly as you can see in my Post under the August Showcase. Unfortunately something seems wrong with the Aspect Ratio.

This seems like an easy fix though. The challenge is finding what goes wrong.
Nifty Gui on the other hand might not even be updated on our side since 3.1 at all so expect some issues.

Sounds familiar. nifty gui has exactly this problem.

Maybe you can share your workaround with us because that seems to apply to anything gui related under iOS

Sorry, I was not precise enough. nifty gui had the same problem for jME 3.0. I published my workarounds here.

Don’t forget to test the new renderer with all devices and also test with display zoom. (No, this is no joke.)

I understood that yeah, but I wanted to say that everything relying on the guiNode is prone to this error.
A few comments:

  • We now use x86_64 for the simulator and there is no need to check the simulator or the i386 Version as real phones seem to be arm and arm64 only.

  • “Images have to be flipped.” This PullRequest missed out the Native Side and was what caused a crash lateron, I took the android code for that and it should definately work now.

  • “Images need to be 32 bpp.” I didn’t look too much into this but at least I made some code aware of bpps’ ness (At least when bpp is dividable by 8), so maybe you could give it a try (What it doesn’t do is transcode to 32bpp, though).

  • “com.jme3.font.BitmapText shows nothing” This is strange since the Stats View is (partially) visible.

I will also see how to integrate that app.reshape thing.

Thanks for sorting out Avian.

I tried it and it crashed on my 32 bit IPad 3 in the routine loadextensions in GLRENDERER.java

It doesn’t have GL30 so it’s crashing on the depreciated command extensionSet.addAll(…

If I comment that out it runs the BASIC GAME standard template. I don’t what effect that will have but would love to know.

Anyway, Now I’ll have a go at the full project.

Just letting you know.

private HashSet<String> loadExtensions() {       
    HashSet<String> extensionSet = new HashSet<String>(64);  
    if (caps.contains(Caps.OpenGL30)) {         
        // If OpenGL3+ is available, use the non-deprecated way
        // of getting supported extensions.
        gl3.glGetInteger(GL3.GL_NUM_EXTENSIONS, intBuf16);
        int extensionCount = intBuf16.get(0);
        for (int i = 0; i < extensionCount; i++) {
            String extension = gl3.glGetString(GL.GL_EXTENSIONS, i);
            extensionSet.add(extension);
        }
    } else {          
     //   extensionSet.addAll(Arrays.asList(gl.glGetString(GL.GL_EXTENSIONS).split(" ")));
    }
    return extensionSet;
}

Might be my fault of not updatIng the right thing but the actual fault was glgetstring returning null since the harness had a fault.

Did you try a New project?
Also i guess you mean arm with 32bit? Since there is no i386 Support anymore

Edit: yep i forgot to contribute that, I’ll do tomorrow

yes, it’s arm physical device 32bit.

Thanks

if you are not going to link against i386 simulator then you should change the filelist in the Xcode project to be remove ios-i386 and replace that with x86_64 for the simulator build

Other Linker Flags:
-filelist …/…/build/ios-arm/libs.list -filelist …/…/build/ios-arm64/libs.list -filelist …/…/build/ios-i386/libs.list -lz -rdynamic

change to

-filelist …/…/build/ios-arm/libs.list -filelist …/…/build/ios-arm64/libs.list -filelist …/…/build/ios-x86_64/libs.list -lz -rdynamic

Hi,

The latest commit sorts that problem.

I know, I didn’t do that because for some reason I’d pollute the whole project with my local File Paths and everything specific to my machine.
Also I was unable to build it by adjusting this (it always wanted i386, so I had to tick “Only build for target architecture” or something.

I have to see whether I change it, but at least it’s something a iOS-Dev should figure out since there might arise more problems with the fragile project configuration.

@Darkchaos
@GTWhite
Sounds good. Thanks for the fixes. Not tested up to now, but thanks for addressing my issues.