Add official Raspberry Pi support

heniotierra commented 8 years ago

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 commented 8 years ago

Theme already has a cursor override doesn't it?

CheeryLee commented 8 years ago

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- commented 8 years ago

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 notifications@github.com 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 commented 8 years ago

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- commented 8 years ago

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

On 29 December 2015 at 20:58, heniotierra notifications@github.com 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 commented 8 years ago

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

x1212 commented 8 years ago

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 commented 8 years ago

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

MarianoGnu commented 8 years ago

you should add the cursor to the editor icons

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

x1212 commented 8 years ago

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 commented 8 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

zohozer commented 5 years ago

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 commented 5 years ago

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

starryalley commented 5 years ago

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.

mischiefaaron commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

NilsIrl commented 5 years ago

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.

realkotob commented 5 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

psstoyanov commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

ikostan commented 4 years ago

@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 commented 4 years ago

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

ikostan commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

Run: git clone --branch 3.2 https://github.com/godotengine/godot
Run: cd godot
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.

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

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 commented 4 years ago

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

Run: git clone https://github.com/godotengine/godot
Run: cd godot
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.

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 commented 4 years ago

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

ikostan commented 4 years ago

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

I've read the error message, thanks.

psstoyanov commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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.

godotengine / godot

Add official Raspberry Pi support #2671