Sorry your browser is not supported!

Hello all.
I've managed to get my AppGameKit game running on a Raspberry Pi but am struggling with the framerate. It is just too slow. I run the same app on my mid-range Android phone and get 60 frames per second but on the Pi I get about 5 fps full screen. Considering it is a Pi 3 model B+ with a 1.4GHz 64-bit quad-core processor I am a little disappointed. The game is written using Tier 1 and is all 2D but does use physics which might be a CPU hog.

Does anyone have any advice as to how to speed the whole thing up?

I am running it on RaspiOS Buster (32bit) as newer operating systems seem to lack some libraries that the AppGameKit Player app needs. I've turned off VNC, Bluetooth, and set the GPU memory to 128MB as I thought that might help. It looks to be a pretty bare-bones OS but is there anything else I can turn off in the background to help? Eventually, if I can get it working satisfactorily, this will be running as a stand-alone gaming device so I can turn off all networking and anything else that AppGameKit doesn't require if needed. Any advice at all is welcome.

The Raspberry Pi 3 is quite slow in comparison to new models but if your media is optimized it makes a lot of difference. The AppGameKit core itself will probably run at higher fps, which means is the load you impose what makes the game run at slower rate.

First order would be to check the actual code and optimize loops or any other routine.
3D games require much more internal math calculations, so the CPU performance is affected if there are complex geometries in the game.

This is my checklist. I have experienced earth to heaven differences in performance:

- Reduce size, bit depth of all images for backgrounds, sprites and fonts.
- for 3d models, reduce polygon count at minumum. Use the simplest geometries possible, This makes a BIG difference.
- 3d model textures should be reduced in bit depth and resolution as much as possible.
- Sound files probably wont affect FPS but anyway it is better if they are as low footprint as possible.
- Optimize your particles, reducing rate and again, images.
- Reuse images in sprites, as well as any other image use.
- Reflection and ambience Shaders can be CPU intensive as well.
- Use the least Physics objects possible.

Hi All,

Thought I'd add my own experience with the Pi 3B+ and AGK.

I have developed successful games on the Pi 3, and my biggest knock on FPS was that I need to access the SD Card twice a second, simply to use as NVRAM ( credits & bank etc )

Some cards were words than others, however a stable 30 fps was enough for these applications.

My latest game,with more animations and generally a step up from the previous, saw this go down to 16 - 20fps , so I painstakingly removed certain gfx aspects / animations to see what was causing the delay.

Nothing graphically that I was doing made any difference.

I'm not sure if running the game in portrait ( display_orientation = 3 - in config.txt ) and full screen ( 1080 x 1920 ) has any effect, still tinkering, but the SD Card access is still losing about 5pfs.

If anyone has anything further to add, I'm aleays open to suggestions.

I have this also running on Pi 4 - and the frame rate is the same as Pi 3..

Thanks!

Thank you both for your comments on this.

Just to confirm...
+ I'm not doing any 3D (all 2D).
+ I've disabled all sound in the test app.
+ There are no particles.
+ There are no shaders used.
+ The code is as optimised as possible.

As a test I have tried the following to see if there was any effect:
+ With physics, running full screen = 5fps
+ Without physics, running full screen = 12fps
+ Without physics, running in a window = 13fps
+ As above, GPU upped to 256MB = 13fps
+ As above, GPU lowered to 32MB = 13fps
+ As above, removed text/font objects = 13fps
+ Chopping up large sprites into multiple smaller sprites = 13fps

Having 2D physics turned on is definitely hitting the frame rate but I was expecting a much bigger difference. The memory set aside for the GPU seems to make no difference with this relatively small app. I have also tried the screen in portrait mode but tested all of the above in landscape mode.

There isn't really anything else I can turn off in the app for testing. The only way I could get the frame rate up to about 50fps (with physics on) was by swapping the larger sprite images for smaller ones, but without adding any additional sprites - so it isn't really a fix.

Seems that your game makes it as simple for the CPU as it can get. With those settings it should be much faster.
If that is so, the only remaining thing to do is to start experimenting into video drivers to take advantage of GPU. Wrong OpenGL libraries can be also affecting performance.

Also, for finding "parasite processes", open a remote terminal from your desktop computer while you run your game in the pi, and enter htop (maybe need to install sudo apt-get install htop). You can see which resources are being used, memory, CPU, Etc. Probably you have used it. If not, it is kind of a task manager for Linux.

As far as I know drivers are configured via overlays, in the /boot/config.txt file. Of course it is a matter of experimenting but having the wrong driver really can slow down a graphics.
All that said, the only time I changed a driver for the raspberry pi 3 is to use a small display with touch screen. With the 3b+ never used Buster, but with Raspbian Jesse I had much better performance than yours, with my actual games using physics or with any of the TGC demos.

Check these links:
https://magpi.raspberrypi.com/articles/raspberry-pi-3bplus-specs-benchmarks
https://forums.raspberrypi.com/viewtopic.php?t=317511
https://github.com/raspberrypi/linux/blob/rpi-4.1.y/drivers/media/platform/bcm2835/bcm2835-camera.c#L677
https://github.com/ssvb/xf86-video-fbturbo
https://raspberrypi.stackexchange.com/questions/64079/how-can-i-setup-the-video-graphics-on-the-raspberry-pi-3

EDIT: I just tested in my pi3B+ with Raspbian Jessie and all the AppGameKit example projects, including games, physics and bone animaton run at 59.xx FPS. My game runs between 55-58 fps.
In the /boot/config.txt all overlays are commented, meaning are at the default settings. HDMI settings are commented as well. gpu_mem is 128

Hi, hope all good with everyone.

My latest project - despite painstakingly commenting out various sections, still remains at 24fps - not great but at least it's constant ( before I was see drops down to 16fps )

My quesion is, would rotating the display have any effect on the FPS - as this project is in portrait mode ( display_orientation=3 )

Yeshu777

Yeshu777, thanks for pointing out screen orientation.
Am really surprised because I found two things in my test game on the raspberry pi with bullseye32:
- Full screen mode for the game reduces FPS from 59 to 30, and this is in portrait mode.
- Rotating the screen 90 or 270 reduces FPS further, to 14.5. (this is the video driver, not rotating physically).

Since bullseye does not use config.txt for rotation, I used xrandr --output HDMI-1 --rotate right to set screen rotation. If wayland is activated, then HDMI-1 becomes XWAYLAND0 but I could not make it rotate with that utility.
Are you using bullseye? I guess not because of the parameter you mentioned.
Later will try on Buster but I bet it is the same.

Now, a solution that can potentially overcome these problems is
a) using a monitor that can rotate the screen by itself, plus...
b) faking the fullscreen mode by presetting a neutral color and the start coordinates of the application (and removing the "chrome", edges and title of the window which is kind of easy in Tier2)
c) reducing the overall resolution of the display and or surface being rendered (virtual resolution within the app)
I remember doing these steps in a pi3b in 2017 and didn't have any trouble with FPS on AGK.

Personally I overcame those problems with the powerful OrangePi 5 plus which goes as fast as it can even with fullscreen and rotation.

H JD,

Thanks for the info - yes portrait and full screen would be the problem - and it explains it perfectly.

I also get the same with the Pi 4 players ( 30 fps limit )

But your answer has at last given some reason as to the slow fps.

I'll check my Pi 3B 'standard' SD card and see what it's running - as was created some 2 years ago.

Shall report back, all the best!

Yeshu777

Yeshu777,
I tested yesterday my test game on my old setup with raspbian Jessie (raspberry pi 3b+).
On that Pi, the same game we were discussing previously runs at 57+ FPS in Full screen and with display_rotate=3, whereas in the same conditions the exact game runs at 14FPS on the Pi4.
This is a good motivation to keep using the Raspberry pi 3 family, at least until I find the problem on Pi4.

I think the it has to do in part with the resolution set on /boot/config.txt.
On the Pi4 there are factors like the display driver handling, or maybe openGL performance there.

My tests on the Pi4 (bulllseye, bookworm, 32 and 64) use the newest players I compiled, while the test on the Pi3 (Jessie) uses the factory version of AppGameKit 2017-05-05.

On the AppGameKit code, virtual resolution and windows size are set at 800,1280 (for portrait aspect)
Relevant parameters on config.txt are:

# set portrait proportions
framebuffer_width=800
framebuffer_height=1280
display_rotate=3

#hdmi params
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=28

#gpu
gpu_mem=256

Maybe you guys can do your own comparison test and post results here.

Hey JD,

Completely missed this, on my app ( on Pi 3B+ ), my resolution in main.agc is as follows :



I'd not thought about setting similar in the config.txt other than "display_rotate=3"

Shall have a look..

JDforce - Your post got me thinking about the version of the OS being the limiting factor so I thought I would give it a try yesterday. After a lot of frustration, these are my findings...

Using “Jessie” with Pi 3 Model B+
This version of the OS was release BEFORE the launch of the Pi 3 Model B+ so it has some BIG problems and isn't immediately compatible. You find that if you download the newest "Jessie" image, your Pi 3B+ will not boot due to the version of the bootloader not being compatible. If you boot it using an older Pi (luckily I have an old 1B and an SD card adapter) you can then update everything which fixes this. You must first change the sources for "apt" as the OS has been moved to a legacy server by doing the following:
sudo nano /etc/apt/sources.list
sudo nano /etc/apt/sources.list.d/raspi.list
Edit these two files and change any references from http://mirrordirector.raspbian.org to http://legacy.raspbian.org (but DO NOT change any references to archive.raspberrypi.org). You can then run:
sudo update
sudo apt-get dist-upgrade
This will get it to update everything it can to a version which will then boot on the Pi 3B+. There are other big problems though like it not supporting the built-in WiFi hardware which I was not able to fix. Unfortunately it still won't run AppGameKit due to some of it's libraries being too old and aren't easily updatable - at which point I gave up.

Using “Stretch” with Pi 3 Model B+
This was the version that came out for use with the Pi 3 so it works straight away and boots up nice and fast. As it is old now you also need to change the sources for "apt" to find any updates, so follow the directions above to update those and upgrade the distribution. The AppGameKit editor works fine on this OS but the PiPlayer does not. It complains with an error that GLIBC is not new enough and even the newest version in it's repository isn't good enough. As a last resort I downloaded a newer version from a newer operating system's repository which I DO NOT RECOMMEND. Everything seemed okay after I did it but this can potentially break a lot of things in the OS. If you did want to try this, you can run these commands:
wget https://archive.raspbian.org/raspbian/pool/main/g/glibc/libc6_2.28-10%2Brpi1%2Bdeb10u2_armhf.deb
That downloads the Debian package.
sudo dpkg -i --force-all libc6_2.28-10+rpi1+deb10u2_armhf.deb
That forcibly installs GLIBC version 2.28 (which is just a little newer than the provided version) against all of the warnings, using the package manager. This got PiPlayer working for me but sadly my full-screen game framerate was still only around 14 fps. This is about 3 times better than using the "Buster" OS but still not quite good enough for me.

If I get time I might try the next version of the OS after "Stretch" to see if that works without too much hacking. For now I have switched to a very cheap Android TV box instead (actually cheaper than a Pi) and it runs my game, full-screen at about 50 fps. The only downside is that I don't get the I/O benefits of the Pi.

Interesting...
After your commentary, at first I thought that was a Mandela effect, because I remember vividly only using Jessie with the Raspberry pi 3B around November 2016 and we kept using Jessie when the 3B+ was out, around 2018.
I didn't like stretch because some programs we already had in Python handled the network adaptors by name and Stretch changed something about that, but the same SD cards and Card Images I had for the 3B worked without any problem. So we skipped Stretch but used Buster.
Because of that, we kept using Jessie until we started using the Pi4.

I don't remember having any trouble with Jessie and apt-get. Probably never used apt, but rather I used apt-get.
An don't remember any incompatibility with AppGameKit, it was straightforward to use.
Since I have some Pi 3B and B+ units, and many of my development SD cards with Jessie, I just tested a couple and everything still work great,
In one of those old 3B+ and Jessie that I tested the FPS from my previous test.
So, no Mandela effect for me haha.

Hi all,

The current OS Image I created for my projects is "Buster" - 2019

How down this version stand with the fps ( obviously still has the 24fps limit in portrait mode ) are there any improvements to be made?

Yeshu