Irrlicht on Raspberry PI

[hybrid]

I got mine on Friday, finally. But I doubt that I will have enough time the next days, so updates maybe next weekend or so.

[sudi]

Did you receive the upgraded 512mb version?

[hybrid]

Not sure, yet, but I doubt this.

[ACE247]

The 512mb units will probably take yet another 4 months to get to customers. But the 256mb limit isn't really a problem. The CPU's ARMv6 Architecture is the biggest problem(v6 already 10 years old). The PI in a nutshell is actually just a (relatively) large GPU with a small CPU and some RAM botched onto it. I got mine quite a while ago and used some shift register, adc and dac chips to expand its gpio capabilities and am mainly using it in a Robot as a wifi remote controlled and camera streaming server setup running arch linux(which is fastest) and then have that hooked up to an Arduino Mega that drives all the mechanical functions of my robot. It's pretty good actually, until you try compressing audio/video files in the cpu or not to mention opencv...

[hybrid]

So Irrlicht takes about one hour or two to compile directly on the pi But the results are pretty good, right away I got more than 30 FPS with example 4. But there are still massive problems with the shaders (I used the gles_v2 driver). And all this of course in debug mode, so numbers should become better. Properly fixed version for pi will be available later this year, when we fix the ogl-es branch.

[hybrid]

The compilation is quite simple. Just apply my patch and disable OpenGL in the IrrCompileConfig. Then call make in source/Irrlicht and in examples/ after that. If you fix the width settings in the patch, you even get a proper rendering, otherwise the image is quite displaced and stretched. So simply avoid overwriting the result from the display settings call and push those values into the native window struct. Oh, and you have to fix the shaders, they can only handle up to 2 lights, otherwise too many texture access are mentioned. Just change the define in the vsh files.

[sudi]

The compilation is quite simple. Just apply my patch and disable OpenGL in the IrrCompileConfig. Then call make in source/Irrlicht and in examples/ after that. If you fix the width settings in the patch, you even get a proper rendering, otherwise the image is quite displaced and stretched. So simply avoid overwriting the result from the display settings call and push those values into the native window struct. Oh, and you have to fix the shaders, they can only handle up to 2 lights, otherwise too many texture access are mentioned. Just change the define in the vsh files.

So i just have to checkout the ogl-es branch and apply your patch to get it to work? Which patch?

PS: what libs did you install on your pi to get it to compile? which OS did you use

[hybrid]

Patch is on the first page. I took the raspian standard image (Debian wheezy). Installed a few packages, yes, but not sure anymore which were really essential. vim and svn were missing IIRC. Maybe also some x11-dev packages. You'll see what is missing once the compiler complains.
The patch just inserts the accelerated window creation on top of the x11 device. It cannot use the x11 window, though, as no hw acceleration is available for x11, yet. So it simply uses the framebuffer and overwrites the x11 screen completely. Which also means that the cursor is not visible. But events are still working.

[dextrus]

I see the code has changed since you posted (the patch failed) and I doggedly tried to manually apply the patch (I failed). I see that one part you've changed has been "officially" changed in the latest repo. Does this mean we can see a Pi-friendly version soon?

/Dextrus

[hybrid]

Well, for now the PI setup only uses the Framebuffer, so the code has to be ported over to the fb device and work there. Don't know when this change will be applied. Moreover, this also means that you don't have the usual user IO events from X anymore, so maybe problems with steering and control. But since the system is now standing in my office it has a good chance to get some updates.

[dextrus]

Thanks Hybrid and Thalhammer. I have it running too now, but at a dissapointing 10fps in DEBUG (Quake level) using OGLES2. Still, this does mean I can proof-of-concept a ton of Irrlicht content on the Pi! My kids are forcing me to do Minetest next. sigh..

[dextrus]

Got around to doing the release build. 40fps! That's a lot of debugging in that thar build!

[dextrus]

So, does anyone have any suggestions about providing an Irrlicht-compatible way of drawing to the screen? Is there a magical #define/#undef combination or would I have to hack something in myself?

[hybrid]

What do you mean by that? It does render to the screen!?

[dextrus]

Apologies, yes it does render to the screen (and quite fast too!). It's not exactly usable though?