Hey everyone. Just curious if anyone has tried building a game with Godot 3. There is a project which adds the rpi as an export target. https://github.com/efornara/frt
I’ve been tinkering with Godot for years now and it’d be fun to see my projects running on this handheld.
Would love to see Godot able to export to the GameShell, in fact, it’s the only thing missing for now that keeps me from buying it.
Hobby game dev here. I just ordered a GameShell and have been working on porting a game project of mine from iOS/Swift/SpriteKit to Godot 3.0 and really want to make a build to the GameShell.
Since I don’t yet have the hardware (and to help with the dev environment) I’m spinning up a VM in qemu for a Raspbian/Raspberry Pi 3 to test some things out. ARM based systems’ VM’s don’t work as well on Virtual Box, Hyper-V or other Hypervisors.
Thanks ugly_cat, I’m going to try that and if it works well I may post some tutorials and resources online.
Be sure to post any updates!
I primarily use Love2d but looking to get into Godot for some 3d stuff, so looking forward to seeing how you get on!
With the upcoming version 3.1 you should have more chances to make it work on the GameShell as it supports OpenGL ES 2.0. There are 3.1 alpha builds available on the Godot website if you want to try.
I was experimenting with my Pocket CHIP which is also an AllWinner single board computer, different CPU though (Quad Cortex A8).
I was able to get one of my games running with frt. It’s not an export template like I thought, but a binary used to run Godot projects. I did have a 3D model inside of my 2d project which didn’t render correctly. I think that can be fixed though.
Quick update:
I read elsewhere on these forums that while the clockworkos image is easily downloadable, the linux kernel is not necessarily readily available. That’s holding up my qemu vm creation of a virtualized clockworkpi game shell. I may end up waiting until my hardware is delivered to continue working on that angle. I was able to run various VM’s in qemu of RPi 3 - just not the specific one for the Game Shell. They may be close enough to get something working, but I’m not really interested in spending time on that now.
For now it looks like the most straight-forward method for doing this is installing godot engine and gcc or scons and compiling on the device itself.
I’m a bit hesitant to take time away from developing my game at this point because I’d like to have hardware in hand and Godot 3.1 might be a nice solution to many problems that I have. On that note - no official word on Godot Engine 3.1 release date yet but they’re wrapping up the alpha and appear to be heading into beta testing. That seems to mean that 3.1 is feature-complete but in need of bug testing and fixes and they show on github an 87% completion: Godot Engine milestone 7 (v 3.1) features/preliminary-changelist here: Godot Engine 3.1 changelog
Just got my gameshell today. I was able to get games working through FRT, but none of them registered any input. Anyone have any ideas as to why?
Note: Of course none of the 3D stuff using GLES3 worked.
Looking pretty hopeful for Godot.
I got mine yesterday and have been enjoying building and tinkering with it.
@ugly_cat What version of the OS and what graphics drivers are you running? I’m on clockworkos 0.3 (I think) with the lima driver, though I’ve also tried fbturbo. I keep getting this error:
cpi@clockworkpi:$ frt_093_215_arm7hf.bin -v
ERROR: ContextGL: Condition ’ singleton ’ is true.
At: drivers/gl_context/context_gl.cpp:43.
ERROR: ContextGL: Condition ’ singleton ’ is true.
At: drivers/gl_context/context_gl.cpp:43.
libEGL warning: DRI3: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
frt: eglInitialize failed.
I think I’m missing a package or driver, got any ideas on how to solve that? If I can figure that out I’ll see about the input issue.
So I went back over what you said @ugly_cat and was able to figure things out and get one of the demos to run on my GameShell tonight, woohoo!
Process this time around:
(On ClockworkOS version 0.24)
On the ClockworkPi GameShell via ssh:
I’ve made a download folder to work with these files and cd into it, you can put them anywhere you want.
Please note the version number used in the frt, as that’s important to get this to work. The first part 093 is the frt version, which is the latest as of writing this post, 215 is Godot Engine 2.1.5, which is the latest stable OpenGL ES2.0 compatible release, finally arm7hf signifies the GameShell’s CPU instruction set.
$ wget Download frt_093_215_arm7hf.bin.zip (FRT)
$ mv download frt_093_215_arm7hf.bin.zip
$ unzip frt_093_215_arm7hf.bin.zip
$ sudo install frt_093_215_arm7hf.bin /usr/local/bin
Since the unmodified sample project doesn’t at all account for running on Clockworkpi, it’s best to download it first to your desktop PC (this can be a laptop or Mac, I just mean a desktop OS). You’ll also need to pick up the Godot Engine 2.15 from here: Godot Engine 2.1.5
Download the demo projects here: Godot Demos 2.1.5 and unzip those on your PC.
Next Open Godot Engine (Make sure it’s 2.1.5 if you have multiple versions installed on your machine) then import the Demos/2D/Platformer project. Go to Scene and Project Settings under Sections, select Display and be sure to set the Width = 320 and Height = 240. For good measure I’ve toggled off the Resizeable and toggled on Fullscreen.
Results: Success (Or something closer)
As with @ugly_cat, I was unable to get input to work yet through the GameShell itself. I was however able to send input without too much delay from my VNC connection and everything seems to work right. I highly suggest using VNC until we get the button input working because there’s no way to exit other than VNC using the FRT command Win+Q or finding the process on ssh with ps aux | grep frt and killing it.
Okay, so this is crazy, after all that I’m actually able to use the buttons that are mapped out correctly on my GameShell. All I have to do is make sure the shoot button is mapped out correctly now and I’ll have the demo fully functional. FTW!
A bit more testing and I know what causes the input to suddenly start working though I don’t know why. The way to activate input is to left click within the game window (I’ve only been able to do this on my PC through a VNC connection).
I’ve also added a control to my Godot Project to exit the game to the main launcher menu when you press the Menu button on the GameShell (while input is working) or Escape key over VNC.
I’ve figured out a work-around for the time being that runs the game project as an app and input actually works fine: load it in the current version of Clockwork OS v0.3! I had the original SD Card that shipped with my GameShell and had flashed an old 8GB card to play around with the previous Clockwork OS because it supposedly worked better with emulator cores.
Next on the agenda: Test one of the FRT versions with Godot 3.1 Beta support and keep fingers crossed that Godot 3.1 GM will release soon.
Godot 3.1 is now released with support for OpenGL ES 2.0
Yeah, would be great if someone could build export templates for the GameShell!
@Samdze I’ve successfully compiled an export template with Godot 3.1 stable on my GameShell.
Trouble is it doesn’t appear to be that easy. I made the tweaks for input and resolution, exit function mapped to escape key (Menu button on GameShell) then did an export project with the 2D Platformer Demo.
It technically runs on device, but it has a bunch of errors and no visuals after the Godot Engine splash screen. Sound was a bit distorted but generally worked. I could tell the input worked as intended since I could hear the jump and shoot sounds play with the buttons I mapped to those actions.
Previously I had trouble with the gcc compiler from the godot guide so they recommended trying Clang instead with the use_llvm=yes parameter. I doubt that would change anything with the errors though.
It seems there’s a lack of implementation for the Lima drivers.
I’ve updated my github and consequently forgot to update this post. I tried the original exported project from the export templates built on the CPI fw v3.0 running on the CPI fw 0.21 and it does work better, though I wanted to get everything working as it should so I’ve recompiled the target=release export templates on fw 0.21. I’m in the process of compiling the export template on CPI fw 0.21 for the debug target because there’s still sound distortion issues and the ALSA driver sends errors about underrun.
Since this is a bit complicated with several components that all have different version requirements I’m going to summarize that here:
You can find all the details and grab the compiled binary at godot_3.1_cpi on GitHub
I loaded firmware 0.21 and recompiled the export templates this weekend. Those ALSA sound underrun errors still come up in the terminal but for now I’m ignoring them since I have a game but it has no sound.
Here’s what I’m working on which will likely turn into my 2019 Q2 game jam entry, running on device:
It started out as an homage to Gameboy games since I first made it on the 30th anniversary of the Big ‘N’s handheld console. I’ve since then transitioned to Super Gameboy color palette and finally on the NES style.
And since the Godot standard Splash screen no longer works, I made this one instead (which you are welcomed to use):
That’s great!
Hope to see this process simplified in the future, with the Raspberry Pi direct export that should be in the works the situation may improve.
Also hoping the lima drivers get fixed/completed as soon as possible.
Anymore Updates? Just ordered my GameShell and I love godot would be amazing to use it on here
Oh boy my unit arrived recently and I’ve been stoked to see if I could get a certain game I’ve been working on and off running, though one thing had me curious-- Is there any reason why you use the 0.21 image instead of the .3 one?
EDIT: Looks like there really is a driver thing going on-- that being said though on .21 the exports seem really slow, compared to FRT. Have you tried compiling the export templates with extra flags like these? CCFLAGS="–target=arm-linux-gnueabihf -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mlittle-endian -munaligned-access"
I’m not sure if the --target=arm-linux-gnueabihf in particular would work on the hardware, though.
I’ve been looking into setting up a build environment with my workstation PC to cross-compile for ARM, although I’m stuck at the linking stage at the end of the build. I’ll post some progress if I manage to move forward with it!
Any news? Has anyone managed to make Godot exports work “flawlessly”?
To report on progress so far, set my toolchain up and grabbed necessary libraries from the CPI (I’ll fill in on that later if i manage to get it functional) and ran a command like this.
scons platform=x11 target=release arch=armhf tools=no use_llvm=yes use_lld=yes use_lto=yes CCFLAGS="–target=arm-linux-gnueabihf -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mlittle-endian -munaligned-access" LINKFLAGS="–target=arm-linux-gnueabihf -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mlittle-endian -munaligned-access -v -I/usr/lib/arm-linux-gnueabihf/ --sysroot=/usr/arm-linux-gnueabihf" module_mbedtls_enabled=no module_webm_enabled=no module_webp_enabled=no module_webrtc_enabled=no module_websocket_enabled=no disable_3d=yes disable_advanced_gui=yes module_upnp_enabled=no module_gdnative_enabled=no module_bullet_enabled=no builtin_pcre2=no builtin_libtheora=no -j12
A little monstrous, I know, but it did result in a binary that fits the architecture, after double-checking with file. Shame I couldn’t build with GDNative enabled though… That would let us write game logic with C++ or whatever supports interfacing with the C ABI (D, Rust, Nim to name a few).
The problem now however is that my toolchain is… too new. The version of libc6 and libm don’t match. I’m going to try this again on a VM running Debian 9… which should match the CPI. I’ll report on this later, but I think I’m on the right track.
