Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tuning x11-64 platform for aarch64 and pyhton3.9 #302

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jfrey-xx
Copy link

Hello,

First of all, thank you for this project, this is amazing that we can run Python scripts within Godot. I only scratched the surface but it already open many doors, not only for the language per se, but because there tons of libraries that can be now be employed alongside the game engine.

Some weeks ago I tried to run godot-python on Raspberry Pi (Raspberry Pi OS / Debian Buster). It failed because this is not something that is planned in current code, and because aarch64 was only recently added to the underlying python-build-standalone (and it is still a work in progress).

After some time hacking my way through the code, I managed nonetheless to make it work. I added some instructions in the README, the broader picture is detailed in a tutorial here https://labs.ullo.fr/tutorials/python-and-godot-engine-on-a-raspberry-pi-displaying-physiological-signals-with-lsl/ Note that only python 3.9, not 3.8, is supported by python-build-standalone for aarch64. It did not seem to be an issue but I did not test thoroughly every feature of godot-python.

This pull request is not to be merged as is, because I went fast and simply replaced the existing x11-64 platform. Now, others might be interested in running and Godot and Python on a Raspberry (or on other aarch64 linux systems). What would be the best way to integrate those changes? Create a dedicated platform, e.g. x11-64-arm (maybe with an "-experimental" flag)?

@touilleMan touilleMan marked this pull request as draft June 22, 2021 07:03
@touilleMan
Copy link
Owner

Wow this is really cool !

This pull request is not to be merged as is,

I've converted the PR as draft to reflect this

but because there tons of libraries that can be now be employed alongside the game engine.

Yes, that's the main selling point for using Python instead of GDscript ^^
I don't much about Python ecosystem on Raspberry, is it easy to pip install binary dependencies ?

the broader picture is detailed in a tutorial here

This is a really nice tutorial, do you mind if I add it to the README ? (it could help people trying to use pip on top of using raspberry)

What would be the best way to integrate those changes? Create a dedicated platform, e.g. x11-64-arm (maybe with an "-experimental" flag)?

Adding a new platform seems like the way to go.

However I'm not sure how we could test the platform on the CI. Maybe we could use an emulator, but given Raspberry support for Godot is not official, we may endup with fragile code (especially when Godot 4 will be released) and I won't have any experience to support this.

I think the simplest thing to do would be to add the platform, but with no guarantees whatsoever (so no CI is run against it, people using Raspberry could submit PR to fix issues but no effort would be done to check for changes compatibility)

Another solution would be for you (or anybody interested in supporting Raspberry) to fork Godot-Python and add the new platform from there (typically using git subtree to simplify synchronization with the upstream Godot-Python).

Again, Godot 4 brings a complete breakage of the GDNative API so I can't guarantee how much the Godot-Python codebase will change to support this (in theory the platform stuff should not change that much given it's mostly the interface with Godot that is modified, but who knows ! ^^).

@jfrey-xx
Copy link
Author

It is as easy to install libraries on Raspberry as everywhere else, it is just that sometimes in pip the versions on ARM lag behind other platforms, and it happened to me a couple times that I had to compile some bits by hand because maintainers did not anticipate that their package could be installed on such CPU.

Concerning the tutorial it would be my honor to appear in the README ;)

I did not follow Godot development -- truth to be told I am very new at Godot -- I had no idea GDNative could break, finger crossed then!

As you say the whole port is at an early stage, it makes sense to leave it aside from the "official" releases, especially if it is difficult to do cross-compilation (I am not even sure we could automate the retrieval of linux aarch64 builds from python-build-standalone at this stage).

I would not have enough spare time to maintain a fork, but I can try to work on the pull request to create this dedicate platform :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants