Godot: Add support for custom export templates

[sunnystormy]

I wanted to know if there was a way to include the ARMv7h compiler toolchain with the engine so that users could export to X11 ARMv7h platforms (Raspberry Pi 2 and related ARMv7h boards)?

Since those SoCs are very cheap, I think pivoting to embedded systems like these could broaden our audience.

Let me know your thoughts!

[slapin]

You can build for these by editing scons files.
But you will need to fix some logic detection there.
Otherwise it works fine, just not supported.

[vnen]

Major problem with such ports is that no one in the community uses the platform, so there's no one committed to maintain those. One example is the Haiku port that we don't even know if it still works.

If you (or anybody else) want to port and maintain it, you are welcome to do so.

[akien-mga]

Though in this case the platform would stay X11, it's likely just a matter of allowing to build for arm and not only for x86 and x86_64 (which should work - at least for the templates - as we already build the templates android and iOS ARM devices).

[vnen]

There are some processor-specific optimizations that need to be enabled/disabled depending on the target. But I'm not against this, especially if it's trivial, it's just that IMO we need to make sure it works (even if experimentally).

[vnen]

BTW there seems to be some experimental support for Raspberry Pi in @x1212's fork: https://github.com/x1212/godot

Based on the video there was a need of workarounds to deal with the limitations of X11 and OpenGL.

[sunnystormy]

I would like to look into this, then, especially if it gives me experience with publishing to other platforms.

Ideally, I'd like to start with just getting an export script to work. I think that a full engine port is a bit more effort, but something I'd be willing to do down the line.

Could any of you give me some pointers on where to start creating an export template? Thank you!

[akien-mga]

What we call "export template" is actually the engine compiled for a given platform, without the editor tools. So it's not really a matter of writing an export tool, but more to edit the buildsystem (the main SConscript and the platform-specific SCsub, platform-config.h and detect.py files) to allow building Godot for X11 on an arm platform.

[x1212]

The main problem will probably be that you won't have just one X11 ARM platform ...
So far every ARM platform I build godot for had other slightly different issues due to the drivers not doing what they should be doing.
On the Open Pandora the GLES2 and x11 overdraw each other depending on what changed last it will either be x11 or GLES2 that is visible in one place (basically if you move the mouse it will be visible until the next frame is drawn by godot). Otherwise it's mostly just replacing glx with egl.
On Raspberry Pi you get four different options:

• using the really slow Mesa OpenGL
• using HW-acelerated GLES2 with an offscreen render target and copy it's contents to the x11 window (better performance than Mesa but still slow due to the copy ...)
• using that obscure videocore library (if I remember its name correctly ...) that comes with the raspberry pi to draw from GLES2 directly to the screen in a defined rectangle and change that rectangle according to changes to the x11 window (so far the fastest I have tested, but has issues due to always overdrawing x11 meaning the cursor is invisible without additional workarounds)
• using the new opensource OpenGL driver, haven't tested it myself yet, but if I remember correctly someone on the forum reported it to work, so my guess is this is probably the simplest and most compatible solution for raspberry pi

As you can see the x11 ARM platform will probably a nightmare to maintain because there is just way to many different buggy drivers and the need for hacky workarounds each with their own pros and cons ... and that's just the "get a window with 3D-content to work"-part after that you will probably run in other problems (for example on OpenPandora the NPOT extension of OpenGL is supported but still if you render to a offscreen target with non power of two dimensions and read from that texture you will only get black ...)

[silverkorn]

BTW, slightly dead but included: OUYA game console :stuck_out_tongue_winking_eye:

[Oneil974]

Hi,
I would try to compile for raspberry pi 2 again but when I will have more time. It takes a lot of time on pi 2
Maybe this week

[wkubiak]

For all it's worth, around a month ago I managed to compile and run Godot 2.1 on Odroid C2, which has a ARMv8 CPU ("aarch64" architecture, not "arm"). Most work I had to do was to add the architecture in detect.py for platform X11 and add some new lines of code in the reference counter classes, as they have different implementations in asm depending on the cpu arch.

Sadly, my work has been lost because it was done on a borrowed C2 unit and the SD card got corrupted or whatever when I asked my friend to retrieve that code. When I find the time I'll try to replicate what I did and make a PR request.

Still, the next stage after making Godot compile and run was to make a GLES context for the X11 platform as people before said in this issue thread, because when I run Godot on the C2 board it was utilizing software rendering via GLEW and it was running very slow because of this.

[Calinou]

Bugsquad note: This feature is still not implemented as of commit https://github.com/godotengine/godot/commit/4d787869e189b670d609f33c308991741592e40a.

Note that Godot 3.0 requires OpenGL ES 3.0 support, but Godot 3.1 will support OpenGL ES 2.0 again (which is important for this issue, since only a few ARM SBCs support OpenGL ES 3.0 as of April 2018).

[gururise]

Armv7h export targeting the most popular SBC (ie. Raspberry Pi) is probably all Godot needs to aim for. The number of Raspberry Pi's out there exceed all other SBC's combined and the Raspberry Pi is used in school around the world in an educational capacity.

[MrJustreborn]

Maybe this is interesting: https://github.com/efornara/frt

[slapin]

Almost all SBCs support GLES2 + Linux, so why just RPi?
On Wed, Oct 17, 2018 at 3:24 PM MrJustreborn [e-mail] wrote:
>

Maybe this is interesting: https://github.com/efornara/frt

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[slapin]

frt is just for 2.1

On Wed, Oct 17, 2018 at 3:24 PM MrJustreborn [e-mail]
wrote:

Maybe this is interesting: https://github.com/efornara/frt

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/5240#issuecomment-430606895,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAX0zDk_J6tZ3xQij14JU9DmaFrkUhGks5ulyF-gaJpZM4I28BY
.

[MrJustreborn]

frt is just for 2.1
…
On Wed, Oct 17, 2018 at 3:24 PM MrJustreborn @.*> wrote: Maybe this is interesting: https://github.com/efornara/frt — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5240 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAX0zDk_J6tZ3xQij14JU9DmaFrkUhGks5ulyF-gaJpZM4I28BY .

It has experimental support for Godot 3:
https://github.com/efornara/frt/blob/master/doc/Usage.md#godot-3

[sunnystormy]

You know, it would be great if there were a tutorial explaining how to create a custom backend for godot. I'd love to figure out how to export for Open-Source ISAs like RISC-V and OpenPower.

[vnen]

@sunnystormy you can request a tutorial on https://github.com/godotengine/godot-docs. Creating a new platform sums up to creating a new folder on the platform folder of Godot source, implementing the specific OS class and exporter, and setting up the proper build flags on detect.py and SCsub.

[sunnystormy]

@vnen Thank you for this! Just created a ticket here: https://github.com/godotengine/godot-docs/issues/3035.

[Calinou]

Closing in favor of #2671, since it's mostly a duplicate. The rest is already covered by https://github.com/godotengine/godot-docs/issues/3035.