Page 19 of 26

Re: Android Port

Posted: Sun Feb 09, 2014 11:40 pm
by Nadro
Example no. 27 is dedicated for Android.

Re: Android Port

Posted: Tue Feb 11, 2014 11:47 pm
by CuteAlien
Notice - latest version (r4679) has a change that might break a few applications until you modify your application. I changed it so the engine no longer adds "media" in assets automatically, but that must now be done by the user. But on the other hand you can now add any sub-folders in assets which didn't work before (you might have noticed that when you ever tried putting a font into another sub-folder).
Example is updated to show the change.

If you think this change is bad and we should always add "media" by default please complain and I'll revert it maybe (but I think it's better this way as I don't like hardcoding our example-paths in the engine).

Re: Android Port

Posted: Wed Feb 12, 2014 9:06 am
by Nadro
@CuteAlien
Last change is fine in my opinion, I agree that hard coded support for media directory was bad, at now it looks much better.

Re: Android Port

Posted: Wed Feb 12, 2014 7:34 pm
by Neirdan
Just encountered a bug while using

Code: Select all

 
irr::gui::IGUISkin* skin = device->getGUIEnvironment()->getSkin();
irr::gui::IGUIFont* font = device->getGUIEnvironment()->getFont("media/sansserif24.xml");
 
While it perfectly works with

Code: Select all

 
irr::gui::IGUISkin* skin = device->getGUIEnvironment()->getSkin();
irr::gui::IGUIFont* font = device->getGUIEnvironment()->getFont("sansserif24.xml");
 
media being a subdirectory of the /assets/ directory

I didn't modify the xml line

Code: Select all

 
<Texture index="0" filename="sansserif240.png" hasAlpha="true" />
 

Re: Android Port

Posted: Wed Feb 12, 2014 8:21 pm
by CuteAlien
@Neirdan: Are you using already the new version I had checked in? And did it work before? I have to test - must admit I never used xml's for fonts.

edit: I found the reason. Seems to be a general problem with files in archives. I'll fix it.
edit2: Fixed in trunk, still have to merge with ogl-es, but too tired already today.
edit3: Not fixed in trunk because svn is again funking up and I can't check-in *sigh*
edit4: Now finally checked in to trunk (r4679-4683). <rant>Crazy "Inconsistent line ending style" errors... it complained even when I run dos2unix and unix2dos on every single file which was changed. And no error message _which_ file is the problem. Great if you have lots of changed files. Only once I gave up checking them all in and checked in each folder one-by-one instead of all together it suddenly worked without having a problem with any file now. I get this stupid bug with svn on Debian every few weeks...</rant>

Re: Android Port

Posted: Thu Feb 13, 2014 1:09 pm
by CuteAlien
@Neirdan: It's fixed now as well in the ogl-es branch in rev. 4686. Thanks for the report.

Re: Android Port

Posted: Thu Feb 13, 2014 10:03 pm
by Neirdan
Thanks to you for fixing it.
What I did is nothing compared to that.

Re: Android Port

Posted: Mon Feb 17, 2014 8:50 pm
by Neirdan
Just found a weird bug. Basically I used the code below to generate a very ugly mesh that would make the app crash.
This code creates a square made of 2 triangles * iTotal times.
When you have more than 65536 triangles, the mesh simply doesn't show.

Caution: using a high number iTotal (but below 32768) will display a high number of triangles all at the same position, sometimes crashing the app and even crashing the whole phone.
I had to reboot like 5 times to corner that bug. I think the GPU can't handle that.

Phone used: HTC One - Android 4.3


This bug also explains a bug I encountered with ITerrainSceneNode being displayed very weirdly on some devices.
Because the terrain scene node does add & remove triangles dynamically inside the mesh depending on the camera position.

I think there is somewhere a maximum number of triangles per mesh set at 65536.

Code works perfectly fine on Irrlicht 1.8.1 / windows 7 desktop.

Code: Select all

 
void createMesh() {
    irr::scene::IDynamicMeshBuffer* buffer = new irr::scene::CDynamicMeshBuffer(irr::video::EVT_STANDARD, irr::video::EIT_32BIT);
    irr::video::SColor clr(255,255,255,255);
    unsigned int iTotal=32768;
 
    buffer->getVertexBuffer().set_used(4*iTotal);
    buffer->getIndexBuffer().set_used(6*iTotal);
 
    for (unsigned int iCpt=0; iCpt<iTotal; ++iCpt) {
 
        //indices
        buffer->getIndexBuffer().setValue(6*iCpt+0, 0);
        buffer->getIndexBuffer().setValue(6*iCpt+1, 1);
        buffer->getIndexBuffer().setValue(6*iCpt+2, 2);
        buffer->getIndexBuffer().setValue(6*iCpt+3, 1);
        buffer->getIndexBuffer().setValue(6*iCpt+4, 3);
        buffer->getIndexBuffer().setValue(6*iCpt+5, 2);
 
        //BL
        buffer->getVertexBuffer()[4*iCpt+0].Pos.X = -0.5f;
        buffer->getVertexBuffer()[4*iCpt+0].Pos.Y = 0;
        buffer->getVertexBuffer()[4*iCpt+0].Pos.Z = -0.5f;
        buffer->getVertexBuffer()[4*iCpt+0].Normal.X = 0;
        buffer->getVertexBuffer()[4*iCpt+0].Normal.Y = 1;
        buffer->getVertexBuffer()[4*iCpt+0].Normal.Z = 0;
        buffer->getVertexBuffer()[4*iCpt+0].Color = clr;
        buffer->getVertexBuffer()[4*iCpt+0].TCoords.X = 0;
        buffer->getVertexBuffer()[4*iCpt+0].TCoords.Y = 0;
 
        //TL
        buffer->getVertexBuffer()[4*iCpt+1].Pos.X = -0.5f;
        buffer->getVertexBuffer()[4*iCpt+1].Pos.Y = 0;
        buffer->getVertexBuffer()[4*iCpt+1].Pos.Z = 0.5f;
        buffer->getVertexBuffer()[4*iCpt+1].Normal.X = 0;
        buffer->getVertexBuffer()[4*iCpt+1].Normal.Y = 1;
        buffer->getVertexBuffer()[4*iCpt+1].Normal.Z = 0;
        buffer->getVertexBuffer()[4*iCpt+1].Color = clr;
        buffer->getVertexBuffer()[4*iCpt+1].TCoords.X = 0;
        buffer->getVertexBuffer()[4*iCpt+1].TCoords.Y = 1;
 
        //BR
        buffer->getVertexBuffer()[4*iCpt+2].Pos.X = 0.5f;
        buffer->getVertexBuffer()[4*iCpt+2].Pos.Y = 0;
        buffer->getVertexBuffer()[4*iCpt+2].Pos.Z = -0.5f;
        buffer->getVertexBuffer()[4*iCpt+2].Normal.X = 0;
        buffer->getVertexBuffer()[4*iCpt+2].Normal.Y = 1;
        buffer->getVertexBuffer()[4*iCpt+2].Normal.Z = 0;
        buffer->getVertexBuffer()[4*iCpt+2].Color = clr;
        buffer->getVertexBuffer()[4*iCpt+2].TCoords.X = 1;
        buffer->getVertexBuffer()[4*iCpt+2].TCoords.Y = 0;
 
        //TR
        buffer->getVertexBuffer()[4*iCpt+3].Pos.X = 0.5f;
        buffer->getVertexBuffer()[4*iCpt+3].Pos.Y = 0;
        buffer->getVertexBuffer()[4*iCpt+3].Pos.Z = 0.5f;
        buffer->getVertexBuffer()[4*iCpt+3].Normal.X = 0;
        buffer->getVertexBuffer()[4*iCpt+3].Normal.Y = 1;
        buffer->getVertexBuffer()[4*iCpt+3].Normal.Z = 0;
        buffer->getVertexBuffer()[4*iCpt+3].Color = clr;
        buffer->getVertexBuffer()[4*iCpt+3].TCoords.X = 1;
        buffer->getVertexBuffer()[4*iCpt+3].TCoords.Y = 1;
 
    }
 
    // Recalculate bounding box
    buffer->recalculateBoundingBox();
    //Create mesh
    mesh = new irr::scene::SMesh;
    mesh->addMeshBuffer(buffer);
    buffer->drop();
    mesh->recalculateBoundingBox();
}
 

Re: Android Port

Posted: Tue Feb 18, 2014 1:16 pm
by mikkis
I compiled official (newest) Irrlicht ogl-es branch and Android example (no 27), it works with emulator from sdk, but when I run example in BlueStacks (emulator), none of the textures doesnt show (sydney, logo and fonts are just black when using GLES20 driver, and white if using GLES10). I would like to use BlueStacks because it is fast.

Re: Android Port

Posted: Tue Feb 18, 2014 1:53 pm
by CuteAlien
You got it working with the emulator from the SDK? I spend some hours on that without success so far (I never got anything but a black screen).

Re: Android Port

Posted: Tue Feb 18, 2014 3:19 pm
by CuteAlien
@Neirdan: 2 problems responsible for that. First in COGLESDriver.cpp (also in ES2 driver). There getMaximalPrimitiveCount() returns always 65535 - that's the check where it fails in your case (and which probably isn't quite correct, but I won't modify it for now as I'm not familiar enough with the code). You should get an error for that in the error.log in debug (with: adb logcat Irrlicht:V *:S).

But even when trying to increase that constant it won't work here because my device doesn't have the GL_OES_element_index_uint extension which is needed to support 32-bit drawElements calls (https://www.khronos.org/registry/gles/e ... x_uint.txt). And given that I have a rather new device (moto g) it's probably a better idea to split your models into smaller blocks than expecting devices to have support for it.

Re: Android Port

Posted: Tue Feb 18, 2014 3:44 pm
by Neirdan
Yeah that's the solution I chose, but it also means that the TerrainSceneNode won't work for a heightmap bigger than 180*180 (when fully displayed with no LOD).
I also don't want too many drawcalls (splitting a 256*256 heightmap into 16*16 sectors = 256 drawcalls).

Re: Android Port

Posted: Tue Feb 18, 2014 4:04 pm
by CuteAlien
Sorry, I don't know a way around it. As far as I understand it GL ES in Android devices simply doesn't support it unless they have that extension.

Re: Android Port

Posted: Tue Feb 18, 2014 5:21 pm
by mikkis
CuteAlien wrote:You got it working with the emulator from the SDK? I spend some hours on that without success so far (I never got anything but a black screen).
Yes, example works with sdk's emulator using API19 (android 4.4.2) target.
When I use API10 (android 2.3.3), got only black screen. Tested that example on my phone too (android 2.3.6), black screen (last time last year it worked).

Re: Android Port

Posted: Tue Feb 18, 2014 5:28 pm
by CuteAlien
Ah thanks - I also used API10 as target.