Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Issues with allegro games

This thread is locked; no one can reply to it. rss feed Print
Issues with allegro games
pix3lworkshop
Member #17,123
September 2019

Hello everyone,
Since I switched from Debian 8 to 9, I experienced an issue that affects every allegro based games in repositories, like Alex the allegator 4 and Ballz (So far, only these two were tested).

Playing results in system slowdown, 100% cpu peaks and very slow system responses, also the screen refresh is irregular and choppy.

All of these problems where not ever experienced in debian 8 or ubuntu 14.04, and are encountered only after upgrade the system.

I experienced the issue on two different hardwares, Intel i3 and i5, both with an intel based graphic card and direct rendering enabled.

I don't have any graphical problems with games based on X11, SDL or OpenGL directly, only Allegro ones.
Is there anyone experienced the same issue?

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Niunio
Member #1,975
March 2002
avatar

Xubuntu 18.04.3 here and no problems with Alex4. I must say I don't know what's my computer hardware more than several years old Intel and nVidia. ::)

-----------------
Current projects: Allegro.pas | MinGRo

Chris Katko
Member #1,881
January 2002
avatar

For the CPU issue: Since you're on Linux, you can run a poor man's profiler (if the game has symbols still in it, or you compile it yourself).

Run the game in gdb, then simply hit Control-C (on GDB). then type bt and hit enter for backtrace (shows the call stack). Because you randomly paused, it's most likely to be in the most CPU intensive part. If you do it like 5+ times in a row, and it's really frozen in a few (or one) functions, it'll show up over and over and over thanks to random chance.

("GDB poor mans profiler" has many Google results)

https://readwrite.com/2010/11/01/using-gdb-as-a-poor-mans-profi/

[edit] Is Debian 9 brand new or something? Because I usually keep my Linux up-to-date (it's some merge of Xubuntu/Ubuntu at this point) and I'm programming Allegro game prototypes without issue so far. I'll try downloading someone else's Allegro game later.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

pix3lworkshop
Member #17,123
September 2019

Thanks everyone for the replies.

I just made some simple test with Alex4.

[code]
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
%Cpu(s): 51,4 us, 4,5 sy, 0,0 ni, 42,7 id, 1,3 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : 3919468 total, 559512 free, 1037268 used, 2322688 buff/cache
KiB Swap: 1951740 total, 1951740 free, 0 used. 2546080 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4288 user 20 0 877800 12700 9560 R 101,0 0,3 0:06.35 alex4

[/code]

As you can see, the CPU run over 100%, the screen refresh is very choppy, I can see it half updated most of the time.
The sounds run smoothly instead, the keyboard has a lot of delays in the responses.

Just for testing, I just commented out everything inside "blit_to_screen" function in main.c, to check if the problem is the rendering process

[code]
// blits anything to screen
void blit_to_screen(BITMAP *bmp) {
//~ acquire_screen();
//~ if (options.use_vsync) vsync();
//~ stretch_blit(bmp, screen, 0, 0, bmp->w, bmp->h, 0, 0, SCREEN_W, SCREEN_H);
//~ release_screen();
}
[/code]

The CPU still at 100% usage, but the keyboard responds quickly this time, I can tell you this because of the associated sounds effects.

Just for the sake, I added an empty user to my system, for have an empty home folder without any kind of configs files, and tried other DE instead of KDE, but the results still the same.

One curious things anyway, is that compiling the allegro 4.4.2 from sources and run the bundled examples, like ex3d or exaccel, results in smooth rendering and very low cpu usage...

Anyway, my graphic card is a:
Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller

I'm using the xorg intel driver.

Sorry for my bad english or if something is miswritten or ununderstandable...

gusnan
Member #11,822
April 2010

@Edgar - I believe I can solve your stuck keyboard problem at least - If you don't have a connected hardware joystick, try to remove the file /dev/input/js0, and that problem should go away.

[edit]
See this bug report for more (maybe interesting) info:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714401
[/edit]

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Niunio
Member #1,975
March 2002
avatar

I'm really curious. As I've said, I have no problem in my installation, and I have a joystick that I use sometimes that is connected only when I use it. Let's compare my installation with yours:

Name                  | Package       | Version
----------------------+---------------+-----------
Xubuntu               | Ubuntu        | 18.4.3 LTS
Allex the Allegator 4 | Alex4         | 1.1-7
Allegro               | liballegro4.4 | 2:4.4.2-10

-----------------
Current projects: Allegro.pas | MinGRo

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

pix3lworkshop
Member #17,123
September 2019

@Niunio

My system is a Devuan Ascii (Debian Stretch), the packages installed are this (Merged from debian):

alex4/stable,now 1.1-7 amd64 [installed]
alex4-data/stable,stable,now 1.1-7 all [installed, automatic]
liballegro4.4/stable,now 2:4.4.2-10 amd64 [installed, automatic]
libdumb1/stable,now 1:0.9.3-6+b3 amd64 [installed, automatic]

On Devuan Jessie version, every Allegro games was running smoothly and fine.
Also on Linux Mint 17 (Ubuntu Trusty 14.04 I think), everything was ok.

I tried this game also on Trisquel, in live environment, and to my surprise it was runnning smoothly, but the use of the cpu was really very high, so much so that when I reboot, the uefi bios also warned me of a high CPU temperature.
Trisqel use linux-libre as Kernel unlike Devuan and Mint, I don't know if matters, but if it, maybe its some kind of spectre/meltdown fix introduced that cause this issue...
Just wondering...

I will try to check with the "poor man's profiler" as soon as possible as suggested by Katko and see if I can found something interesting...

Anyway, thanks a lot for now!

Niunio
Member #1,975
March 2002
avatar

I'm running Ubuntu 18.04 in a VBox VM.

May be the communication between VM and joystick isn't working as Linux expect. Just wondering, I have no idea, but if host is Windows peripheral devices works in a very different way than Linux (I have both Windows 7 and Xubuntu installed in the same computer, so I know about it).

alex4/stable,now 1.1-7 amd64 [installed]
alex4-data/stable,stable,now 1.1-7 all [installed, automatic]
liballegro4.4/stable,now 2:4.4.2-10 amd64 [installed, automatic]
libdumb1/stable,now 1:0.9.3-6+b3 amd64 [installed, automatic]

That's exactly the same installation I have. I have a 64bit system too so may be we're using the same binary! Maybe we're using different joystick configuration.

-----------------
Current projects: Allegro.pas | MinGRo

bamccaig
Member #7,536
July 2006
avatar

I'm running Ubuntu 18.04.3 LTS (MATE flavor) and input appears half functional and half blocked. I can navigate the menu, and start the game. When I start the game, I can walk left or right, but I cannot jump (Alt apparently). I've tried hitting damn near every key on the keyboard, and the only thing that would work was left and right arrow keys. I haven't attempted to delete a joystick device yet. That seems like the wrong way to fix it, albeit a viable workaround for somebody that really wants the game to work and doesn't care about joysticks. Disappointingly the bug report linked to appears to give up and pass the buck instead of at least linking to a new bug on the appropriate package. If the kernel is indeed wrong I'd hope somebody has reported the bug to the kernel devs as that's arguably the most important piece of software running on your machine...

pix3lworkshop
Member #17,123
September 2019

@Chris Katko

I tried the "poor man's profiler" as suggested.
Here, is the output:

[code]
$ gdb -p 2924
Attaching to process 2924
[New LWP 2925]
[New LWP 2926]
[New LWP 2928]
[New LWP 2929]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: File o directory non esistente.
(gdb) bt
#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007f25efa68bb5 in __GI___pthread_mutex_lock (mutex=0x557ca8220400)
at ../nptl/pthread_mutex_lock.c:80
#2 0x00007f25f03dc650 in _unix_lock_mutex ()
from /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
#3 0x00007f25f03dee49 in _xwin_lock ()
from /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
#4 0x0000557ca68a2d7a in ?? ()
#5 0x0000557ca68a97e2 in ?? ()
#6 0x0000557ca6897ae7 in ?? ()
#7 0x00007f25effa02e1 in __libc_start_main (main=0x557ca6897980, argc=1,
argv=0x7ffe60fc4f78, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7ffe60fc4f68)
at ../csu/libc-start.c:291
#8 0x0000557ca6897bfa in ?? ()
(gdb)
[/code]

I noticed a strange thing during the test.
If the game window is minimized or half covered in the top part by another one, the rendering getting speeder.
I can see some animations rendering more smoothly and the sounds playing good, not choppy...

If I cover the game window on the side and not bottom, the rendering starts to be choppy again.
Maybe a vsync issue?

In the first attachment, a screen of what the rendering looks like during a normal gameplay.
In the second one, the game window partially covered by firefox, the rendering is quite smoothly.
Sometimes as in the screen, the pixels looks misaligned...

gusnan
Member #11,822
April 2010

I can reproduce pretty high CPU load when running alex4 in a virtualbox mahcine running Debian in some cases, and this seems to be due to Pulseaudio emulating alsa for the sound. Running htop reports high CPU usage on Pulseaudio.

When running using the command "pasuspender alex4" it runs fine on this VM too (But without sound of course). I have found bug reports that seems to support this, but they are really old.

pix3lworkshop
Member #17,123
September 2019

Thanks for your reply gusnan, I tried "pasuspender", but it doesn't solve the problem...
I also tried to remove the intel graphics driver and leave vesa, just to test, but everything still remain the same...

Update
I suspected that the problem was the graphical driver (intel i915), so uninstalled the xorg driver and VAAPI driver packages and test the game, same problem.
The driver was still loaded, because it was provided also by the kernel too.

So, I blacklisted it, and well, now alex4 and ballz (I tried this two only so far) works smoothly and well!

[code]
$ dpkg -S i915
linux-image-4.9.0-9-amd64: /lib/modules/4.9.0-9-amd64/kernel/drivers/gpu/drm/i915
libgl1-mesa-dri:amd64: /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
libgl1-mesa-dri:i386: /usr/lib/i386-linux-gnu/dri/i915_dri.so
[/code]

By searching the web I saw that a lot of people had similar problems with this driver and some had fixed it by passing some configuration options to it in /etc/modprobe.d.

So, I will provide some more further info if I will find the correct option and fix the problem definitly, hoping this can be useful also to others.

Thanks to everyone for the support until now ;D

Another update

Since I found that the problem was the driver, I played around with X11 configs, and just added this one to my system.

[code]
$ cat /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
BusID "PCI:0:2:0"
EndSection
[/code]

Now everything seems to works right, even the CPU is on average 90%.
The direct rendering is also enabled and also 3D works right, I hope this is the last fix...

Go to: