Irrlicht Engine

Please check performance with the custom shader. As I said before, mobile GPUs has perf problems with ubershader where a lot of branching + discard exists. Example no. 10 shows how to use shaders. For replace EMT_SOLID you just need a few code lines in your shaders.

@Nadra, Thanks, I'll check the code.

I have many reports about showing black with “.jpg” textures in OGLES2.0 driver . I've tried to add a jpeg texture to sample NO. 27(OGLES2.0), it also just shows black, anyone knows why?

@Nadro, more devices are supporting OGLES 3.0, do we have plan for OGLES 3.0 driver?

@BinMa
Thanks for a report

@penguin03
OGL ES3.0 driver is done (it mostly base on OGL ES2.0 driver), but need some clean up. I'm still working on OpenGL drivers redesign.

OpenGL ES 3 only represents 9% of market shares, so don't be in a hurry.
http://developer.android.com/about/dash ... sdroid.net

Neirdan wrote:OpenGL ES 3 only represents 9% of market shares, so don't be in a hurry.
http://developer.android.com/about/dash ... sdroid.net

Thought it might represent those 9% of the market which has lots of spare money ;-)

@CuteAlien
agree

@Nadro
Could you share the OGL ES 3.0 driver?

Irrlicht on Mobile tutorial

If you guys could check my mistakes, add your own knowledge and let me know what you think about it

penguin03 wrote:@Nadro
Could you share the OGL ES 3.0 driver?

Sorry but not yet (I redesign OGL drivers once again), I'll share this driver as quick as possible. Sorry for a delay.

Silly question, but since mobile phones and tablets have so many different screen ratios (ranging from 3:2 for iOS to 16:9), is the camera by default with 4/3 aspect ratio?
http://irrlicht.sourceforge.net/docu/cl ... 701f4a5b3c

Edit; Got my answer, IF there is a video driver, camera by default get width/height screen ratio, otherwise 4/3.

cww on Oct 25, 2013 wrote:Hi Nadro, thanks for the good work. I am refactoring my own code a bit with the latest changes and have the following thoughts…

For android onAppCmd callback, my app also needs to be notified (to save state persistently, for example), but the event already handled within CIrrDeviceAndroid. As a work around, I assign a new callback to android_app after CIrrDeviceAndroid is created. CIrrDeviceAndroid still needs to handle the event so I call irr::CIrrDeviceAndroid::handleAndroidCommand within my new callback. See below.

Code: Select all

 
m_pDevice = static_cast<IrrlichtDevice*>(new CIrrDeviceAndroid(param));
// use a custom onAppCmd callback
android_app* android = (android_app*)(param.PrivateData);
android->onAppCmd = customCallback;
 
…
 
void customCallback(android_app* app, int32_t cmd)
{
        // my code goes here
        ……
        // call original irrlicht callback function
    irr::CIrrDeviceAndroid::handleAndroidCommand(app, cmd);
}
 

A bit hackish but it works. One last problem is irr::CIrrDeviceAndroid::handleAndroidCommand is private, and I need to change in irrlicht source code to make it public. Hence if this function can be made public, or some other mechanism can be added for our own callback be triggered, it will be great!

Cheers!

Nadro on Oct 30, 2013 wrote:I marked 2 static methods (input + commands) as public in last commit

Uhmm they are private again? Or is there some better way to handle the android commands now?

I think I have made them private. The reason is that those are part of the implementation and not part of the public interface. Irrlicht never makes implemenation parts public with some tricks (like not putting them in headers but people in the know can call them if they still know they are there). That kind of stuff creates hell for maintainers - as you suddenly no longer know which functions you are allowed to change. So same way as in the rest of Irrlicht - if you want to re-use those parts you have to copy-paste them.

And _if_ we make them public - then there have to be functions in the public interface for it. Which probably means we have to finally create Interface classes per device (IDeviceAndroid, IDeviceWin32, IDeviceLinux etc) - which I would consider a rather good idea as I would have needed that already several times.

Edit: Btw - if this is about adding key-input please wait 1-2 more days. I have written a solution for that yesterday, but will have to rework it some more before I can check it in.

No, as I said, it's about handling the android application commands... Needless to say, this should be implemented in a lot better way. My proposal: have an abstract class, let's call it CAppCmdHandler in this post, from which the user can inherit and implement those virtual OnSomeCommand methods he needs. Those methods would be called inside CIrrDeviceAndroid::handleAndroidCommand. Kinda like the event receiver or light manager. Then pass a pointer to an instance of said class somehow to Irrlicht - probably through SIrrlichtCreationParameters.

OK, thanks - after some more chatting I get the problem (can't do this in user-code as it set's up some internal stuff which can't be done from user-app yet). Will work on this next week.