[RFC] The UrhoBox (was Embedding Urho3d)

The exercise described here, somehow succeeded. The existing work on RPI and ARM, has been really helpful.

Summary: Embedd our engine in a Linux Embedded System that could be trimmed to only play urho3d games. Deploy the system on specific popular Hardware. In other words, the Urho3d-Only Video Game Console.

I am in the process of converting this exercise in a project, small website for downloading the images, instructions for building your own, etc etc. So I’d like to gather your comments (polluting the forums as less as possible) regarding:

Name: Propose a name for this. You can comment if some other proposal in this thread you specially like or dislike(indicate the reasoning in this case). As the background intention is to promote our engine, proposals containing urho are preferred.

Targets: If you would like to test or be involved, indicate which Raspberry PI models you own. Other boards are also welcome, but they must be yocto supported. Each build takes several hours, and ~50GB of disk space, therefore I need to go for the most relevant targets.

Project templates: The games would need to follow some standard, this standard we can be based in our already existing templates. Indicate if there is any template missing in this thread.

Game definition: Eventually there will be some kind of game selector(name wanted), as such, the project template should contain some kind of Game-Manifest. (Name, Desc, Genre, …)

Comments: Feel free to add your comments & Questions

Topics regarding games distribution like:

  • “How do I build my game for this platform?”,
  • “How will the system fetch/download my Game”

Will be addressed later on a third loop. My initial intention is maintain myself the opensourced and most close to a determined official template as part of the project, even preinstall them in the image.

Please read other users before posting, I beg you, 1 reply per user(edit your post as long as the following 2 weeks). As a start, I will give my own:

Name: UrhoTank(from fishTank, might sound warlike in many languages or relate to Tank games, which would be misleading)
Targets: Rasp 0w
Project Templates:

Game Definition: I don’t know previous exercises, or already defined standards, maybe from other gamming hubs. Initial proposal: Xml containing (Name, SubName, Description, Version, Genre, Sample Pictures, Requeriments Benchmark) Pictures should be contained in the Resources folder.
Comments: I already spoke way too much, hope this way of gathering information is ok, once everything is setup I can move most of discussions out.



  • The Fin – “powered by Urho3D”

Because this project (and it’s variations/installments) will be an important part of the fish, pushing it forward. This name also lends itself for a fin-shaped case design, like an organic Wii. Lastly it points to Finland, where it all began, while meaning “end” in French: α & ω :fish:

Project templates:
About the QtCreator wizards I would like to add that they have by no means acquired their final form; suggestions and pull requests are welcome. [ forum thread ]
For instance it currently expects qmake is used to build the project. This could be extended with cmake for instance. Also, as I made these wizards in isolation (without collaboration) their code should basically be considered unreviewed.


A little update update on how things are going:

Game Definition: As the the whole environment used for this is python based, currently a JSON file was the more straight forward way.
On how each game will be present in disk, I let the build environment dictate. A sample how the resulting structure is can be seen here and how it is created

Project Template: @Miegamicis Template has been integrated, and will be the base at least in this early beggining.

NAME: As seen in the post title, things urged to be named to create repositories and so on. I finally went with the initial name in the very first proposal: UrhoBox
Logos of a fish inside a semi-transparent box are welcome.

Game Distribution: The current idea on how games can be distributed is using already existing packaging (rpm, deb, ipk), as yocto creates them automatically. It will be necessary to be able to install in alternatives paths other than /.

Game Selector: I have started the development of a game selector is a very important piece. Will be the starting up program. It needs to:

  • Scan the available games on available disks, network, repositories, stores…
  • Be able to browse, download and launch them
  • Preferences (would be interesting if they could be shared among games…)
  • Reboot / Shutdown / Park the UrhoBox

What is Park? Park would turn UrhoBox into a standard linux system so people could install other application & services while UrhoBox does not act as a Gamming Machine.

Oh! and this piece of software will be called theFin

After now, Feel free to comment on any point.

This is @Miegamicis template game launched from the x init session.


Nice! Glad to see that it’s actually used somewhere. :+1:


Here is another loop.
I might now say all the key components are now in place.

The system now boots in a game selector(thefin) which is very simple and there is room for improvement and collaboration. It is using only urho3d provided assets, and a custom scene file(obviously derived from a known example). It is based on the @Modanung QTCreator template.

Then you will see in the video launching 2 games:

  • Second seen in the video is the same as can be seen in my previous post.
  • First one was my initial playground on urho3d engine. But the important part here is that this is an example of how a game can be deployed to the system without having to release the sources or keeping a git repository somewhere. Here can be seen of the location of the source code is actual a local filesystem path. Note as well the ~21 fps for such a low spec hardware :slight_smile:

Anyone could build the complete image, or a simple game. In the second case a rpm/deb/ipk file is generated and that could be distributed (this part is the initial idea, but is currently functional). A wiki is on the way to explain these steps.

The image found in the video can be downloaded here (follow Скачать word)

Feedback is welcomed to know how and where to go :thinking:

PS: Yes, reflex on screen show me avoiding children from getting the keyboard to play…


@urnenfeld Do you have an image for the rpi0 somewhere? I will try to give it a shot next week as I have a week holiday.
Sry I didn’t read everything (yet). And still have to wrap my head around that whole process…
EDIT: Not sure my pi zero is working at all!? :smiley:
At least I already printed everything for the “Switch Killer” aka The Fin :wink:


@dertom of course I keep the images. I can publish the very same that was shown in the video. Let me some days until I get my fiber service fixed. I am on mobile internet right now.

Current image is very minimalist, I added a ssh server and some wifi required tooling but have not tested, if that is enough to connect. Would you find useful to have something more already bundled?

These printing are really interesting and motiving :open_mouth: Is one of those cross acting as the pointing device/mouse? Can’t wait to see all together!

No need to hurry, it seems my rpi0 is broken?! It is just not booting up. Tried everything. It worked once a bit but with errors concerning mmc-something. Since then nothing…A new one is one the way…let’s see how long that will take to arrive.

The crosses are the dpad. Not sure about how that will be mapped to the device. Would more guess like cursor-keys,…
Not sure how well that works(mechanically), felt a bit awkward on the ‘dry-test’. Maybe I will change that to single buttons. But this 3d model I found in the internet is a good base. I already experimented with flexible Print-Material(tpu) for the top parts which made it feel a bit better and not so clunky… But first I want the thing to boot up…

No need for you to customise the image for me. I will try to run that meta-urho3d thingy on my own. Maybe I will ask about that some times…thx so far

Have you tried another uSD card? there is no mmc integrated in the board AFAIK.

If you own a rpi2 or rpi3, it might be a good moment to enable support.

If the kernel publish that device as normal keyboard/mouse events, must work. If it is some other type of input device, we might need to add something more…

Cool! I will complement the building steps in the wiki during the weekend. I just got the fiber fixed!

Yeah, I tried several SD-cards with different versions of raspbian and a prebuilt one for that gaming addon,… I flashed so much yesterday I needed sunglasses :smiley: I also tried the plug the rpi0 in as a usb-device in the computer. That actually did work,…it was recognized so the thing as a whole seems to work (which kept me trying for some more hours :smiley: ) Burnt lots of time and decided to wait for the new one. :wink:

I acutally have a whole armada of SoCs (lots of Orange PIs, some RPis and one Odroid) but since I have this gaming device that fits directly on the rpi I do want it to work with that. The other ones are more or less (more less) working in my ‘mega’ arm-cluster :wink: (That was another time burner-project: setting up a kubernetes cluster on arm…:smiley: )

That would be epic…

@dertom I have updated the wiki. There are better details on the building process. There should be no errors so feel free to report any surprise, to improve the guide.

As for the image, I have edited the previous post. Check link below the video.

1 Like

Thx for the detailed wiki. Very appreciated and thx for uploading the image.

So it is right, that this image is pi0 only, yes? Nontheless I tried the image on my an rpi3b and rpi4. On the rpi3 you saw only the typical initial rainbow-colored rectangle…on rpi4 nothing. :wink:

Then I started with following the wiki. Everything went quite smooth until the very last step, where you pointed out to:

bitbake urhobox

But I only get an error:

ERROR: Nothing PROVIDES 'urhobox'

I could start some process using:

bitbake core-image-minimal`

Actually not sure that is the intended process, at least it tells that meta-urho3d is in the build-config:

`Parsing of 823 .bb files complete (822 cached, 1 parsed). 1295 targets, 82 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.40.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "qemuarm"
DISTRO               = "poky"
DISTRO_VERSION       = "2.6.4"
TUNE_FEATURES        = "arm armv5 thumb dsp"
TARGET_FPU           = "soft"
meta-yocto-bsp       = "thud:958427e9d2ee7276887f2b02ba85cf0996dea553"
meta-raspberrypi     = "thud:4e5be97d75668804694412f9b86e9291edb38b9d"
meta-urho3D          = "thud:2790a3d59f53488a02974d70b4db801b00d87720"``

Obviously I don’t know what I’m doing, yet. But I’m curious what the result will be :smiley:

Thx so far

EDIT: first build ran through but obviously not with the result as wanted. Now trying:

bitbake core-image-urho3d

Oh,…ok. Found out that I used the wrong machine. I used one of the predefined but would have to use one of those:

raspberrypi0  raspberrypi0-wifi  raspberrypi2  raspberrypi3-64  raspberrypi3  raspberrypi-cm3  raspberrypi-cm  raspberrypi

Next try ;)… ah, now I know what it was meant with main-table in the wiki :+1:

1 Like

I wrote it very fast there might mistakes from all sorts… orthographic, grammar …

Yes, the pi0W actually, even the build system would generate only for this as it is now :frowning: but it is the next topic I will work. It must be very easy reach that stage.

My fault :cry: sorry, I missed to commit the very last stuff. Just pull the latest changes from meta-urho3d repo again. To recover the environment, you only need to repeat the:

source sources/poky/oe-init-build-env my-urhobox-r0w-build

As you already realized, you need to setup the MACHINE var (in conf-/local.conf) to raspberrypi0-wifi.

Judging by your output, everything is correctly setup, you are good to go with:

bitbake urhobox

Thanks for giving a try!!

1 Like

cool,…got it completely compiled for pi0. Maybe I will give it a try with rpi3 later.

1 Like

Great! I have tested locally, and verified the resulting ouput, but no test… It wasn’t supossed to be that easy…

So to make the yocto apply the same patching for any Raspberry MACHINE try this:

Note meta-raspberrypi does not support the pi4 in thud branch. :pensive:

1 Like

Well,…I could actually create an rpi3-image.

But now comes the but :wink:
After the loader-screen, it first told me:

init id s0 respawning too fast disabled for 5 minutes

I could come around this by disabling uart in config.txt on the device itself…

After that I get some other error, see image:

Not sure what to do about this. I’m a bit lost. Btw, do you have a good way to test those images on the desktop or did you test all on your rpi0?`

I guess I will start over after a break… maybe on an other Yocto branch…and first with some samples. One step after another :wink:

1 Like

So the xsession will launch the script /etc/mini_x/session (what is called thefinloop) and that script for some reason could not launch thefin. I assume there exist /usr/bin/thefin in your image as well…

I wonder if the Error: No calibratable devices found. is shown/triggered by urho3d engine…

You can always CTRL+ALT+F1 and get a tty. root is without password

Other option is to remove file /etc/mini_x/session then you will boot to a simple x terminal, where you can launch thefin/template/samples manually, but you would need to take care of the environment vars for locating resources(check ls /usr/bin*-launcher scripts).

We can say there is, I can set the MACHINE to qemux86 and run on PC, this is extremely slow, so I have not actually checked in deep how functional it is… I just saw it reaches thefin.

Ok,…I will check this out someday. For now I wait for the rpi0 to arrive,…I think I understood what steps you took but without deep knowledge of linux and its boot-process and how X11 egl and co play together it was a bit too much if something does not work. The problem is that I tested too much and the image that worked is lost (the thing that I copied was just a symbolic link :smiley: )
At the moment I play a bit with buildroot. A similar project. I find the mini_x interesting cause I also wondered what would be the best setup to just start one opengl application…
Thx so far, when the rpi0 arrives I will be back on yoctus… :+1:

1 Like

Well finally the rpi0 arrived (I should have looked at the delivery date before).
Too bad I have no time for this stuff atm. But I could test two things:

  1. UrhoBox - TheFin image you provided works:
  • Bad thing I my usb2otg blocks the 2nd usb. So all I could do so far is starting and watching the box start. :wink: (In the photo you see another effort to use a normal micro-usb and conect the device via UsbFemale-adapter)
  1. Obviously it doesn’t work with this game-hat I bought. I would have to install some drivers,…and to do this via yoctu would cost me 2 weeks and still won’t work :wink: The gamehat works with a provided image though…and one thing I can say…the display is tiny. Guess 1.5" is not enough :smiley: :wink:

Again thanks for your efforts. I can’t imagine how many hours and days you must have burnt for this to work. :+1: Still I do love the yoctu project and how you can create your own linux-distribution. Wouldn’t it be great to have a fully setup and ready to go for developing UrhoOS :smiley: :wink:

Now I order me a better usb2otg-adapter and we will see. I have some holiday in july…I guess then I will play with it again.