Embedding Urho3D


Thinking how could I help this community with my current knowledge. I came to apply yocto.

It could not sound familiar to people who is not into embedded linux. Summarizing a lot, this is a way to transparently crosscompile your project to any Linux embedded platform regardless of the compiler/architecture/soc. Somehow if there is a Linux kernel that runs the platform you can easily port your project into.

So I started playing, without major patching I could create a recipe(which is more merit of urho3d build system) which builds the whole Urho3D engine and embeds into a Linux Image. So ideally Urho3d engine could be run in any platform that there exists a yocto bsp layer for it.

The typical development goes first in a qemux86 virtual machine, and then you move to real HW. On this virtual environment unfortunately, the sample binaries does not run(Illegal Instruction). I kow the reasons, I need a bit of digging the urho3d build system, and later on will get more complicated when we get closer to the metal. But this is not the main intention of this post.

Eventually if this exercise succeeds I was thinking on a kind of Linux Distro targeted/optimized to Urho3D and Urho3D based games… A splash screen at boot up and ASAP going to some game selector/installer… “The UrhoBox” !?.. ok, some things might be utopic here…

The unique question would be, Is this something that catches the attention of the community?

It sounds interesting to me, although I have never heard the Yocto project before. Currently Urho3D can already cross-compile to RPI and any generic ARM platforms, so I don’t think it will be a herculean task to make it cross-compile for other target triplet. I would like to contribute (on my spare time), if you need help.

@weitjong With yocto this “ARM” support could be more specific or Normalized. I mean, urho3d may run in a rPI but maybe not in a NxP i.MX8 Sabre Board. Despite both being ARM.

In my development I am using a virutal target (a modified qemux86, which emulates a intel… erm… Pentium III). Binaries are deployed, but Urho3d tends to generate SSE2 code, which creates illegal instructions on the virtual target. So some help on what makes the build system decide to use SSE2 or not would be useful.

As well this might not be the place to track this… I could create tickets in the github then people could comment on them.


Earlier I mentioned that currently Urho3D build system can already cross-compile to generic ARM platforms, although it is only been tested on ODROID-C2 (ARM64) board and ODROID-X2 board by one or two users in the past. I believe our build system is capable of targeting any triplets like I said earlier. One just needs to provide the right mix of build options with the right cross-compiling toolchain. As long the boards run with Linux on ARM processor then it should be good to go.

As for the SSE SIMD instruction support, without looking at the build script now I think it should be auto-detected and configured accordingly. If the detection is wrong then you should be able to override it by using the URHO3D_SSE option. However, on 64-bit Intel platform this option cannot be turned off. Perhaps, what you need to tune is the compiler flags to target a specific “-march”. See URHO3D_DEPLOYMENT_TARGET build option for more detail.


This is already great, a good point and reference. After the qemux86 my plan was going for the rPi, the odroids should be next then.

This is where yocto could help. Currently the recipe is very basic, just builds Urho3D. When it is mature enough, there would be different customization for each board(MACHINE) supported. So these right mix of build options for each board would be clearly listed and automatized in the yocto recipe, and could be included in a Linux Embedded image.

Let me clarify this is not impacting Urho3D build system at all. It is an external process/tool that lets you fetch/configure/builds the code, letting you tweak every step…