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…
Or simply the Fin?
It could have 3D-printed standing case inspired in shape by Urho’s back fin, like an organic Wii. The name would also be referencing @cadaver’s nationality (in several non-English languages) and French people would be confused as it boots. Several other meanings of the word:
As bad as even I am not sure if will ever support it … (RaspPi Zero W)
I encourage anyone to filll PRs or Issues in the meta-urho3d for such feedback
Well, that applies for any Software Development
For the ones following I moved to a branch called pyro (yocto convention) for the rpi0 development. Despite it is trying to compile and passed through the configuration stage, I have my doubts as urho3d buildsystem is trying to crosscompile while yocto already takes care of this.
For example, yocto interprets that everyting behind that cmake is meant to be crosscompiled, but there are things inside the project which looks to be meant to be build natively(LUA, Angelscript?). It would be useful to know if these 2 parts can be somehow separated or launched separatedly.
As for name the of all this if it ever reaches something…
One of main reasons of the exercise, was to promote the engine. Therefore I would have a strong position to keep the word urho inside the name of the project.
As there would be other elements & entities around this (game selector, some kind of lifecycle), all the good ideas risen here could have its place, even for codenames or versioning… at a last step it could be as well voted
I don’t have a rpi0 but I have several other of those Singleboard-Computers (rpi 3b+,odroid-c2 and a couple of different orange pis). So if i can help with those devices maybe at a later stage, I would be happy to do so.
EDIT: Actually I compiled urho3d on odroid-c2 and orange pi pc2 a couple of days ago which worked out of the box (without anglescript and another cmake-switch) and I got 8fps on both (both were not accelerated…)
It was the sprite demo, as well as the physics-demo. I actually didn’t test too much. I was mostly interested if it works and I’m more interested to test it in headless-mode as server…(someday )
About the acceleration: I’m using armbian-imgs as OS and those did not had the mali-graphics-drivers included. The official odroid-c2 ubuntu have those but I didn’t had time to test those…maybe I will give it a try this weekend…
(EDIT: forget it. I just saw that I installed armbian again…this is because I’m experimenting kubernets to cluster my mini-computers and I want to have the same OS-Distri on each…nonetheless once there is something to test…tell me. I got lots of SD-Cards )
Yes, I compile on the device…I tried to cross-compile once (some time ago) but did not succeed,…the only problem with compiling on the device was assimp that seems to be too much for my little device Therefore I disabled the tools. Anglescript had millions of strange errors…