mirrlicht - porting irrlicht to mobile platforms.

[inet]

Recently, I'm trying to port irrlicht onto mobile platforms. The first target is nokia's S60. Some preliminary results have been achieved. Latest source code can be download from code.google.com with a subversion client tool.

Some details and links are available on my blog.
http://graphicsmakesfun.blogspot.com/20 ... tform.html

[hybrid]

Very nice. An OpenGL ES port is also on my list, moreover since I'm developing embedded devices currently
Which revision did you use? Seems like one around 300?
I think we can replace some of the ifdef's with more specific ones testing for OpenGL extensions. This would also help with other OpenGL implementations.

I just saw that you still include glext.h - why? That way you won't know which extensions are supported. Moreover, the extension string is supported, so you just have to ifdef the glu part. Also try to disable the extension pointer part, might give better results (but might require several more ifdef's first).

Please keep us informed

[inet]

The trunk is synced with revision 301. I kept a sync directory under branches. This directory exists only for sync with the sourceforge depot of irrlicht. Then I merge it to the mirrlicht trunk from time to time.

>So you just have to ifdef the glu part.
What do u mean by "glu part"?

[hybrid]

The "glu part" is the use of gluCheckExtensions which I added some time ago to make things more reliable. But if you ifdef the check for the glu version and the if branch which uses the glu methods the dynamic extension check should work with OpenGL ES.

[inet]

AFAIK, OpenGL ES doesn't have glu functions. Besides, the opengl extensions like GL_ARB_multitexture should be unavailable in OpenGL ES although I haven't tested this.

[hybrid]

Yeah, so just disable the glu branch when compiling for OES. But the extension string returned by OES should be correct w.r.t. normal OpenGL syntax and supported features. That's why the extension check in Irrlicht should still work and initialize all variables correctly. Furthermore, you'll get automatic access to new features provided through OES extensions (at least for those that use the usual OpenGL naming scheme).
So what about the glext.h include?

[bitplane]

ooh.. I'm also interested in this topic.. I've got a Nokia S60 myself (6680), I've never done any development on it but now may be the time to start!

[elektrikal]

of course i cant do such thing as i just started in c++ or even any other language but this is really intersting...back two years ago i got my Nokia3650 and i started downloading PDFs about programming on Symbian devices...i gave up but Irrlicht made me came back to start learning some C++ and now comes this which is wonderfull...u have my attention.

many thx.

[inet]

To hybrid: About the glext.h.

I include it for using the function pointer type used here.

Code: Select all

#elif defined(_IRR_USE_OPENGL_ES_)	
         pGlActiveTextureARB = (PFNGLACTIVETEXTUREARBPROC)glActiveTexture;
			pGlClientActiveTextureARB = (PFNGLCLIENTACTIVETEXTUREARBPROC)glClientActiveTexture;
#endif

glActiveTexture and glClientActiveTexture are core functions supported by OGL es. They are not extensions. So I just directly cast the functions.

I still cann't figure out how to use the extension query to init the extension function pointers.

Have you tried eglGetProcAddress("glActiveTextureARB")? It just return NULL pointer in my debug session.

[hybrid]

Returning NULL is the correct behavior since the core elements should not be queried by GetProcAddress IIRC. However, this will make it difficult to use extension pointers with the OES setup. I think it might be easier to use the direct calls, i.e. disable extension function pointers. But you should definitely avoid to include glext.h as it does not contain the necessary oes_ extensions. These are also defined in the appropriate gl.h files.

[inet]

Before glext.h, I also included OGLES/egl.h, this header includes the OGLES/gl.h in turn. So OES extensions are included.

I think it might be easier to use the direct calls

In order to use direct calls, I have to modify these routines: extGlActiveTextureARB, extGlClientActiveTextureARB. Now I just set the function pointer so that I don't write some special for these two functions.

I include glext.h as a temporary solution also because some GL macro definitions such as GL_MULTISAMPLE_ARB, GL_SRC0_COLOR_ARB used in COpenGLDriver.cpp are not in the standard OGLES/gl.h.

Maybe later, when we have a cleaner solution for the extension mess, we can remove the glext.h include.

[hybrid]

Well, you don't need to change the methods, just disable the IrrCompileFlag such that extension function pointers are not used anymore. This works for OSX and Solaris already, so why not for ogles as well?
The inclusion of glext.h makes it impossible to check at compile time which features are (at max) supported by the implementation, because this spills out all defines available. Otherwise you can do some #ifdef GL_something to check for support of something.
I guess the missing elements simply are not available with ogles so they need some work to be done. Using them would cause problems anyway.

[inet]

The problem with disabling the use of extension pointer is the ARB postfix.
Maybe I should write a small header to redefine these ARB things by myself?

like
#ifdef _IRR_USE_OPENGL_ES_
#define glActiveTextureARB glActiveTexture
#define GL_MULTISAMPLE_ARB GL_MULTISAMPLE
....
#endif

Another option would be simply replace the ARB version of macros and functions with the ones without ARBs.
like in extActiveTextureARB
just use
if (MultiTextureExtension) glClientActiveTexture(texture);

The rationale behind this is: For the macros and functions that have been already promoted to opengl core, if there is an ARB version there must be a corresponding version without ARB.

Personally I prefer the second option. What do u think?

[hybrid]

The problem with dropping the ARB suffix is that older revisions of OpenGL libraries won't work anymore. Since direct ogl calls require an exact equivalence of the entry points with method names we would have to add both versions. This would add several more ifdef's and probably introduce lots of compile problems. I did not check all possibilities yet, so maybe I'm missing something.

[inet]

You're right about the incompatibility with older OpenGL libraries.

So if we need to remove glext.h, we need to do the following:

1.Disable _IRR_OPENGL_USE_EXTPOINTER_
2.in each COpenGLDriver::extXXXX function add #ifdefs for direct calling.
3.Following the GLES/gl.h inclusion, instead of include glext.h, we need to another header which contains definition of the _ARB macros to satisfy the compiler.