Allegro.cc - Online Community

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

This thread is locked; no one can reply to it. rss feed Print
 1   2 
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. ::)

[edit]

Yep. I finally got my full dev chain installed. Allegro, DAllegro, LDC, all compiled from git.

My current game project compiled and loaded.

0 to 1 FPS.

#esportready

-----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

Thanks for that. Glad it's not just me :-)

I just installed it and ran it. Yeah, that's a BIG red flag for me.

Do you mean a big cyan flag? ;-)

[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.

Yeah, ran it for at least a minute. I do have old Pi hardware though; original Model B, single core CPU @700MHz IIRC.

Are you doing anything strange with timing?

Don't think so. I was going to post the code but having just had a look, it's a bit of a mess..... So maybe ;D Doesn't sound like it's just me though...

I've just been reading that the 'Full KMS' driver accessible via raspi-config max fix this issue, though I thought I'd tried that (among many other things....) I'll give it another go tonight / next time I get a chance.

I'll see if I can knock a noddy demo up as well, to demonstrate.

Chris Katko
Member #1,881
January 2002
avatar

Ian Lewis said:

Do you mean a big cyan flag? ;-)

Holy crap that made me chuckle out loud.

I'm using a model 2 whatever Pi B.

It should be able to handle !@$!ing pictures. In fact, had I realized the OS was the issue, I would have kept it on the previous. Because I could run videos, play games, and more.

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

I have no experience nor expertise with a Raspberry PI, but this seems awful similar to memory bitmap slowdown. Can you do some run time testing and check if your bitmaps are memory bitmaps?

bool is_memory_bitmap(ALLEGRO_BITMAP* bmp) {
   return al_get_bitmap_flags(bmp) & ALLEGRO_MEMORY_BITMAP;
}

EDIT
Did you see the post about the DPI2 no suitable driver error that came up?

EDIT2
Compile in debug mode and check allegro.log.

Ian Lewis
Member #15,817
December 2014

Yeah, I can try that stuff. I'd be surprised if it's memory bitmaps, but it won't hurt to check.

Did you see the post about the DPI2 no suitable driver error that came up?

No, what was that?

So the full-kms driver made no obvious difference, to my code or glxgears. ::)

I'm using a model 2 whatever Pi B.

The model 2 Pi had a quad core processor @900MHz, IIRC, so it should be a fair bit quicker.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Ian Lewis
Member #15,817
December 2014

Ah, gotcha. OK, I'll check if I have the same log entry when I get back on my Pi.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Chris Katko
Member #1,881
January 2002
avatar

I don't have allegro.log. I'd have to recompile the entire Allegro (on a Pi that takes awhile!)

But I also have that line in /var/log/*xorg*:

Quote:

Extended renderer info (GLX_MESA_query_renderer):
Vendor: VMware, Inc. (0xffffffff)
Device: llvmpipe (LLVM 3.9, 128 bits) (0xffffffff)
Version: 13.0.6
Accelerated: no
Video memory: 927MB
Unified memory: no

They said in their github bug report that it's "upstream" and "We don't support upstream, so !@$!@ off."

If I go into raspi-config and set "OpenGL Full KMS", it fixes the color, and gets even slower. Just like the posters in that thread.

I'm absolutely stunned by the quality of service from the Raspberry Pi guys. I honestly thought they were better people.

[edit]

What do I need to get allegro.log to show up?

I recompiled Allegro with cmake debug options. I put the libs in my directory and LD_LIBRARY_PATH'd to them. And then recompiled my app. But I don't have an allegro.log.

I'm using DAllegro though. But there's no #define TURN_ON_DEBUG required, right? It should just work with the new library?

(Did I need a flag for make as well? Or just cmake .. -DCMAKE_BUILD_TYPE=Debug then make?)

[edit] It takes any build flag. WTF. How do you build Allegro in debug mode? Googling it comes up with nothing.

Swapping the order so flag comes before .., let's see if that helps. But I don't see any metnion of DEBUG MODE in the cmake output. >:(

[edit] Looks like that worked by swapping the order of .. and -DCMAKE flag.

Here's allegro.log from running ex_draw_bitmap.

It actually runs fairly fast... but... my game still runs slow as piss. (4 FPS at 640x480 drawing a couple layers of tile map with frustrum culling to speed it up.) It could just be that the example is so basic, it's not slowed that much.

I also changed my raspi-config to do the middle option of OpenGL KMS fake whatever that is. Not sure if that improved the Allegro examples. I'll try more when I have time.

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

Chris Katko
Member #1,881
January 2002
avatar

Be sure to check my last edit. I posted the allegro.log.

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

Chris Katko
Member #1,881
January 2002
avatar

SEGFAULT.

But I think I'm having other issues too. Because I get no allegro.log at all and that should show up.

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

Ian Lewis
Member #15,817
December 2014

A few random updates on this.

- I've double checked, and the 'experimental' OpenGL driver has no effect, as far as I can tell. I doesn't even give me correct colours, as it seems to for others. Perhaps this is because my hardware is too old (Original PI, would be model 1 if they'd thought to number them :-)

- My original bug reporter now has my game running at full speed, using the new OpenGL driver, but he has a Pi3. It looks like there may be significant hw differences....

-> I've just found this thread https://www.raspberrypi.org/forums/viewtopic.php?p=1090593 which suggests:
a) New OpenGL driver only works on Pi2/3
b) It may be possible to get it working on Pi1/0, but it takes a lot of hacking.

Also, looking back at the original RPi 'complaining' thread, the OP there seems to be saying that everything's fine when the new driver is enabled, he only had problems when it wasn't. Also on Pi3.

This doesn't entirely explain why it doesn't work for Chris (on Pi2) but does suggest why I'm getting nowhere fast with my hw.....

- Yes, I have assorted messages in /var/log/*xorg* saying 'no hw acceleration'.

- I made use of Edgar's ALLEGRO_RENDER_METHOD suggestion to make an attempt at auto-detecting hw acceleration, and used this in my noddy example. I've attached this (one .c file, plus a font). It does a slowly fading background, and a couple of text strings (reporting FPS) and manages ~8fps on my Pi. Which is clearly pretty pathetic :-) If anyone else wants to try this on a Pi, I'd be somewhat interested in the results.

Cheers,

Ian.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Ian Lewis
Member #15,817
December 2014

Well, I think there are solutions already, albeit a little complicated.

My understanding is as follows:
If I build under Stretch, then the resulting binary expects to find libraries libGL.so and libGLU.so
If I build under Wheezy or Jessie, then the resulting binary expects to find libraries libEGL.so and libGLESv2.so
(this info comes from ldd)

I suspect the difference between the two builds is to do with pkg-config, or the way it's been configured. I'd be delighted if anyone can enlighten me further on this.

libEGL.so and libGLESv2.so have been renamed in Raspbian Stretch, but you can make an 'old' build work (at correct speed) using symlinks (as per my earlier post).

libGL.so and libGLU.so are present in Stretch, but the code runs very slowly unless you run the raspi-config utility to enable the new (experimental) OpenGL driver. I believe this is the difference between using hardware acceleration or not.

This new driver doesn't work on RPi version 1 hardware, owing to a lack of memory.

So the solutions are:
o If you have Wheezy or Jessie, run the old build.
o If you have Stretch and V1 hardware, run the old build with symlinks.
o If you have Stretch and V2/3 hardware, run the new build and turn on the new OpenGL driver.

Incidentally, I'd also be delighted if anyone can explain the relationship between the .so 'libraries' and the 'OpenGL driver'. Are they the same thing? With just a switch to say 'use the hw acceleration'?

 1   2 


Go to: