Graphics problem under Arch Linux

Discussion about Rocks'n'Diamonds, Boulder Dash, Supaplex, Emerald Mine and any other BD hybrid.

Moderators: Flumminator, Zomis

khvolk
Posts: 10
Joined: Sat Jul 26, 2008 9:26 am

Graphics problem under Arch Linux

Post by khvolk »

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
Attachments
Screenshot_20200511_114137.png
Screenshot_20200511_114137.png (57.3 KiB) Viewed 12563 times
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger »

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... :shock:
khvolk
Posts: 10
Joined: Sat Jul 26, 2008 9:26 am

Re: Graphics problem under Arch Linux

Post by khvolk »

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).
Attachments
Screenshot_20200512_155619.png
Screenshot_20200512_155619.png (66.76 KiB) Viewed 12543 times
Screenshot_20200512_102054.png
Screenshot_20200512_102054.png (35.15 KiB) Viewed 12543 times
Screenshot_20200512_102015.png
Screenshot_20200512_102015.png (47.3 KiB) Viewed 12543 times
khvolk
Posts: 10
Joined: Sat Jul 26, 2008 9:26 am

Re: Graphics problem under Arch Linux

Post by khvolk »

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?
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Graphics problem under Arch Linux

Post by filbo »

> 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...
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Graphics problem under Arch Linux

Post by filbo »

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...
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger »

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. :-(
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger »

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. :-(

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)... :-(

Apparently the only solution is to do frequent tests against the current development repository... :-(
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Graphics problem under Arch Linux

Post by filbo »

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...
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger »

Doesn't the SDL source have regression tests in it?
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). :-(
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?
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:

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$ 
When skipping the function to show the color key, the program runs "normally", but shows the missing transparency.

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!
Looking at the bug history, seems like they've had this at least 3x, maybe more.
Yes, this is indeed the third time that this bug occurred. :-(
Plus, at the same time, add to RnD code which implements the same regression test at startup and pops up a dialog on startup:
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.
... 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?
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):

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));
There are the following three cases to achieve transparency in images loaded by R'n'D:

* 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.
And maybe change SDLSetWindowIcon() to call SDLLoadImage() so it's also protected...
Yes, good point.
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger »

OK, problem is solvable inside R'n'D! :D

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));
That's it, and it shouldn't hurt if you have a correctly working SDL library.
khvolk
Posts: 10
Joined: Sat Jul 26, 2008 9:26 am

Re: Graphics problem under Arch Linux

Post by khvolk »

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
khvolk
Posts: 10
Joined: Sat Jul 26, 2008 9:26 am

Re: Graphics problem under Arch Linux

Post by khvolk »

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
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger »

So more people will suffer from this bug, if other Distributions adapt this SDL-Version too.
Definitely yes. It will affect all SDL programs that convert surfaces with color keys for transparency. :(
Can't you produce an application image from Rocks'N'Diamonds so that it can be played directly from the Download?
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.
Adding some very good Levelgroups with it, so the people must carry on playing
Yes, you are right that I should put back those "Contributions" level packages (or a selection of it) back to the main game package! :-)
I just tried to recompile it applying this patch in libgame/sdl.c, but I get: [nasty error]
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()".)
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger »

OK, the patch is now in the R'n'D repository -- just do a "git pull && make run" and enjoy! :D
Post Reply