Graphics problem under Arch Linux

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

Moderators: Zomis, Flumminator

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

Re: Graphics problem under Arch Linux

Post by khvolk » Wed May 20, 2020 6:15 am

ran into problem building it from the git. I recognized that I had to install the netpbm package. But after this I got (at the end of 'sudo make run'):

LSA lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave
rocksndiamonds: warning: Mix_OpenAudio() failed: ALSA: Couldn't open audio device: No such file or directory
rocksndiamonds: fatal error: IMG_Load('RocksBusy.png') failed: Unsupported image format
rocksndiamonds: aborting
make[1]: *** [Makefile:308: run] Fehler 1

sdl2_mixer is installed. Sound is ok. The unsupported image format - I don't understand...

User avatar
Holger
Site Admin
Posts: 3256
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Graphics problem under Arch Linux

Post by Holger » Wed May 20, 2020 7:36 am

Hm, this looks like both SDL_image and SDL_mixer are somehow broken on your system (SDL_image not being able to open PNG images, SDL_mixer not being able to open an audio device -- both warnings/errors are quite strange, as SDL_mixer really should be compiled with PNG support, and the PNG library should be installed, and SDL_mixer should use PulseAudio nowadays and not try to open /dev/dsp or whatever).

Could you please try to build all required SDL libraries from scratch? That is SDL, SDL_image, SDL_mixer and SDL_net. It should be just downloading, extracting and "./configure && make && sudo make install". (For SDL_mixer, it might be possible that you have to manually activate support for MOD, MP3 and MIDI, but this would only require removing a comment sign ("#") in front of the appropriate directives.)

Then rebuild R'n'D, and everything should work fine.

Which system did you encountered these problems on? Was this Manjaro? Which version?

Is it an option to test this with a more "standard" Linux distribution, like Ubuntu 18.04 or 20.04 (using a live CD, for example)?

I'm curious if the problems you encountered are system (hardware, graphics card etc.) dependent, or if this is a problem with maybe "badly" packaged SDL libraries of the distributions you used. :?

Regarding the "netpbm" package required for building from Git: Yes, I also came to the conclusion that it may be only the second best idea to use IFF/ILBM files in 2020... I should put the resulting PNG files into the repository to prevent the hassle of dealing with ancient image file conversion... :D

filbo
Posts: 374
Joined: Fri Jun 20, 2014 10:06 am

Re: Graphics problem under Arch Linux

Post by filbo » Wed May 20, 2020 8:41 am

> second best idea to use IFF/ILBM files in 2020... I should put the resulting PNG files into the repository to prevent the hassle of dealing with ancient image file conversion... :D

I was going to object that some old levels might also use IFF, but -- well, none in my huge collection do...

In fact, looks like graphics/gfx_classic/Makefile converts *.ilbm to *.png, except it needs help from code in RnD to expand the template for custom elements. Is there something special about RocksCE-template.ilbm that wouldn't work if it were RocksCE-template.png (pcx, bmp, whatever) in the first place? The thing where the makefile runs RnD to emit the .bmp CE image, then converts it to .ilbm, so the next target can convert it to .png, is ... funky :)

===

Unrelated, but I was reminded by doing `git pull` and then comparing remaining diffs in my tree: I have in src/events.c,

Code: Select all

     fprintf(program.log_file_default[LOG_ERR_ID], "%s", newline);
+#if !defined(PLATFORM_WIN32)
+    fprintf(program.log_file_default[LOG_ERR_ID], "%s", "\r");
+#endif
which actually might be much better expressed as:

Code: Select all

-    fprintf(program.log_file_default[LOG_ERR_ID], "%s", newline);
+    fprintf(program.log_file_default[LOG_ERR_ID], "%s", STRING_NEWLINE_DOS);
(or even more explicitly "\r\n", or STRING_NEWLINE_UNIVERSAL or something...)

The point of this is: this is writing to stderr, to a terminal; and my terminals spend a lot of their time in raw mode where plain newlines cause stairstepping (specifically: sitting in `vim` editing something or other). It is not harmful to emit CRLF to a Unix terminal when LF would have been sufficient, and sometimes it is anyway not sufficient.

[the other remaining diff is an added:

Error(ERR_INFO, "GetKeyModState() = %x, KMOD_Valid = %x, masked = %x\r",GetKeyModState(),KMOD_Valid,GetKeyModState()&KMOD_Valid);

in src/events.c:HandleKeysDebug(), because I am *still* having occasional cases where some modkey gets 'stuck on' as far as RnD is concerned, causing number keys to change the game speed when I'm not holding any modifier...]

Post Reply