Godot: Add official Raspberry Pi support

[heniotierra]

I know the Raspberry Pi and Raspberry Pi 2 are not officially supported, and that there is a working fork out there, but it has got some issues which make it close to worthless. However, I think that some of those problems might be easy to address.

For example, one of the big issues is that the mouse cursor is always under the interface objects, but I think that if one can make the mouse cursor be drawn by Godot's GUI in a similar way as the other interface objects, that would be enough for solving the problem. I guess that would be pretty easy to implement.

I don't know anything C++, only C (and also some OO languages), otherwise I could do that myself. But then, if someone can at least give me directions like where to begin to look at the source files to use the stuff to do this, I'd be glad, and very willing to try.

[MarianoGnu]

Theme already has a cursor override doesn't it?

[CheeryLee]

What do you mean? Raspberry Pi is just a computer without OS. You can install Linux or Android on the device and play your Godot project (Linux binary or APK respectively).

[punto-]

If there's a basic api to access the hardware (screen, input, sound,
filesystem), a port could just "boot" a godot game directly, like on old
consoles. It'd probably run faster, and also a pain in the ass to make :p
Games might need to be more careful about memory if there's no OS providing
virtual memory too (like on old consoles). Sounds like fun.

On 28 November 2015 at 18:06, Alexander Cheery [email protected]
wrote:

What do you mean? Raspberry Pi is just a computer without OS. You can
install _nix or Android on the device and play your Godot project (_nix
binary or APK respectively).

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/2671#issuecomment-160335505.

[heniotierra]

One of the issues is that the Raspberry Pi handles 3D stuff by drawing directly on the hardware (screen), not through X, while the mouse IS drawn thourgh X, making the mouse cursor not to be visible, for the interface (drawn with hardware acceleration?) is on top of it.

This specific issue is described on the working port fork: https://github.com/x1212/godot/issues/1

[punto-]

Did you try the "custom_mouse_cursor" option on project settings?

On 29 December 2015 at 20:58, heniotierra [email protected] wrote:

One of the issues is that the Raspberry Pi handles 3D stuff by drawing
directly on the hardware (screen), not through X, while the mouse IS drawn
thourgh X, making the mouse cursor not to be visible, for the interface
(drawn as 3D) is on top of it.

This specific issue is described on the working port repo: x1212#1
https://github.com/x1212/godot/issues/1

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/2671#issuecomment-167902145.

[heniotierra]

I did not, nor am I able to atm, but will do tomorrow. :)

[x1212]

Since I merged the latest changes into my fork yesterday it now supports the "custom_mouse_cursor" option, but that seems to only work in a running game, not in editor or when selecting a project from the list.
I did find a place in main.cpp, where I could try to add that option on startup, but the problem is, I didn't find any way to provide a path to for example /home/USERNAME/.godot/cursor.png (or ~/.godot/cursor.png), since that will be changed to res:///home/USERNAME/.godot/cursor.png (or res://~/.godot/cursor.png) by the resource loader and so on. That means it would need one cursor.png for every possible location res:// can point to.

Btw. if there are any plans for providing official support for the Raspberry Pi, the next few days would be a good time to have a look at the necessary changes (currently they can be found on the raspberry branch https://github.com/x1212/godot/tree/raspberry) since I should have enough spare time to help until the middle of next week.

[MarianoGnu]

you should be able to run a script with the keyword to change default cursor inside editor...

[MarianoGnu]

you should add the cursor to the editor icons

1. add cursor.png to Godot\tools\editor\icons
2. run make_icons.py
3. get the texture to set the custom cursor using this line:
   Ref cursor = get_icon("Cursor","EditorIcons");

[x1212]

Thanks, I got the cursor to work in the project manager that way, for some reason it didn't work for the editor, but in the editor scripts can be used, so that shouldn't be such a big problem anymore (but I'll try to fix it anyway).

[MarianoGnu]

@x1212 "I did find a place in main.cpp, where I could try to add that option on startup"
probably this line you mention runs only when the project manager is launching

[akien-mga]

AFAIK Godot builds out of the box on the Raspberry Pi, and from what I've seen seems to work just fine. What's missing to consider this issue solved? (cc @efornara)

[efornara]

To be honest, I rarely use godot platform=x11 tools=yes on the Raspberry Pi. My builds (FRT) use another code path (OpenGL ES 2.0) and the problems I get are more like the problems you would get on low-end android phones.

After enabling vc4 to get hardware accelerated desktop OpenGL, godot 2.1 compiled and worked out of the box last time I checked. I tried my branch (gles2, but master should be the same) something like 2/3 weeks ago, and I had two problems:

• There was an internal compiler error when compiling with the official raspbian/stretch compiler (gcc 6.3.0 on/targeting arm). Some macro in gdnative. I didn't bother to compile with clang. I just commented out the offending line.

• Godot crashed at startup on glGenerateMipmap (it's standard in OpenGL ES 2.0, but it's an extension in OpenGL 2.1). I think the glGenerateMipmap problem was mentioned already in an issue (not regarding the Raspberry Pi in particular). In any case, I reckon it's probably better to fix all these small issues in one go when the whole GLES2 renderer is almost complete.

[efornara]

I have compiled godot 3.1-beta1 on a stock raspbian stretch (gcc 6.3) using:

scons platform=x11 target=release_debug tools=yes CCFLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mlittle-endian -munaligned-access" -j 4

I get this error:

modules/gdnative/gdnative/variant.cpp: In function 'godot_variant godot_variant_call(godot_variant*, const godot_string*, const godot_variant**, godot_int, godot_variant_call_error*)':
modules/gdnative/gdnative/variant.cpp:40:81: internal compiler error: in assign_temp, at function.c:961
 #define memnew_placement_custom(m_placement, m_class, m_constr) _post_initialize(new (m_placement, sizeof(m_class), "") m_constr)
                                                                 ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
modules/gdnative/gdnative/variant.cpp:449:2: note: in expansion of macro 'memnew_placement_custom'
  memnew_placement_custom(dest, Variant, Variant(self->call(*method, args, p_argcount, error)));
  ^~~~~~~~~~~~~~~~~~~~~~~
Please submit a full bug report,

Commenting out the line is enough to generate a working executable using gcc (of course, I haven't tested gdnative), so this seems to be the only problem.

I had no issues compiling with use_llvm=yes (clang 4.0), so I have used it to compile both godot 3.1-beta1 and 2.1.5-stable.

Here are my first impressions on a Raspberry Pi 3B+ using the experimental OpenGL driver. Not what we might want to hear, but here they are.

The 3.1-beta1 editor runs but it is not really useable. I have loaded the 2D platformer and interaction is very slow. Even the code editor lags a couple of seconds when typing a character. Anyone wants to try with lto (and maybe overclocking)?

The 2.1.5-stable editor is actually quite useable. Panning, selecting and code editing the 2D platformer all work reasonably well. Not a speed demon, but no major lags either: I could see someone writing a game on it.

Note that I am talking about the editor here. The export templates are another matter. I expect to be able to test them soon, but my experience with the 2D platformer on 3.0-gles2 suggests that 3.1-beta1 should be slower than 2.1.5-stable, but still useable.

For the record, here are the compilation times using clang 4.0 on a non-overclocked Raspberry Pi 3B+ running without GUI, with the operating system on a MicroSD card and the godot directory (and swap partition) on an external hard disk:

2.1.5-stable: 47m
3.1-beta1: 82m

[akien-mga]

Commenting out the line is enough to generate a working executable using gcc (of course, I haven't tested gdnative), so this seems to be the only problem.

That's an upstream bug in GCC 6 & 7, that was later fixed in GCC 8.1: see #16100 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085.
You can work it around with this patch: http://svnweb.mageia.org/packages/cauldron/godot/current/SOURCES/godot-3.0.2-workaround-gcc-ice-armv7hl.patch?view=markup

[efornara]

I do see a significant performance regression. On the plus side, the poor performance I was seeing on the editor might be related.

On the 2D platformer on the Raspberry Pi 3B+, I get 60fps on 3.0.6-gles2 (basically 3.0.6-stable with the 2D-only GLES2 code that was initially merged on master), and I get 1fps (legacy driver) and 5fps (new driver) on 3.1-beta1.

I might be doing something stupid, so please let me know if anyone else can reproduce the problem. I am using my own platform (FRT), so there is a chance it might be a problem on my end. I'll try the standard X11 export templates later, but, since I am not doing anything crazy in my platform, I wouldn't bet on this being the problem.

I attach the projects I use. Basically, I downloaded the demo from the asset store and exported it as a Linux ZIP on godot-3.0.6-stable. I then imported the demo on godot 3.1-beta1, changed the renderer to GLES2, and exported it as another Linux ZIP.

30_2d_platformer.zip
31_2d_platformer.zip

If this helps, I get these errors on godot 3.0.6-gles2:

ERROR: ContextGL: Condition ' singleton ' is true.
   At: drivers/gl_context/context_gl.cpp:44.
ERROR: ContextGL: Condition ' singleton ' is true.
   At: drivers/gl_context/context_gl.cpp:44.
ERROR: PhysicsServer: Condition ' singleton != __null ' is true.
   At: servers/physics_server.cpp:738.
ERROR: ~List: Condition ' _first != __null ' is true.
   At: core/self_list.h:100.
WARNING: cleanup: ObjectDB Instances still exist!
   At: core/object.cpp:1989.
ERROR: clear: Resources Still in use at Exit!
   At: core/resource.cpp:418.
OpenGL ES 2.0 Renderer: VideoCore IV HW
WARNING: not found: physics/2d/thread_model

and these errors on godot 3.1-beta1:

ERROR: ContextGL: Condition ' singleton ' is true.
   At: drivers/gl_context/context_gl.cpp:44.
ERROR: ContextGL: Condition ' singleton ' is true.
   At: drivers/gl_context/context_gl.cpp:44.
ERROR: initialize: Directional shadow framebuffer status invalid
   At: drivers/gles2/rasterizer_scene_gles2.cpp:3178.
WARNING: _get: Property not found: physics/2d/thread_model
   At: core/project_settings.cpp:193.
ERROR: PhysicsServer: Condition ' singleton != __null ' is true.
   At: servers/physics_server.cpp:724.
ERROR: free_custom_shader: Condition ' !custom_code_map.has(p_code_id) ' is true.
   At: drivers/gles2/shader_gles2.cpp:681.
ERROR: free_custom_shader: Condition ' !custom_code_map.has(p_code_id) ' is true.
   At: drivers/gles2/shader_gles2.cpp:681.

[efornara]

Same result on 3.1-beta1 / x11: 5fps.

I couldn't test 3.0.6-gles2 / x11 because it crashes. I suspect old code not handling the glGenerateMipmap extension properly. In any case, I am now more confident in saying that x11 vs frt doesn't matter.

Still, I might be doing something wrong, so it would be nice if anyone else could confirm.

Just compile with something like this:

scons platform=x11 target=release tools=no use_llvm=yes CCFLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mlittle-endian -munaligned-access" -j 4

And then run it with something like this:

godot.x11.opt.32.llvm --main-pack 31_2d_platformer.zip --print-fps

The difference (using frt) between new and legacy drivers (5fps and 1fps) suggests that this is more likely GPU related rather than CPU related.

[akien-mga]

Keep in mind that you're comparing two quite different GLES2 backends. The one you merged in 3.0 in your fork was the very early backend with the most simple rendering features supported. The one in 3.1 supported 3D PBR, and many advanced 2D rendering features.

Disabling some features in your project settings might help reduce this gap. Some of it will stay as overhead in any case.

[akien-mga]

One other potential cause might be #24466. You could try to revert the commit mentioned there to see if it does a big difference on such hardware/drivers.

[efornara]

I didn't revert the commit mentioned ( https://github.com/godotengine/godot/commit/bec76cfa19684cbfce3677044331805fd2a54d8b ) because I had a conflict, but I did checkout the previous commit ( https://github.com/godotengine/godot/commit/e57709396537807c55ce05352137fde8c6a510f4 ) and now I get 60fps again.

[rilpires]

Is the server build able to run in a raspberry, since it doesn't render anything and stuff ??? Has anyone tried it ?

[zohozer]

Just a heads up.

Raspberry Pi 4 has just released and according to this site, seems that do have support for OpenGL ES 3.0

Will make this easier to do a proper port of the Godot engine to Raspberry?

[starryalley]

Yeah I plan to buy a RPi4 to run godot 3.1 as well.

[starryalley]

I just ran godot 3.1.1 on a 2GB RPi4 using OpenGL ES2 without problem, using similar compile command mentioned above. Running a small 4k resolution 2D project works perfectly smooth on a 1080p screen. Godot editor is still usable as well despite of it being a little bit slow.

[agameraaron]

OGLES2 support in 3.1.1 runs significantly slower than OGLES3 for my game probably due to the tileset performance issues. If the next version of Godot does not improve performance enough in the OGLES2 renderer then I will at least have the option of getting a Raspberry Pi 4 & using OGLES3 for my demonstration/booth hardware.

[NilsIrl]

If there's a basic api to access the hardware (screen, input, sound,
filesystem), a port could just "boot" a godot game directly, like on old
consoles. It'd probably run faster, and also a pain in the ass to make :p
Games might need to be more careful about memory if there's no OS providing
virtual memory too (like on old consoles). Sounds like fun.

So you're proposing to turn Godot into an OS?

[daveyman123]

Is godot on the raspberry pi a thing? what about interacting with GPIO?

[NilsIrl]

Is godot on the raspberry pi a thing? what about interacting with GPIO?

I don't think that is supported but it should work using GDNative.

[asheraryam]

It seems it works with pi 4 which has gles 3, but what about the pi 3B+ ?
Is there a working compile command with the master branch?

[hiulit]

@daveyman123 @NilsIrl @asheraryam Take a look at https://github.com/efornara/frt.
It's a Godot "platform" targeting single board computers.
It has its limitations, of course, but I've tested it on a RPI 3B+ with a GLES2 2D game I'm working on and it works fine.
And about interacting with GPIO, check out https://github.com/efornara/frt/issues/4. I've tested it with some arcade buttons attached to the GPIO using GPIOnext (to map the GPIO to a virtual keyboard) and it's working as well.
I'm using FRT on a project of my own, a Godot "emulator" for RetroPie https://github.com/hiulit/RetroPie-Godot-Game-Engine-Emulator ;)

[sunjam]

Found this thread while searching for whether Godot supports the Arm64 Pinebook Pro laptop. Apologies that it is not directly Pi related.

GPU stats:
ARM Mali-T860MP4 Quad-core GPU The highest performance GPUs built on Arm Mali’s famous Midgard architecture, the Mali-T860 GPU is designed for complex graphics use cases and provide stunning visuals for UHD content. Frequency 650MHz Throughput 1300Mtri/s, 10.4Gpix/s OpenGL® ES 1.1, 1.2, 2.0, 3.1, 3.2., Vulkan 1.0*., OpenCL™ 1.1, 1.2., DirectX® 11 FL11_1., RenderScript™.

[sdwfrost]

I tried compiling 3.2.1 on a Pinebook Pro, based on the Pi instructions here

scons platform=x11 target=release_debug tools=yes use_llvm=yes CCFLAGS="-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard -mlittle-endian -munaligned-access" -j 4

However, when I run, I get the following error:

LIBGL: Initialising gl4es
LIBGL: v1.1.1 built on Mar 10 2019 13:15:04
LIBGL: Using GLES 2.0 backend
LIBGL: loaded: libbrcmGLESv2.so
LIBGL: loaded: libbrcmEGL.so
LIBGL: Using GLES 2.0 backend
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer detected
LIBGL: Extension GL_OES_element_index_uint detected and used
LIBGL: Extension GL_OES_packed_depth_stencil detected and used
LIBGL: Extension GL_OES_depth24 detected and used
LIBGL: Extension GL_OES_rgb8_rgba8 detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_depth_texture detected and used
LIBGL: Extension GL_OES_texture_stencil8 detected and used
LIBGL: Extension GL_EXT_texture_rg detected and used
LIBGL: Extension GL_EXT_color_buffer_float detected and used
LIBGL: Extension GL_EXT_color_buffer_half_float detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Max vertex attrib: 16
LIBGL: Extension GL_OES_standard_derivatives detected and used
LIBGL: Max texture size: 8192
LIBGL: Max Varying Vector: 15
LIBGL: Texture Units: 8(8), Max lights: 8, Max planes: 6
LIBGL: Hardware vendor is ARM
LIBGL: sRGB surface supported
LIBGL: Targeting OpenGL 2.0
LIBGL: glXMakeCurrent FBO workaround enabled
LIBGL: FBO workaround for using binded texture enabled
LIBGL: glX Will try to recycle EGL Surface
LIBGL: Current folder is:/home/simon/Programs/godot/bin
Godot Engine v3.2.1.stable.custom_build.b0eca5828 - https://godotengine.org
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /lib/arm-linux-gnueabihf/libc.so.6(+0x24fd0) [0xf6bfffd0] (??:0)
[1] /lib/arm-linux-gnueabihf/libc.so.6(+0x24fd0) [0xf6bfffd0] (??:0)
-- END OF BACKTRACE --
Aborted
simon@Debian-Desktop:~/Programs/godot/bin$ [2] /lib/arm-linux-gnueabihf/libpthread.so.0(pthread_join+0x9) [0xf6e8f48e] (??:0)
-- END OF BACKTRACE --

[clayjohn]

@sdwfrost can you try compiling with "debug" instead of "release_debug" that way the backtrace will include better info.

[psstoyanov]

@sdwfrost , looks like you are using mrfixit's Debian image (it's the only one that comes with gl4es enabled globally by default). This Debian image and ayufan's Ubuntu images are using armhf userland - 32bit one. I haven't tried to get the Godot editor working there for a very long time

If you are on Manjaro or one of the other distros targeting aarch64, then you can use:
scons platform=x11 target=release_debug tools=yes use_llvm=false CCFLAGS="-march=armv8-a+crc+crypto -mcpu=cortex-a72.cortex-a53" -j6
Manjaro with Panfrost gets Godot with ES2 working well imho. Not ground breaking but certainly useable

llvm can't optimize for both the big and small cores (you will have to choose either the a72 or a53)

[akien-mga]

We're in the process of moving feature proposals to godot-proposals.

Would anyone interested in Raspberry Pi support in Godot be willing to open a new issue there following the proposals issue template, and summarize the key takeaways from the discussion here? (Current forks that implement support, what's needed to have things working out of the box in the core engine, etc.)

[KoBeWi]

Someone created a new proposal, so this can be closed.
https://github.com/godotengine/godot-proposals/issues/988

[ikostan]

@sdwfrost , looks like you are using mrfixit's Debian image (it's the only one that comes with gl4es enabled globally by default). This Debian image and ayufan's Ubuntu images are using armhf userland - 32bit one. I haven't tried to get the Godot editor working there for a very long time

If you are on Manjaro or one of the other distros targeting aarch64, then you can use:
scons platform=x11 target=release_debug tools=yes use_llvm=false CCFLAGS="-march=armv8-a+crc+crypto -mcpu=cortex-a72.cortex-a53" -j6
Manjaro with Panfrost gets Godot with ES2 working well imho. Not ground breaking but certainly useable

llvm can't optimize for both the big and small cores (you will have to choose either the a72 or a53)

HI @psstoyanov, may be you can help me with this one. I tried to compile it on Manjaro ARM and the process failed, see error below:

`
[Initial build] Compiling ==> modules/enet/networked_multiplayer_enet.cpp

[Initial build] Compiling ==> modules/enet/register_types.cpp

[Initial build] Compiling ==> thirdparty/oidn/core/api.cpp

[Initial build] In file included from thirdparty/oidn/core/common.h:19,
from thirdparty/oidn/core/device.h:19,
from thirdparty/oidn/core/api.cpp:48:
thirdparty/oidn/common/platform.h:27:10: fatal error: xmmintrin.h: No such file or directory
27 | #include
| ^~~~~
compilation terminated.
scons: * [thirdparty/oidn/core/api.linuxbsd.opt.tools.64.o] Error 1
Compiling ==> thirdparty/oidn/core/device.cpp
In file included from thirdparty/oidn/core/common.h:19,
from thirdparty/oidn/core/device.h:19,
from thirdparty/oidn/core/device.cpp:17:
thirdparty/oidn/common/platform.h:27:10: fatal error: xmmintrin.h: No such file or directory
27 | #include
| ^~~~~
compilation terminated.

scons: * [thirdparty/oidn/core/device.linuxbsd.opt.tools.64.o] Error 1

scons: building terminated because of errors.
`

[psstoyanov]

@ikostan , which branch are you using? I will try to replicate this tonight

[ikostan]

@ikostan , which branch are you using? I will try to replicate this tonight

I used git clone https://github.com/godotengine/godot command, so I assume it is a main one.

[psstoyanov]

@ikostan , which branch are you using? I will try to replicate this tonight

I used git clone https://github.com/godotengine/godot command, so I assume it is a main one.

I haven't tried master in awhile, will give it a go in a few hours. Could be worth it to open a ticket for this specific error.

For now, I have found the following setup to provide the best results:

• in the godot directory switch to 3.2 branch
• use mesa-git package (instead of mesa) in your Manjaro install
• enable the experimental PAN_MESA_DEBUG=gl3 flag in your environment (you will see why in a bit)

master has already merged the changes for Vulkan which removed es3.

With 3.2, you will see the editor becoming smoother in ES3 mode, however for that you need to be able to get GL3 context (hence the experimental gl3 flag for Panfrost). ES2 runs well when you play the game but the editor isn't very smooth (haven't figured out why). There are other reasons why you would like ES3 instead of ES2 - GPU accelerated particles for example.

Panfrost devs are moving fast - when they get to Vulkan, I bet Godot will run even better.

[psstoyanov]

@ikostan , I receive the same error as the one you got. Opening a ticket for it, could be good.

Apart from the error, I have missed the following commit: https://github.com/godotengine/godot/commit/525c40a488c07ac072469cf9a694de77672d27bc

The OpenGL ES2 backend is being refactored and disabled for now on master.

For now, stick with 3.1 or 3.2 branches until master merges the revamped es2 or Panfrost devs do their magic for Vulkan :smiley:

[ikostan]

@ikostan , I receive the same error as the one you got. Opening a ticket for it, could be good.

Apart from the error, I have missed the following commit: 525c40a

The OpenGL ES2 backend is being refactored and disabled for now on master.

For now, stick with 3.1 or 3.2 branches until master merges the revamped es2 or Panfrost devs do their magic for Vulkan 😃

Tanks @psstoyanov. Not sure about opening a ticket since Raspberry Pi is not officially supported. Trying to compile 3.2...

[psstoyanov]

@ikostan , further investigation and what I've missed from the changes with 4.x+

This is very interesting: https://github.com/godotengine/godot/blob/ba7738a3b264bfbe999631449c1d2daaaa5212f2/SConstruct#L111 Seems like we can target specific arch for several months now.

Targeting scons platform=linuxbsd arch=arm64 target=release_debug tools=yes use_llvm=false CCFLAGS="-march=armv8-a+crc+crypto -mcpu=cortex-a72.cortex-a53" -j6 produces the editor executable from the master branch!

It goes around the x86 specific error with xmmintrin.h (most likely linuxbsd platform assumes x86 arch :smile: similar to how 3.2 assumes es3 requires GL3 context for X11 :wink: )

Of course, the resulting build can't run on PBP running Panfrost (still no Vulkan for Panfrost or refactored es2 for Godot). BUT it is generated and can be launched on the Pinebook Pro running Manjaro.

Now with this newfound knowledge, I'm really interested to check if I can finally produce an executable that will run on mrfixit's Debian build that is running 32bit userland :smiley: Already started the compile :crossed_fingers:

[Update]: No, targeting arm architecture routes through x86 setup leaving the same error: fatal error: xmmintrin.h: No such file or directory.
arm64 works and that is enough for now I guess.

If someone has an idea how to get arm or armv7 build of the editor, please share :)

[ikostan]

@ikostan , I receive the same error as the one you got. Opening a ticket for it, could be good.

Apart from the error, I have missed the following commit: 525c40a

The OpenGL ES2 backend is being refactored and disabled for now on master.

For now, stick with 3.1 or 3.2 branches until master merges the revamped es2 or Panfrost devs do their magic for Vulkan smiley

This is what I did:

1. Run: git clone --branch 3.2 https://github.com/godotengine/godot
2. Run: cd godot
3. Run: scons platform=x11 target=release_debug tools=yes use_llvm=false CCFLAGS="-march=armv8-a+crc+crypto -mcpu=cortex-a72" -j6

and as a result I got this output:

scons: Reading SConscript files ...
Enabling ALSA
Enabling PulseAudio
Checking for C header file mntent.h... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
[ 5%] Linking Static Library ==> main/libmain.x11.opt.tools.64.a
[ 5%] Ranlib Library ==> main/libmain.x11.opt.tools.64.a
[100%] progress_finish(["progress_finish"], [])
[100%] Linking Program ==> bin/godot.x11.opt.tools.64
[100%] scons: done building targets.

1. Run: sudo bin/godot.x11.opt.tools.64

as a result I got following output:

Godot Engine v3.2.3.rc.custom_build.c5abc57f8 - https://godotengine.org
:point_right: X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 28
Current serial number in output stream: 25
:point_right: X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 28
Current serial number in output stream: 25
:point_right: ERROR: initialize: Condition "ctxErrorOccurred || !p->glx_context" is true. Returned: ERR_UNCONFIGURED
At: platform/x11/context_gl_x11.cpp:190.
OpenGL ES 2.0 Renderer: V3D 4.2
OpenGL ES 2.0 Batching: ON

Godot GUI client is opened as well

1. For the test purposes I imported following pong project. It is a 2D game and it seems running well. However, I can still see a few errors in the console when I am trying to run the Godot engine, see logs above (step 4)

Now I will try to compile the latest Godot engine... Thanks @psstoyanov for helping me.

[ikostan]

@ikostan , further investigation and what I've missed from the changes with 4.x+

This is very interesting:

https://github.com/godotengine/godot/blob/ba7738a3b264bfbe999631449c1d2daaaa5212f2/SConstruct#L111
Seems like we can target specific arch for several months now.

Targeting scons platform=linuxbsd arch=arm64 target=release_debug tools=yes use_llvm=false CCFLAGS="-march=armv8-a+crc+crypto -mcpu=cortex-a72.cortex-a53" -j6 produces the editor executable from the master branch!

It goes around the x86 specific error with xmmintrin.h (most likely linuxbsd platform assumes x86 arch smile similar to how 3.2 assumes es3 requires GL3 context for X11 wink )

Of course, the resulting build can't run on PBP running Panfrost (still no Vulkan for Panfrost or refactored es2 for Godot). BUT it is generated and can be launched on the Pinebook Pro running Manjaro.

Now with this newfound knowledge, I'm really interested to check if I can finally produce an executable that will run on mrfixit's Debian build that is running 32bit userland smiley Already started the compile crossed_fingers

[Update]: No, targeting arm architecture routes through x86 setup leaving the same error: fatal error: xmmintrin.h: No such file or directory.
arm64 works and that is enough for now I guess.

If someone has an idea how to get arm or armv7 build of the editor, please share :)

This is the procedure I followed:

1. Run: git clone https://github.com/godotengine/godot
2. Run: cd godot
3. Run: scons platform=linuxbsd arch=arm64 target=release_debug tools=yes use_llvm=false CCFLAGS="-march=armv8-a+crc+crypto -mcpu=cortex-a72.cortex-a53" -j6, got this output:

[Initial build] progress_finish(["progress_finish"], [])
[Initial build] Linking Static Library ==> modules/freetype/libfreetype_builtin.linuxbsd.opt.tools.arm64.a
[Initial build] Ranlib Library ==> modules/freetype/libfreetype_builtin.linuxbsd.opt.tools.arm64.a
[Initial build] Linking Static Library ==> core/libcore.linuxbsd.opt.tools.arm64.a
Ranlib Library ==> core/libcore.linuxbsd.opt.tools.arm64.a
[Initial build] Linking Program ==> bin/godot.linuxbsd.opt.tools.arm64
[Initial build] scons: done building targets.

1. Run: sudo bin/godot.linuxbsd.opt.tools.arm64, got following console output:

Godot Engine v4.0.dev.custom_build.443686d72 - https://godotengine.org
ERROR: No surface extension found, is a driver installed?
at: _initialize_extensions (drivers/vulkan/vulkan_context.cpp:268)
ERROR: Could not initialize Vulkan
at: DisplayServerX11 (platform/linuxbsd/display_server_x11.cpp:3482)
Warning: Missing charsets in String to FontSet conversion

screenshot with Godot error message also attached:

So unfortunately the procedure does not work for the master branch

[Zireael07]

@ikostan: It can't work for master because master is Vulkan-only

[ikostan]

@ikostan: It can't work for master because master is Vulkan-only

I've read the error message, thanks.

[psstoyanov]

@ikostan , I can see that on your system it is using V3D. While you said you are on Manjaro ARM, you didn't specify which board you are using.

I know for sure there are experimental Vulkan drivers for the RPi3 and RPi4. Try to find more about them (I think v3dv was the RPi4 specific one - some assembly may be required :smile: ).

I don't have a Pi at home nor do I follow it's GPU driver progress as closely as I do for the PinebookPro with Panfrost. However the same principles apply:

• Godot's master currently doesn't have es2 backend (follow the blog and updates for that one)
• With Godot master your system needs to have enabled Vulkan support (check v3dv for RPi - keep in mind it's experimental)
• 3.1 and 3.2 work with both es2 and es3
• For es3 on Linux, Godot 3.x assumes your system has to support GL3 (no idea what's the state for the Pi there)

[ikostan]

@ikostan , I receive the same error as the one you got. Opening a ticket for it, could be good.
Apart from the error, I have missed the following commit: 525c40a
The OpenGL ES2 backend is being refactored and disabled for now on master.
For now, stick with 3.1 or 3.2 branches until master merges the revamped es2 or Panfrost devs do their magic for Vulkan smiley

This is what I did:

1. Run: `git clone --branch 3.2 https://github.com/godotengine/godot`

2. Run: `cd godot`

3. Run: `scons platform=x11 target=release_debug tools=yes use_llvm=false CCFLAGS="-march=armv8-a+crc+crypto -mcpu=cortex-a72" -j6`

and as a result I got this output:

scons: Reading SConscript files ...
Enabling ALSA
Enabling PulseAudio
Checking for C header file mntent.h... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
[ 5%] Linking Static Library ==> main/libmain.x11.opt.tools.64.a
[ 5%] Ranlib Library ==> main/libmain.x11.opt.tools.64.a
[100%] progress_finish(["progress_finish"], [])
[100%] Linking Program ==> bin/godot.x11.opt.tools.64
[100%] scons: done building targets.

1. Run: `sudo bin/godot.x11.opt.tools.64`

as a result I got following output:

Godot Engine v3.2.3.rc.custom_build.c5abc57f8 - https://godotengine.org
point_right X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 28
Current serial number in output stream: 25
point_right X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 28
Current serial number in output stream: 25
point_right ERROR: initialize: Condition "ctxErrorOccurred || !p->glx_context" is true. Returned: ERR_UNCONFIGURED
At: platform/x11/context_gl_x11.cpp:190.
OpenGL ES 2.0 Renderer: V3D 4.2
OpenGL ES 2.0 Batching: ON

Godot GUI client is opened as well

1. For the test purposes I imported following [pong](https://github.com/godotengine/godot-demo-projects/tree/master/2d/pong) project. It is a 2D game and it seems running well. However, I can still see a few errors in the console when I am trying to run the Godot engine, see logs above (step 4)

Now I will try to compile the latest Godot engine... Thanks @psstoyanov for helping me.

Actually I still have a problem. When I tried to develop 2D game of my own I got an error on my first attempt to play it:

So I get right back to where I started. i mean, I wanted to compile the Godot engine in order to solve that error in the first place...

[psstoyanov]

@ikostan , most likely you haven't adjusted the project settings to enforce es2. By default, the projects are going for ES3 quality.

Go to Project -> Project Settings -> Rendering -> Quality and either set it to GLES2 or use the fallback to es2 option.
This will allow to develop and play the game in the editor.

Now for actual release of the game on the RPi you will also have to create the export templates - https://docs.godotengine.org/en/stable/development/compiling/compiling_for_x11.html#building-export-templates . As you are already familiar with compiling the godot engine from source, the steps to compile the export temple (to get the final executable) are similar.

I haven't bothered with the export template just yet but I don't believe it will cause any issues.

[ikostan]

@ikostan , most likely you haven't adjusted the project settings to enforce es2. By default, the projects are going for ES3 quality.

Go to Project -> Project Settings -> Rendering -> Quality and either set it to GLES2 or use the fallback to es2 option.
This will allow to develop and play the game in the editor.

Now for actual release of the game on the RPi you will also have to create the export templates - https://docs.godotengine.org/en/stable/development/compiling/compiling_for_x11.html#building-export-templates . As you are already familiar with compiling the godot engine from source, the steps to compile the export temple (to get the final executable) are similar.

I haven't bothered with the export template just yet but I don't believe it will cause any issues.

Thanks, it seems to be working now.