Graphics problem under Arch Linux
Moderators: Flumminator, Zomis
Graphics problem under Arch Linux
I just reinstalled my Desktop with new hardware and a new Arch Linux. There is a small graphics problem (I saw this before too): Animations in the menu (see attached screenshot) are "before" the text. The "doors" in the menu look strange. Sdl 2 is installed. The Problem is in the repository version and in a compiled version 4.1.4.1.
Regards
Karl-Heinz
Regards
Karl-Heinz
- Attachments
-
- Screenshot_20200511_114137.png (57.3 KiB) Viewed 18724 times
Re: Graphics problem under Arch Linux
Very strange -- this looks like every graphics and animation that should be transparent is not transparent anymore, but opaque.
I assume that you did not have this buggy behaviour with your previous system, so it looks like a problem with transparent blitting with your currently installed SDL version.
As I am not sure if I understand you right here: Does this problem also occurs when using the supplied binary from the release version (tar.gz for Linux)? Or what do you mean with "The Problem is in the repository version and in a compiled version 4.1.4.1"?
Which version of the SDL libraries (especially SDL and SDL_image) do you use? (Have a look at the "INFO -> VERSION" screen.)
Do you use SDL libraries shipped with your system, or did you compile the SDL libraries yourself?
Did anybody else encounter similar problems with recent Linux systems? I have seen this problem for the first time now...![Shocked :shock:](./images/smilies/icon_eek.gif)
![Confused :?](./images/smilies/icon_confused.gif)
I assume that you did not have this buggy behaviour with your previous system, so it looks like a problem with transparent blitting with your currently installed SDL version.
As I am not sure if I understand you right here: Does this problem also occurs when using the supplied binary from the release version (tar.gz for Linux)? Or what do you mean with "The Problem is in the repository version and in a compiled version 4.1.4.1"?
Which version of the SDL libraries (especially SDL and SDL_image) do you use? (Have a look at the "INFO -> VERSION" screen.)
Do you use SDL libraries shipped with your system, or did you compile the SDL libraries yourself?
Did anybody else encounter similar problems with recent Linux systems? I have seen this problem for the first time now...
![Shocked :shock:](./images/smilies/icon_eek.gif)
Re: Graphics problem under Arch Linux
I thought that I made an error installing this new Computer. For this reason I made a totally new Manjaro installation with KDE Desktop environment. But the problem persists! Using the repository version 4.1.4.1 of Rocks'n'Diamonds yield to the same strage non transparent behavior: see attachment
Downloading 4.1.4.1 from artsoft.org and starting just the delivered binary gives:
kh@fantasio:~/tmp/rocksndiamonds-4.1.4.1> ./rocksndiamonds
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri)
libGL error: failed to load driver: swrast
rocksndiamonds: warning: SDL_CreateRenderer() failed: Couldn't find matching render driver
rocksndiamonds: warning: SDL_CreateRenderer() failed: Couldn't find matching render driver
Speicherzugriffsfehler (Speicherabzug geschrieben)
Compiling this, the code works exactly like it does from the repo. And there is another strage effect:
when I am in the game all emeralds blink from time to time. Instead of the emerald you see a blink from three stars (third attachment, top emerald row, second from left).
Downloading 4.1.4.1 from artsoft.org and starting just the delivered binary gives:
kh@fantasio:~/tmp/rocksndiamonds-4.1.4.1> ./rocksndiamonds
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri)
libGL error: failed to load driver: swrast
rocksndiamonds: warning: SDL_CreateRenderer() failed: Couldn't find matching render driver
rocksndiamonds: warning: SDL_CreateRenderer() failed: Couldn't find matching render driver
Speicherzugriffsfehler (Speicherabzug geschrieben)
Compiling this, the code works exactly like it does from the repo. And there is another strage effect:
when I am in the game all emeralds blink from time to time. Instead of the emerald you see a blink from three stars (third attachment, top emerald row, second from left).
- Attachments
-
- Screenshot_20200512_155619.png (66.76 KiB) Viewed 18704 times
-
- Screenshot_20200512_102054.png (35.15 KiB) Viewed 18704 times
-
- Screenshot_20200512_102015.png (47.3 KiB) Viewed 18704 times
Re: Graphics problem under Arch Linux
I just installed a different desktop PC with Manjaro: a Intel core i3-4130T (my PC is a AMD Ryzen 3200G). So it is Intel HD 4400 Graphics as opposed to AMD Radeon Vega 8 Graphics. But there is the same Problem with Rocks'N'Diamonds. No transparency!
This Intel PC with Deepin Linux (a Chinese Debian, very nice!) works without problems. The repositories version is 4.1.1.0. But when I download the current 4.1.4.1 I can run the binary without any problem too.
So we have a Arch Linux / Manjaro Problem. Do you want me to ask this to https://www.archlinux.org/packages/comm ... ndiamonds/ Sergej Pupykin?
This Intel PC with Deepin Linux (a Chinese Debian, very nice!) works without problems. The repositories version is 4.1.1.0. But when I download the current 4.1.4.1 I can run the binary without any problem too.
So we have a Arch Linux / Manjaro Problem. Do you want me to ask this to https://www.archlinux.org/packages/comm ... ndiamonds/ Sergej Pupykin?
Re: Graphics problem under Arch Linux
> Do you want me to ask this to [Arch pkg maintainer] Sergej Pupykin?
Earlier you said:
> Compiling this, the code works exactly like it does from the repo.
So it is not a problem with the Arch central build system or packaging of RnD. It's a problem with tools (C compiler etc.) or libraries provided with Arch.
Given that, I'd say: yes, report it to the RnD package maintainer, but make sure to mention in your report that your own build has the same problem.
I would guess it must be some problem in their build of the SDL2 libraries: https://www.archlinux.org/packages/extra/x86_64/sdl2/ -- so you probably want to report it to both.
Or, build your own copy of SDL2 (https://www.libsdl.org/download-2.0.php), see if that fixes it. If so you have a 'smoking gun' you can report to the SDL2 package maintainer...
It could also be a fight between SDL2 and your video card driver.
Um. Another tack: find and run other SDL2 games, see if they have trouble. Not sure how viable this is: I find 3 SDL2-dependent items vs. ~240 SDL1-dependent items (mostly games or game frameworks) in my distro's package list. But it's LinuxMint 17.3 (vintage 2014) so maybe things have changed since then...
Earlier you said:
> Compiling this, the code works exactly like it does from the repo.
So it is not a problem with the Arch central build system or packaging of RnD. It's a problem with tools (C compiler etc.) or libraries provided with Arch.
Given that, I'd say: yes, report it to the RnD package maintainer, but make sure to mention in your report that your own build has the same problem.
I would guess it must be some problem in their build of the SDL2 libraries: https://www.archlinux.org/packages/extra/x86_64/sdl2/ -- so you probably want to report it to both.
Or, build your own copy of SDL2 (https://www.libsdl.org/download-2.0.php), see if that fixes it. If so you have a 'smoking gun' you can report to the SDL2 package maintainer...
It could also be a fight between SDL2 and your video card driver.
Um. Another tack: find and run other SDL2 games, see if they have trouble. Not sure how viable this is: I find 3 SDL2-dependent items vs. ~240 SDL1-dependent items (mostly games or game frameworks) in my distro's package list. But it's LinuxMint 17.3 (vintage 2014) so maybe things have changed since then...
Re: Graphics problem under Arch Linux
Oh, I just noticed that you reproduced the problem on both Intel & AMD IGPs, so it can't be a graphics hardware driver problem.
Holger, have you tested with SDL 2.0.12? According to https://discourse.libsdl.org/t/sdl-2-0- ... ased/27318, it was released just a couple of months ago. I bet this is a problem with bleeding-edge SDL2...
Holger, have you tested with SDL 2.0.12? According to https://discourse.libsdl.org/t/sdl-2-0- ... ased/27318, it was released just a couple of months ago. I bet this is a problem with bleeding-edge SDL2...
Re: Graphics problem under Arch Linux
filbo, you were right with your assumption about SDL 2.0.12: This seems to be the problem here.
Unfortunately, I am not able to test this directly on Linux (my build system is too old for recent SDL versions), but I was able to reproduce the problem on my Mac (running macOS 10.14):
- When using SDL 2.0.10, everything (especially transparency) works like a charm.
- When using SDL 2.0.12, I have the exact same problems with transparency as described (and shown) above.
(Note: Version 2.0.12 is the direct successor of version 2.0.10, as stable releases use only even numbers.)
And it seems I was also able to narrow the problem a little bit more: When drawing PNG images with alpha channel transparency (I have a test level set that uses a half-transparent image as a global animation on the main screen), this works just fine and as expected, but the default R'n'D images do not use alpha channel transparency, but simple "black pixels are transparent" style transparency (using SDL_SetColorKey()), and this apparently does not work correctly anymore in the current stable SDL version.![Sad :-(](./images/smilies/icon_sad.gif)
Unfortunately, I am not able to test this directly on Linux (my build system is too old for recent SDL versions), but I was able to reproduce the problem on my Mac (running macOS 10.14):
- When using SDL 2.0.10, everything (especially transparency) works like a charm.
- When using SDL 2.0.12, I have the exact same problems with transparency as described (and shown) above.
(Note: Version 2.0.12 is the direct successor of version 2.0.10, as stable releases use only even numbers.)
And it seems I was also able to narrow the problem a little bit more: When drawing PNG images with alpha channel transparency (I have a test level set that uses a half-transparent image as a global animation on the main screen), this works just fine and as expected, but the default R'n'D images do not use alpha channel transparency, but simple "black pixels are transparent" style transparency (using SDL_SetColorKey()), and this apparently does not work correctly anymore in the current stable SDL version.
![Sad :-(](./images/smilies/icon_sad.gif)
Re: Graphics problem under Arch Linux
Yesterday, I have filed a bug report for this issue, and it was immediately fixed the same evening!
For some more details (to whom it may concern), here's the corresponding bug report:
- https://bugzilla.libsdl.org/show_bug.cgi?id=2979#c17
(Unfortunately, the Bugzilla system throws a "500 Internal Server Error" as of this writing, but hopefully it will be available again soon.)
These are the commits that introduced the bug and that fixed the bug:
Bug was introduced by this commit (as of 10 Sep 2019):
- https://hg.libsdl.org/SDL/rev/0c66be754e29
Bug was fixed by these two commits (as of 17 May 2020):
- https://hg.libsdl.org/SDL/rev/5c4ad9fc7b21
- https://hg.libsdl.org/SDL/rev/c0689749d4b4
I have just tested the latest development version of SDL 2.0.13 from Mercurial, and R'n'D works just fine again with it.
Unfortunately, this does not make the current stable SDL 2.0.12 work, of course, which is apparently used by major Linux distributions. And I also cannot "fix" R'n'D for that broken SDL library (which would mean replacing all color-keyed PNGs by PNGs using alpha channel, but that's no practical solution, as it also affects all existing level sets with custom graphics, and also all the R'n'D stuff that people already have around on their harddisks).
So the only solution for Linux distributions that have SDL 2.0.12 packaged is to either wait for the SDL team to release the next stable version 2.0.14 some day, and then wait for your Linux distribution to package that version so you can upgrade to it. But honestly, I would not expect this to happen this year.![Sad :-(](./images/smilies/icon_sad.gif)
So the only practical solution is to compile the SDL library by yourself (either version 2.0.10 or current 2.0.13 from Mercurial). You don't have to recompile the other SDL libraries (like SDL_image), only the main SDL library (which in fact should work using a simple "./configure && make && sudo make install" in the SDL library's source code directory).
Sorry that I did not test the latest SDL version earlier (I simply missed that a new one was released last year) and unfortunately there are no frequent patch versions for bugs like this in the SDL library's release cycle, even though the major/minor/patch version scheme suggests something different. And there was no pre-release or bug-testing phase before the stable SDL 2.0.12 release this time (like they did for SDL 2.0.6)...![Sad :-(](./images/smilies/icon_sad.gif)
Apparently the only solution is to do frequent tests against the current development repository...![Sad :-(](./images/smilies/icon_sad.gif)
For some more details (to whom it may concern), here's the corresponding bug report:
- https://bugzilla.libsdl.org/show_bug.cgi?id=2979#c17
(Unfortunately, the Bugzilla system throws a "500 Internal Server Error" as of this writing, but hopefully it will be available again soon.)
These are the commits that introduced the bug and that fixed the bug:
Bug was introduced by this commit (as of 10 Sep 2019):
- https://hg.libsdl.org/SDL/rev/0c66be754e29
Bug was fixed by these two commits (as of 17 May 2020):
- https://hg.libsdl.org/SDL/rev/5c4ad9fc7b21
- https://hg.libsdl.org/SDL/rev/c0689749d4b4
I have just tested the latest development version of SDL 2.0.13 from Mercurial, and R'n'D works just fine again with it.
Unfortunately, this does not make the current stable SDL 2.0.12 work, of course, which is apparently used by major Linux distributions. And I also cannot "fix" R'n'D for that broken SDL library (which would mean replacing all color-keyed PNGs by PNGs using alpha channel, but that's no practical solution, as it also affects all existing level sets with custom graphics, and also all the R'n'D stuff that people already have around on their harddisks).
So the only solution for Linux distributions that have SDL 2.0.12 packaged is to either wait for the SDL team to release the next stable version 2.0.14 some day, and then wait for your Linux distribution to package that version so you can upgrade to it. But honestly, I would not expect this to happen this year.
![Sad :-(](./images/smilies/icon_sad.gif)
So the only practical solution is to compile the SDL library by yourself (either version 2.0.10 or current 2.0.13 from Mercurial). You don't have to recompile the other SDL libraries (like SDL_image), only the main SDL library (which in fact should work using a simple "./configure && make && sudo make install" in the SDL library's source code directory).
Sorry that I did not test the latest SDL version earlier (I simply missed that a new one was released last year) and unfortunately there are no frequent patch versions for bugs like this in the SDL library's release cycle, even though the major/minor/patch version scheme suggests something different. And there was no pre-release or bug-testing phase before the stable SDL 2.0.12 release this time (like they did for SDL 2.0.6)...
![Sad :-(](./images/smilies/icon_sad.gif)
Apparently the only solution is to do frequent tests against the current development repository...
![Sad :-(](./images/smilies/icon_sad.gif)
Re: Graphics problem under Arch Linux
Doesn't the SDL source have regression tests in it?
If not, trying to add one is probably out of scope (they won't accept); but if it does, can you provide them with a regression test in suitable form (i.e. in the right directory structure, right buildable form, mentioned in necessary Makefiles or whatever) -- so it'll be caught next time? Looking at the bug history, seems like they've had this at least 3x, maybe more.
Plus, at the same time, add to RnD code which implements the same regression test at startup and pops up a dialog on startup:
Uh-oh, transparency bug in SDL,
see [link to this post maybe].
Expect visual glitches.
[ ] Don't show this again
... meanwhile, you probably could fix it by shimming the PNG loader to convert color-key to alpha channel. Hmmm, in fact, it looks like you're already doing something similar in src/libgame/sdl.c:SDLLoadImage(), just need to 'upgrade' it a bit to defend against this class of bug? And maybe change SDLSetWindowIcon() to call SDLLoadImage() so it's also protected...
If not, trying to add one is probably out of scope (they won't accept); but if it does, can you provide them with a regression test in suitable form (i.e. in the right directory structure, right buildable form, mentioned in necessary Makefiles or whatever) -- so it'll be caught next time? Looking at the bug history, seems like they've had this at least 3x, maybe more.
Plus, at the same time, add to RnD code which implements the same regression test at startup and pops up a dialog on startup:
Uh-oh, transparency bug in SDL,
see [link to this post maybe].
Expect visual glitches.
[ ] Don't show this again
... meanwhile, you probably could fix it by shimming the PNG loader to convert color-key to alpha channel. Hmmm, in fact, it looks like you're already doing something similar in src/libgame/sdl.c:SDLLoadImage(), just need to 'upgrade' it a bit to defend against this class of bug? And maybe change SDLSetWindowIcon() to call SDLLoadImage() so it's also protected...
Re: Graphics problem under Arch Linux
Well, none that I know of. However, there is indeed a "test" directory in the SDL2 source repository, but as far as I can tell, these are merely meant to illustrate the use of various functionality provided by the SDL library, but not as automated (regression) tests (like my automated tape tests for the various R'n'D game engines).Doesn't the SDL source have regression tests in it?
![Sad :-(](./images/smilies/icon_sad.gif)
Yes, that would be my "minimal code example" I've attached to the bug report (and that I could reference again this time without any changes to illustrate the bug). Running this test only requires extracting the tar/gz file and running "make" inside the extracted directory, and it still works without errors or warnings with the current SDL library, showing the broken transparency and, this time, even prints out an appropriate error message:If not, trying to add one is probably out of scope (they won't accept); but if it does, can you provide them with a regression test in suitable form (i.e. in the right directory structure, right buildable form, mentioned in necessary Makefiles or whatever) -- so it'll be caught next time?
Code: Select all
holger@eriador:~/src/sdl_colorkey_problem$ make
gcc -g -o sdl_colorkey_problem sdl_colorkey_problem.c `sdl2-config --cflags` `sdl2-config --libs` -lSDL2_image
./sdl_colorkey_problem
::: GetColorKey() BEFORE SDL_ConvertSurface(): 0x00000000
SDL_GetColorKey() failed: Surface doesn't have a colorkey
make: *** [run] Error 10
holger@eriador:~/src/sdl_colorkey_problem$
So, yes indeed, the test would be ready to use as part of a regression test suite (this time even with an automated result "OK" or "ERROR", which was not the case the last time the bug occurred).
But I'm afraid that making this suggestion does not help much, as there seems to be no such regression test suite. But I will do that suggestion in the bug tracker nevertheless!
Yes, this is indeed the third time that this bug occurred.Looking at the bug history, seems like they've had this at least 3x, maybe more.
![Sad :-(](./images/smilies/icon_sad.gif)
As this bug is "detectable" this time (it wasn't the last time), I could indeed check for it and spit out a warning. I think this is indeed a good idea, as this version of the library will still be around for quite a while, unfortunately.Plus, at the same time, add to RnD code which implements the same regression test at startup and pops up a dialog on startup:
Not sure if this is possible, but maybe yes (and this would indeed be a great solution, errm, nasty workaround for this situation). The problem is here (in src/libgame/sdl.c:SDLLoadImage(), just as you wrote):... meanwhile, you probably could fix it by shimming the PNG loader to convert color-key to alpha channel. Hmmm, in fact, it looks like you're already doing something similar in src/libgame/sdl.c:SDLLoadImage(), just need to 'upgrade' it a bit to defend against this class of bug?
Code: Select all
// set black pixel to transparent if no alpha channel / transparent color
if (!SDLHasAlpha(sdl_image_tmp) &&
!SDLHasColorKey(sdl_image_tmp))
SDL_SetColorKey(sdl_image_tmp, SET_TRANSPARENT_PIXEL,
SDL_MapRGB(sdl_image_tmp->format, 0x00, 0x00, 0x00));
* alpha channel (as part of the image file)
* color key (color palette entry marked as transparent in the image file)
* nothing of the above, so we make all black pixels (#000000) transparent using "SDL_SetColorKey()"
So far I have no idea to internally convert affected images (well, that are at least all classic/default R'n'D image files) to alpha channel transparency (that's what SDL_SetColorKey() is used for), but I'll have a look.
Yes, good point.And maybe change SDLSetWindowIcon() to call SDLLoadImage() so it's also protected...
Re: Graphics problem under Arch Linux
OK, problem is solvable inside R'n'D! ![Very Happy :D](./images/smilies/icon_biggrin.gif)
The problem is in fact not in SDL_SetColorKey(), but in SDL_GetNativeSurface(), which does not take an existing color key from the source surface into the destination surface. So the solution is easy enough: Immediately after calling SDL_GetNativeSurface(), check if the source surface has a color key, but the destination surface didn't. If so, explicitly set the color key from the source surface also for the destination surface. The patch is quite simple:
That's it, and it shouldn't hurt if you have a correctly working SDL library.
![Very Happy :D](./images/smilies/icon_biggrin.gif)
The problem is in fact not in SDL_SetColorKey(), but in SDL_GetNativeSurface(), which does not take an existing color key from the source surface into the destination surface. So the solution is easy enough: Immediately after calling SDL_GetNativeSurface(), check if the source surface has a color key, but the destination surface didn't. If so, explicitly set the color key from the source surface also for the destination surface. The patch is quite simple:
Code: Select all
new_surface = SDL_ConvertSurface(surface, &format, 0);
+ // workaround for a bug in SDL 2.0.12 (does not copy color key)
+ if (SDLHasColorKey(surface) && !SDLHasColorKey(new_surface))
+ SDL_SetColorKey(new_surface, SET_TRANSPARENT_PIXEL,
+ SDLGetColorKey(surface));
Re: Graphics problem under Arch Linux
So more people will suffer from this bug, if other Distributions adapt this SDL-Version too. Holger: Can't you produce an application image from Rocks'N'Diamonds so that it can be played directly from the Download? Adding some very good Levelgroups with it, so the people must carry on playing:
Contributions 2003: Krystian Abromowicz, Paul E. Collins III
Contributions 2004: Dorothee Ebner, Andrzej Grzesik
Walpurgis Flashbacks (I never played untill the end...)
Well there are more. You want my top ten?
Regards
Karl-Heinz
Contributions 2003: Krystian Abromowicz, Paul E. Collins III
Contributions 2004: Dorothee Ebner, Andrzej Grzesik
Walpurgis Flashbacks (I never played untill the end...)
Well there are more. You want my top ten?
Regards
Karl-Heinz
Re: Graphics problem under Arch Linux
I just tried to recompile it applying this patch in libgame/sdl.c, but I get:
/usr/bin/ld: libgame/libgame.a(sdl.o): in function `SDLGetNativeSurface':
/home/kh/Dokumente/Programme/rocksndiamonds-4.1.4.1/src/libgame/sdl.c:355: undefined reference to `SDLSetColorKey'
collect2: Fehler: ld gab 1 als Ende-Status zurück
/usr/bin/ld: libgame/libgame.a(sdl.o): in function `SDLGetNativeSurface':
/home/kh/Dokumente/Programme/rocksndiamonds-4.1.4.1/src/libgame/sdl.c:355: undefined reference to `SDLSetColorKey'
collect2: Fehler: ld gab 1 als Ende-Status zurück
Re: Graphics problem under Arch Linux
Definitely yes. It will affect all SDL programs that convert surfaces with color keys for transparency.So more people will suffer from this bug, if other Distributions adapt this SDL-Version too.
![Sad :(](./images/smilies/icon_sad.gif)
I already do this, for all supported platforms. R'n'D always comes packaged with all SDL libraries known to work, for Windows, macOS, Android -- and also for Linux (in the "lib" sub-directory). The problem is that the shipped SDL libraries apparently do not work with your graphics card.Can't you produce an application image from Rocks'N'Diamonds so that it can be played directly from the Download?
Yes, you are right that I should put back those "Contributions" level packages (or a selection of it) back to the main game package!Adding some very good Levelgroups with it, so the people must carry on playing
![Smile :-)](./images/smilies/icon_smile.gif)
Please excuse me, the patch contained a typo -- fixed in my post! (And it should be put after checking if the new surface is valid, not before; this was just some sort of "pseudo code" to show what is needed after "SDL_ConvertSurface()".)I just tried to recompile it applying this patch in libgame/sdl.c, but I get: [nasty error]
Re: Graphics problem under Arch Linux
OK, the patch is now in the R'n'D repository -- just do a "git pull && make run" and enjoy! ![Very Happy :D](./images/smilies/icon_biggrin.gif)
![Very Happy :D](./images/smilies/icon_biggrin.gif)