Allegro.cc - Online Community
Post Reply

Allegro.cc Forums » Allegro Development » Allegro 5 under Raspbian Stretch runs veeeeeerrrrrry slowly.

rss feed Print
Allegro 5 under Raspbian Stretch runs veeeeeerrrrrry slowly.
Ian Lewis
Member #15,817
December 2014

Hello all,

Short version: I have written a game which runs under Raspbian. It ran at ~30fps under both Wheezy and Jessie versions of Raspbian. It's unbelievably slow under Stretch. Anyone have any idea why, or how to fix it?

Longer version:
I had a report that my game didn't run under stretch, with the following message:

Quote:

pi@raspberrypi:~/GravStorm-master $ ./gravstorm
./gravstorm: error while loading shared libraries: libGLESv2.so: cannot open shared object file: No such file or directory

A quick google suggested this was common with many games that used to run under Jessie, and it's because the raspbian/debian packagers renamed some libraries. I figured the best thing to do was to install Raspbian stretch, install allegro, and rebuild my game. So I did.

[For reference, all my previous development I did under Wheezy, with Allegro 5.1.8 (which was current when I started, and I never bothered to update). Oh yes, and I have an original, old model B Pi.]

I installed and built allegro 5.2.4, following a combination of these three pages:

https://wiki.allegro.cc/index.php?title=Install_Allegro5_From_Git/Linux/Debian

https://ventilatorxor.wordpress.com/2011/08/07/linux-allegro5-static-linking-for-beginners/

https://therobotacademy.com/feed/compile-allegro-5x-raspberry-pi

with static linking.

I then built my game without too much trouble, but it runs very slowly. I got bored waiting for the title screen animation to run, but I'm estimating of the order of 1 frame per minute. I've seen a thread complaining of something similar, and blaming the mesa driver, though it doesn't seem quite as extreme as what I'm seeing.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=191791

So, anyone seen similar? Any ideas what might be causing this? Or how to fix it?

Cheers,

Ian.

P.S. Source code at https://github.com/IanLewis42/GravStorm if anyone wants to try it. Or indeed play it!

EDIT: Just remembered I had to tweak a couple of things to make it build, and the modified files aren't in github yet, so it may not build from there.....
EDIT: OK, github now up to date, everything should build.....

Edgar Reynaldo
Member #8,592
May 2007
avatar

Hi Ian,

Don't have a PI so I can't help you fix this, but I did try to play your game. I can't quite figure out how to reassign the keys. I press down to highlight define keys and press right and enter and nothing works. I can't play the game currently with RCTRL right next to the arrow keys like that.

Ian Lewis
Member #15,817
December 2014

Bugger. You're right.....

OK, fixed, misplaced curly bracket, probably when I was 'tidying up' the code...... ::)

New windows exe and menu.c on github.

Thanks for checking it out!

Edgar Reynaldo
Member #8,592
May 2007
avatar

Issue resolved. The keys now assign correctly. Thank you.

Played through level 3, started getting quite hard. Never been the best at asteroids or lunar lander. I think a quite genuinely good idea might be to try controlling the ship with the mouse or the joystick. I'm going to add joystick support to my missile defense remake I expect. Shouldn't be terribly hard. And a friend got me wondering about porting it to Android or iPhone as a touch game. Could be cool. Aim the ship with the mouse or joystick, then pull the trigger or LMB to engage engines. Or swipe gesture to fire the engine with touch, in the direction away from the ship.

Thanks for the fun

Ian Lewis
Member #15,817
December 2014

Glad it's working, and glad you enjoyed it. It's definitely more fun as a multiplayer combat-style game.

USB Joystick support should be there, though I think it only shows in the menu if you have a joystick attached. This seemed like a good idea at the time, but perhaps it would be better to show it as 'not detected' or something. And I've only tried it with an old-fashioned on/off type of joystick, so I don't know how well it would work with an analogue stick.

The Android version uses a sort of analogue-touch-stick for direction (see screenshot), which works reasonably well. I guess a similar idea could be applied to mouse control....

Cheers.

Ian.

P.S. Out of curiosity, what platform are you running it on?

{"name":"611427","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/a\/eaa446fe6f0a4e8f256d50c4a7e66bc1.png","w":960,"h":540,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/a\/eaa446fe6f0a4e8f256d50c4a7e66bc1"}611427

Peter Hull
Member #1,136
March 2001

As a matter of interest, on your RPi, do you get the same slowdown with glxgears that was reported in the link you gave? Also can you compile any of the simpler Allegro example programs to try and narrow it down?
Pete

Chris Katko
Member #1,881
January 2002
avatar

I'll try and flash Rasbian Stretch on my Pi's this weekend (or hopefully earlier) and see if I notice any issues.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Ian Lewis
Member #15,817
December 2014

Yes, glxgears runs at 4-5fps, and with wrong colours (white/yellow/cyan ; I believe it should be red/green/blue)

Sure I can try an example. There's a lot of them though, and I'm entirely unfamiliar with them. Any suggestions? or I'll maybe hack something simple together that I can post the source of.

Some updates:

The initial animation runs at ~8 frames per minute. It's not terribly complicated; a tiled bitmap for the background, a text string and another bitmap of the logo, with scale transformations.

I have managed to get the 'old' version (allegro 5.1.8, built under Raspbian Wheezy) to run on Stretch. It runs at normal speed (30fps). To do this, I had to make symbolic links to the renamed libraries:

cd /opt/vc/lib
sudo ln -s libbrcmEGL.so libEGL.so
sudo ln -s libbrcmGLESv2.so libGLESv2.so
sudo ln -s libbrcmOpenVG.so libOpenVG.so
sudo ln -s libbrcmWFC.so libWFC.so

and also:

export LD_LIBRARY_PATH=/opt/vc/lib

I'm told that a better way to do this is via a .conf file in etc/ld.so.conf.d but that doesn't seem to work for me :-(

The 'new' version (allegro 5.2.4, built under stretch) doesn't need either of these steps, so is (preumably) picking up it's libs from somewhere else, possibly /usr/lib/arm-linux-gnueabihf , though even having done these steps, the new version still runs slow, so I guess that's not the whole story.

There must have been a significant change in the way stuff is displayed, as the 'old' version has only ever run full-screen, at the requested resolution, regardless of what flags I passed to al_set_new_display_flags(). The 'new' version seems to respect the flags, and will run in a resizable window on the desktop.

Sadly, I've no idea whether that change is more likely to be in Allegro or in some component of Raspbian.

I've looked through Allegro changelogs, and found nothing specific to Raspberry Pi that looked like it might be relevant, but I did find some general Linux changes:

5.1.12 to 5.1.13
Allow using OpenGL ES in X11.

5.2.3 to 5.2.4
Make compositor bypass configurable in X11, and bypass only when fullscreen by default.

Anyone know what effect either of those will have had? And can I choose their behaviour from my code?

Cheers,

Ian.

Chris Katko
Member #1,881
January 2002
avatar

Ian Lewis said:

Yes, glxgears runs at 4-5fps, and with wrong colours (white/yellow/cyan ; I believe it should be red/green/blue)

I just installed it and ran it. Yeah, that's a BIG red flag for me. [Edit:] That sounds like it's running in a software / compatibility mode with some unnecessary format conversion taking place! (like it thinks its in HSV, so it does a RGB -> HSV conversion, for example.)

I get 28 FPS though. Did you leave it running for more than a few seconds? It starts off at like 7.

Quote:

The initial animation runs at ~8 frames per minute. It's not terribly complicated; a tiled bitmap for the background, a text string and another bitmap of the logo, with scale transformations.

Are you doing anything strange with timing? Some times people make mistakes in their event handling code and when there's a system change, it blows up, but their original system "hid" the bug. For example, not dropping more-than-one queued up "to draw" frame, and it takes longer than one frame to draw so another gets scheduled, then it's two, then it's three... and soon it's like 80+ frames behind and the mouse/keyboard input is lagged to heck. (I had that problem before, for example.)

[edit] This looks like a RPi problem... that they haven't bothered to fix yet.

https://www.raspberrypi.org/forums/viewtopic.php?t=191791

Last post was October 2017. >:( >:( I'm actually super pissed at the developers lack of care, and bitching in that thread.

Quote:

"Stop being so impatient."

Stop releasing broken software you smug twats. >:(

Quote:

If you want official, then you need to add a github issues reporting the problem, please include your setup, and specifically the problem you are seeing. Just posting on the forum does not guarantee that it will be seen by the right people. I am not 'the right people', and none of the 'right people' appear to be in the office this week, so rapid response seems unlikely.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.

I thought you had to live in Silicon Valley to be that condescending to your customers who honestly ask for help. ::)

I just installed the most recent version of Rasbian, so there's no official solution yet. One poster mentioned 2X performance by reverting to an older RPi version of a graphics library.

There may be other threads with other user's solutions. I haven't seen it yet.

But an issue that basically makes ALL programs slow with graphics? And it's not resolved almost a year later? ARE THEY INSANE? Do they even work?

I swear, I don't know why I'm not confident enough to start my own company. Because every year I encounter more people like this that make me wonder if a couple of condescending apes smashing laptops together to make a fire, can run a multi-million dollar business. ::)

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Post Reply
Go to: