Ok, referring to the thread here about the FBTurbo driver. Does GameShell Actually Use FBTurbo?
Once I set the driver to use fbturbo properly, FRT and @Zeronaut 's templates seem to work fine, albeit with the same performance as previously described.
Other than that, gonna sit down tomorrow and finish setting up a build environment on Debian 9 to try and compile export templates for armhf there. Here’s hoping all goes well!
GameShell OS v0.4 has been released since the last message.
Has anyone noticed improvements?
As of now, I can confirm that games running under FBTurbo will run fine, but at a fairly terrible performance (15 FPS or so for my own little project of sorts), and doesn’t really run with Lima no matter what I throw with it.
I can’t really pin down a reason behind that, whoops.
Seems like lima driver implementation is really still not up to it…
@ArcOfDream, that demo and all look great! I’m going to try a recompile of the export templates with your settings suggestions on the 0.4 fw and with Godot 3.1.1 soon and I’ll post that on the github repo.
I can say that I’ve tested a project on firmware 0.4 exported using my Godot 3.1 templates from Godot 3.1.1 and everything works fine (at least as good as before).
I haven’t noticed major performance issues other than a really long load time (up to a minute or more for a simple game). Granted, I’ve not yet tried for some sort of 60 fps twitch based game yet, so I don’t know yet.
A new version of FRT has been released recently: https://github.com/efornara/frt
Trying it seems like the lima driver implementation used by the GameShell (v0.4) is an outdated one, could this be the case?
Even Mesa seems outdated, error outputs point to issues with the 18.3 version.
OpenGL ES 2.0 Renderer: Mali400
error: lima_blit not implemented
WARNING: _render_target_allocate: Could not create framebuffer!! At: drivers/gles2/rasterizer_storage_gles2.cpp:4610.
ERROR: _get_gl_image_and_format: R float texture not supported, converting to RGB8. At: drivers/gles2/rasterizer_storage_gles2.cpp:162.
Mesa 18.3.0 implementation error: bad format MESA_FORMAT_NONE in _mesa_uncompressed_format_to_type_and_comps Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
It would seem that solutions available in this modified OS will fix the problem with Godot not running under Lima drivers. Custom D.E.O.T. V1.0+/Clockwork OS v0.4 image - With Updated Kernel 5.3.6, Latest Lima Drivers, RA1.8.1, Mupen64+ and much more! (Current version: 191122)
I’m not sure however if it’s the latest mesa build or lima drivers (maybe both), but the script referenced in this thread post sets you up for latest mesa. (Link)
My test export project worked, starting up immediately and showing something around 100+ FPS (with one shader failing to compile) compared to 15 FPS through FBTurbo. Safe to say Godot might be finally viable to work with.
@ArcOfDream that’s fantastic! Unfortunately I’m not able to follow your process well enough to replicate the same results on my CPi.
My process so far:
X Error of failed request: GLXBadFBConfig Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 34 () Serial number of failed request: 25 Current serial number in output stream: 22 X Error of failed request: GLXBadFBConfig Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 34 () Serial number of failed request: 25 Current serial number in output stream: 22 OpenGL ES 2.0 Renderer: Mali400 Segmentation fault
Clearly I’m doing something wrong, can you share any more details of your process so I can get something up and running?
The Mesa drivers should already be updated, since the instructions are in the same thread I posted the image in. You shouldn’t need to do it again. Not enough info to help you, as I haven’t tried anything with Godot yet, but at least narrowing down your problems slightly.
Just to make sure, what version is the kernel at?
This particular image (build 191122) is on 5.3.6.
There’s discussion re: using apt causing the driver to break going on at the moment in the thread of the image. That could be something that is related.
I double checked and I am on 5.3.6 kernel. I have also used apt. That’s likely what’s going on. Since I likely need to use apt (That custom DEOT image is awesome, but there’s always stuff that I need for development that isn’t/shouldn’t be included).
Is my understanding correct that the current build of your custom DEOT v1.0 build 191122 has an updated lima driver from the stock 0.4 firmware image?
Knowing now what you two have shared I believe that my process of using my older export templates from Godot and running the exported binaries on the custom DEOT v1.0 build 191122 with no other modifications should do the trick.
Re: Using FRT, I vaguely remember that you grab a binary (pi1, since they don’t auto build a version exactly matching the CPi ARM v7hf IIRC), install that to your /opt/bin or where ever and then copy the entire project directory of your Godot project source and run frt from that directory’s root folder? I mainly dropped off using frt for two reasons: 1) They don’t provide builds that are by specifically for the CPi and 2) There was a time where newer builds weren’t happening and I wanted to use newer versions of Godot and CPi firmware, but it was easier to make my own export templates, which is what I did and continue to use.
Re: Godot Export Templates, looking back at their documentation I see that build on/for older kernel or software versions of the same system should work on future versions and is recommended for compatibility. However, Godot itself may have changed things in their newer versions, so we’ve got multiple moving targets to pin down here. @ArcOfDream which version of Godot did you test?
A quick update tonight:
I rebuilt my custom export template for the release (no debug yet, it failed to build), and it is working with the CPI firmware 0.4 and Godot Engine 3.1.2.
GitHub - Godot CPi Export Templates
I’ll probably try it with the lima driver on this stock firmware and then switch over to using the Custom DEOT image to see how things work.
I believe it was 0.9.6 version of FRT (pi2 ver.), specifically the one built against 3.1.2 version of Godot. An X11 build might work out better though, with proper build flags.
Thanks for sharing, did you happen to try anything with sound output? My export templates and FRT seem to work fine for anything except sound and actually freeze games that have sound.
As I looked into it, it appears that FRT is actually now just Godot export templates too. They recommend building your own with the right flags (which I’m still working out what’s best on those) if you have a device that is different enough from their presets. I think the Pi2 has similar enough architecture to the CPi to use that - though I had some trouble with some of those.
According to @javelinface the mesa updates and all are already in that custom DEOT image, but it definitely has some updates compared to the stock fw0.4 image.
Potentially, while updating Retroarch to 1.8.1 other things may have been updated. This may be the culprit.
On another note, this may be of use, hopefully standardising things on your own stock 0.4 image. Sorry to cross post, but I figured this would be relevant.
FW 0.5 update:
I can’t get the export template to work at all unless I run it with frt and even then I get errors. Anyone else out there have any luck? @ArcOfDream ?
What were though compiler flags that you used? I found you can get some of those related to the godot engine after checking out the source from github and running the following:
scons --help>>sconsoptions.txt
You’ll then need to open that sconsoptions.txt in your text editor of choice.
A sampling of the console log for errors:
cpi@clockworkpi:~/games/frt096_312$ godot3.frt.bin --main-pack GraveyardShift.pck
Godot Engine v3.1.2.stable.custom_build.ec02a81 - https://godotengine.org
OpenGL ES 2.0 Renderer: Mali400
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:726.
WARNING: _render_target_allocate: Could not create framebuffer!!
At: drivers/gles2/rasterizer_storage_gles2.cpp:4620.
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
For the game itself, the loading splash screen works then goes to a blank screen, input appears to work (I can only be sure the escape key and exit function does), Sound output works though there are cracks and pops, it sounds less distorted overall, like actually mostly playing at the right speed.
Y’know what, I haven’t actually tried Godot on 0.5 yet. Imma edit this post once I try some stuff out with your exports and FRT.
EDIT: Tested FRT and your X11 export, and the latter one works fine. Admitedly though none of my test stuff uses audio… Do you happen to have the edited 2D platformer demo?
Actually, I also get GLXBadConfig errors on my exported project, but it seems to run just fine besides a shader not working. With FRT there’s a bunch of render errors and a black screen, but it also seems to run fine otherwise.
I’ve put an audio file to see how well it’d play, too, but it sounds like a stuttering mess, yikes. Wonder if there’s a way to mitigate that?
The compiler flags I used on my system haven’t changed since back then:
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```Just wondering, has anyone done anything with Godot on gameshell since January?
Looks like the answer here in this fine video.