Port Ogre to Android?

[calsmurf2904]

:O Has it been tested to actually work? I also got about the same but the problem is that it doesn't compile any of the android makefiles.

[Assaf Raman]

Have a look here: http://groups.google.com/group/android- ... 8cd5b27193

Hi all,

I've built my own version of android ndk which support full C++
standard library (including STL), exceptions and RTTI. I did it using
official ndk build scripts and sources, just little patched them.
Actually I was wonder how easy it was. I've used exceptions in massive
piece of code which I have now ported to android (libstdc++ linked
statically) and seems all works fine.
Only linux and darwin variants ready for now -
http://www.crystax.net/data/android-ndk ... ax.tar.bz2,
http://www.crystax.net/data/android-ndk ... rystax.tar....
Diff I've created to build customized ndk -
http://www.crystax.net/data/android-ndk ... ystax.diff.
Hope it would help to you guys

[calsmurf2904]

Downloading it, his webserver is really slow.
If this actually work we could compile Ogre for android.
It also has full libstdc++ support so thats not a problem either.

[fredguinog]

Great!

[calsmurf2904]

Alright, got Freeimage and Freetype compiled. ZLib was included with the NDK already. OIS isn't possible since it doesn't have Android Input support.
CG isn't possible either since, well....I don't think that needs further explanation.

I have some problems with zziplib though, I'll look further in it tomorrow. (Sleeping time now ).

[calsmurf2904]

Thinking about it, is zziplib really a must? I can't seem to get it to compile for android, which kinda sucks since Ogre needs it.

So these are the deps I have compiled:
Freeimage
Freetype
ZLib

The deps I haven't compiled:
ZZipLib
OIS
NVIDIA CG

[Wolfmanfx]

just disable zip/cg/ois support ogre core do not need them.

[calsmurf2904]

I know, but this also means that none of the demo's will run duo to the OgreCore.zip etc. (Well, We can but we need to edit the resource.cfg a bit and unpack all zip files).

[calsmurf2904]

Alright, it seems that CMake doesn't like generating UNIX makefiles on windows. So no possibility there unless I go command prompt in cygwin (Which I'm not even going to try at this moment). The problem is that I need to compile 1.7 because 1.6 doesn't contain the GL ES rendersystem. (Which I obviously need for android).

[Praetor]

You can just take all the core assets needed by the demos out of the zips for Android use and just use the file system archive for them.

[Azgur]

I'm curious though, there's all this effort being made to get Ogre itself to compile.
Did anyone do a small test application yet to try if getting exceptions to work on Android actually works in their tool chain?
If that won't work, all the other work will be kind of wasted as well.

[calsmurf2904]

Well, the guy posted that he has his whole engine ported to android and his engine uses exceptions. So I think it works.

[pyrokar]

I'm very exited about this, just read the whole thread =)
My android device will arrive this month, it's great to see there is some activity about an android port!
Maybe something similar to this (iphone app) will even be possible.

[calsmurf2904]

I'm very exited about this, just read the whole thread =)
My android device will arrive this month, it's great to see there is some activity about an android port!
Maybe something similar to this (iphone app) will even be possible.

There already is an iPhone ogre port?

[pyrokar]

I'm very exited about this, just read the whole thread =)
My android device will arrive this month, it's great to see there is some activity about an android port!
Maybe something similar to this (iphone app) will even be possible.

There already is an iPhone ogre port?

I don't think this was done using ogre, so i don't know if there is an iphone port. It just impressed me to see what's possible.

[jacmoe]

It wasn't a question.
Ogre is already supported on the iPhone platform.
-> http://www.ogre3d.org/2009/12/07/interv ... iphone-dev

[calsmurf2904]

After not looking a long time into this (alot of reasons), I checked some stuff today.
The main bottleneck I found is that even though the NDK exports the OpenGL ES functions to C++, its not possible to create the "SurfaceView" from code, which is needed to create what ogre calls a "RenderWindow".

The ability to use OpenGL ES 1.1 headers and libraries If your application targets Android 1.6, your native code can now directly call OpenGL ES 1.1 functions to perform graphics rendering. This will help those programs that need to send large amounts of vertex data to the GPU. Note, however, that activity lifecycle and surface creation must still be performed from the VM. This NDK contains a new sample ("san-angeles") that shows exactly how to do that with a GLSurfaceView object.

The GLSurfaceView description can be found here:
http://developer.android.com/resources/ ... eview.html

So it seems to support android we would still need a java side to support it, which seems like quite a bottleneck.

Anybody willing to share some insight on this?

[edit]
Looking at this http://earlence.blogspot.com/2009/07/wr ... d-ndk.html (very basic) we might be able to create a thin wrapper interface in java, and use this in the AndroidRenderWindow. Especially since Android can't run C++ only applications, you still need some java code to boot it up. So we might be able to just add some java wrapper code for the stuff we can't do in C++. (IE, create the GLSurfaceView object).

[Praetor]

Yes, this is expected. Some java is necessary. We can just create a standard Ogre Android Java interface which people include in their Android apps to kickstart the Ogre setup process. I don't think this is a showstopper.

[Assaf Raman]

Have a look at the "san-angeles" demo in the NDK.

[calsmurf2904]

Have a look at the "san-angeles" demo in the NDK.

Yea, but that uses Java too. I'm proposing what Preator is saying, create a thin jni <-> Ogre wrapper that people include in their apps.

[Praetor]

I don't think it would need to be complicated. Just something for setting up and passing in window references. I'm not proposing a large-scale java wrapper. The bulk of the application should be kept below the java layer.

[calsmurf2904]

Something like: (psuedo code)

Java side:

Code: Select all

InitWindowEtc(); //Java function
InitOgre(GetWindowWidth(), GetWindowHeight()); //C++ function, GetWindowWidth/Height are java functions

//And eventually the user application would add
Main(); //C++ function

Ofcourse the actual code in java is larger.
The GLSurfaceView object in Java sets up the GL Context, so Ogre doesn't need to maintain the GL Context. We might be able to retrieve this from java and pass it to C++/retrieve it from C++ code though.

As seen here:
http://developer.android.com/reference/ ... derer.html
Android gives callbacks to the app when it needs to draw the scene, so we can just add another exported C++ DrawOgre() function and put it there.

One more question, how does the iPhone port handle input? 3rd party libs or included in ogre?
It seems that the GLSurfaceView object gives you the callbacks for input:
http://developer.android.com/reference/ ... eView.html

[edit]
Assaf Raman was right, the San Angeles demo provides a good base to start:

Code: Select all

package com.example.SanAngeles;

import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;

import android.app.Activity;
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;

public class DemoActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mGLView = new DemoGLSurfaceView(this);
        setContentView(mGLView);
    }

    @Override
    protected void onPause() {
        super.onPause();
        mGLView.onPause();
    }

    @Override
    protected void onResume() {
        super.onResume();
        mGLView.onResume();
    }

    private GLSurfaceView mGLView;

    static {
        System.loadLibrary("sanangeles");
    }
}

class DemoGLSurfaceView extends GLSurfaceView {
    public DemoGLSurfaceView(Context context) {
        super(context);
        mRenderer = new DemoRenderer();
        setRenderer(mRenderer);
    }

    public boolean onTouchEvent(final MotionEvent event) {
        if (event.getAction() == MotionEvent.ACTION_DOWN) {
            nativePause();
        }
        return true;
    }

    DemoRenderer mRenderer;

    private static native void nativePause();
}

class DemoRenderer implements GLSurfaceView.Renderer {
    public void onSurfaceCreated(GL10 gl, EGLConfig config) {
        nativeInit();
    }

    public void onSurfaceChanged(GL10 gl, int w, int h) {
        //gl.glViewport(0, 0, w, h);
        nativeResize(w, h);
    }

    public void onDrawFrame(GL10 gl) {
        nativeRender();
    }

    private static native void nativeInit();
    private static native void nativeResize(int w, int h);
    private static native void nativeRender();
    private static native void nativeDone();
}

[calsmurf2904]

Alright, this is the wrapper layer I'm proposing:

Code: Select all

package com.Ogre;

import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;

import android.app.Activity;
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;

public class OgreActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mGLView = new OgreGLSurfaceView(this);
        setContentView(mGLView);
    }

    @Override
    protected void onPause() {
        super.onPause();
        mGLView.onPause();
    }

    @Override
    protected void onResume() {
        super.onResume();
        mGLView.onResume();
    }

    private GLSurfaceView mGLView;

    static {
        System.loadLibrary("Ogre");
    }
}

class OgreGLSurfaceView extends GLSurfaceView {
    public OgreGLSurfaceView(Context context) {
        super(context);
        mRenderer = new OgreRenderer();
        setRenderer(mRenderer);
    }

    OgreRenderer mRenderer;
}

class OgreRenderer implements GLSurfaceView.Renderer {
    public void onSurfaceCreated(GL10 gl, EGLConfig config) {
        InitOgre();
    }

    public void onSurfaceChanged(GL10 gl, int w, int h) {
        OgreWindowResize(w, h);
    }

    public void onDrawFrame(GL10 gl) {
        RenderOgre();
    }

    private static native void InitOgre();
    private static native void OgreWindowResize(int w, int h);
    private static native void RenderOgre();
    private static native void DeinitOgre(); //where to put this one? can't find any callback like onSurfaceDestroyed or something
}

Its a slightly edited San Angeles demo, but it still needs some more stuff. Like we need to check with instanceof(gl) to see if it has gl es 1.1 or 2.0 support. Otherwise it would only be 1.0. I also removed the input stuff the San Angeles demo had. Anyone seeing something that needs to be changed?

[Assaf Raman]

In a few day I hope to also get into Android - I will try to help out then.

[calsmurf2904]

Cool I wish I even had an android phone lol, android sounds like a good platform. (Especially since it has C++ support instead of the weird Objective-C language the iPhone has).