Embedding Urho3D

Hello,

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?

1 Like

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.

2 Likes

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.

HTH.

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…

Yep that was it, at least for this target platform:

1 Like

Sounds like a cool project. How about calling it The Fishmaster? :slight_smile:

1 Like

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:

  • black
  • classy
  • purpose

@urnenfeld You may be interesting in this trove of bugs for testing purposes. :wink:

These are your games aren’t they??

My roadmap is as follows:

  1. Deploy on Real HW (rPI)
  2. Define a format to Define & Describe a Game
  3. Develop some kind of game Selector/Launcher (Previous point would be its input)
  4. Splash screen (with name and art)

Feedback is really welcome for second and third point.

And mines (spanish) :smile:

Here’s a quick conceptual render to get a impression of what the Fin could look like:

There has been some collaboration, but it’s mostly an accumulation of my doing, yes. All code is licensed under GPL, assets are CC-BY-SA.

2 Likes

I like the design, but I think I’d go with rotating the board inside so that the whole thing is only as wide as the Fin (though the ports might ruin the appearance, I’m not sure).

1 Like
  1. Deploy on really bad hardware (it helps show up performance bottlenecks)
  2. Have some “ideas guy” describe a game, in great detail, and capture its requirements
  3. Define your coding standards and extract architectural requirements from the game design requirements
  4. Design your code architecture before you write a single line of code.
  5. Implement your architecture using placeholder/imposter methods.
  6. Complete your implementation iteratively, replacing placeholders with working code, while testing periodically
  7. Did I mention version control / making backups?
  8. Get some peer feedback along the way, it can help correct your course and save time and money.

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 :wink:


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 :slight_smile: 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 :wink:

1 Like

I think my Raspberry PI B+ is dead. Anyway as I said, I started with:

But I bought rasp0 in the past with domotics intentions, therefore I had not covered the mini-HDMI adapter required.

I mention because I could generate an image with the engine library and some examples, which was kind of the first milestone to evaluate if all this was feasible or not… but hey I cannot test it.

So while the adapter arrives, if someone owns rasp 0w and wants to test, I can upload the image somewhere. (I would do it anyways but villages here just get ADSL with 0.6MB/s upload…)

2 Likes

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…)

2 Likes

Can you share the actual switches?

Do you remember what got these 8fps? a sample? a particular game?
This is another feasibility fact…

I believe my work is linking to the proper broadcom accelerated libs…

1 Like

cmake -DURHO3D_ANGELSCRIPT=0 -DURHO3D_TOOLS=0 [PATH_TO_URHO3D_SRC]

(You can take out more…you know the docs with all cmake-switches,right?)

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 :wink: )

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 :wink: )

2 Likes

Yeah, I actually expected more of -DARM … are you compiling in target then?

So I’ll set them for benchmarking from now on :wink:

I have a Raspberry Pi 0w. If I can find a spare micro SD card I’ll test it for you if you upload the image.

2 Likes

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 :wink: Therefore I disabled the tools. Anglescript had millions of strange errors…

1 Like