Irrlicht Engine

hi folks
i'm not god with word's but this is my project , irrlicht full integrated with SDl2 usig the port of Irrlich for android.
the idea is to manage windows/input/assets/audio with sdl2 and the render with irrlicht
and use the java from sdl , i full integrate the admob sdk

this is the demo
https://play.google.com/store/apps/deta ... r.irrteste

https://github.com/akadjoker/IrrlichtSDL2

demo with haxe

https://github.com/akadjoker/HaxeIrrTeste

So what's the difference to the SDL device that we already offer within Irrlicht? It should already provide all those things and should hopefully work with android as well!?

hybrid wrote:So what's the difference to the SDL device that we already offer within Irrlicht? It should already provide all those things and should hopefully work with android as well!?

anything written for pre SDL 1.3 (aka, SDL2) will not work with SDL2. And, SDL2 is a better implementation.

Also, I'm looking for some help with my SDL2 port http://irrlicht.sourceforge.net/forum/v ... rt#p289656.
Assets aren't loading on Android.
@djoker?

I also doesn't see any advantage for SDL2 over our current solutions - native window managers. SDL2 for Android require JAVA activity and imho it's a worse solution than our based just on NDK. Of course a some devices like a X11 and iOS need some more improvements, but we're on good way. Anyway I think that we should drop our SDL1 based device and replace it by SDL2 based device.

Nadro wrote:I also doesn't see any advantage for SDL2 over our current solutions - native window managers. SDL2 for Android require JAVA activity and imho it's a worse solution than our based just on NDK. Of course a some devices like a X11 and iOS need some more improvements, but we're on good way. Anyway I think that we should drop our SDL1 based device and replace it by SDL2 based device.

It is true that the current implementations work well, but I've been having a lot of trouble just adding audio to an application on Android. Developing a native app that can run on more than just Android (or also run on Android) is a HUGE pain. By having an SDL2 device I can ignore what platform I am developing for.

You can use OpenAL which works on wide range of platforms.

Nadro wrote:You can use OpenAL which works on wide range of platforms.

I was going to use PortAudio... but, whatever, I've got SDL2 up and rolling nicely. I just need to get the draw area to match the screen size....

SDL2 latest on pastebin: http://pastebin.com/0qTTxDaA
GL on Linux and GLES1&2 on Android has been tested and working.

The SDL2 patch is complete.

Thanks, in upcoming days I'll try to integrate this patch with ogl-es branch.

Please don't do that yet Nadro. If we merge that before merging the ogl-es branch into trunk that means merging will get even harder than it already is. And unfortunately it is already hell to merge the branches and getting ogl-es back into trunk is scarying me already as it is now :-) (I already needed a full day just to get the simple patches of the last 2-3 months merged - and that was in the easy direction of trunk to ogles). For now let's keep that branch as close to trunk as still possible until we figure out how to merge it back. After that we can add new drivers and kick drivers out and so on.

OK, no problem. I'll wait

(I already needed a full day just to get the simple patches of the last 2-3 months merged - and that was in the easy direction of trunk to ogles)

Joys of SVN

Yes, imho GIT is much better in this case.

Yeah, it could handle some of the problems better probably. Thought not sure if it really can handle stuff like that code which we add in opengl driver in trunk belongs in the contextmanager in the other branch. I guess main advantage is that github helps to have a clean workflow by default. So you always get patches for specific versions, while in this case we already don't know anymore a week later for which version that patch was unless the author mentions it.