Faerie Solitaire Windows, Mac, Linux game

You should actually have enough to run it.
It really isn't a demanding game graphicly.
It might have something to do with your Linux builid there.
Perhaps you don't have something installed that the game needs.
I'm no Linux expert reallly.

Goto the developer's website and send them an email. I'm sure they could help you sort out the requirments for running in linux.

I did go to the developer, and their solution was to give me access to the Windows version, which was okay in the long run, because I have an older (P4-3.0, 2G, 7600GT) box running XP on the same desk as my Linux box, and it has no problems with the game. The developer did suggest a log file to check, but it showed nothing abnormal, and that was the last I heard from them.

<whiner mode>But there must be a dependency that isn't being met. Trouble is, Mint13 is based on the current ubuntu, which is about as mainstream as Linux gets. If there is an unusual requirement, one would think it would be identified before public release. Desura has been quite a disappointment in this regard. The whole reason I migrated to Mint13 was because of an also unidentified at the time of purchase dependency, for the first game I purchased.

Not listing the first hardware or software requirement for products that are being paid for, even if they are budget priced, is still bad business in IMO. But when you are the only game in town, who cares? Apparently.... </whiner mode>

I'm running an older version of Linux than you (openSUSE 11.4) and had no troubles. That said, maybe we could figure it out. Have you run it from the command line to see what error messages it gives?

Thanks for the response. While I've been enjoying my minty linux machines for several years now, I am embarrassed to say that I remain a bit of a n00b when it comes to the terminal. As in I didn't know how to run an executable, because i'd never had the need to I guess. So I looked up how, and tested my new skill on a known functional game, and it worked fine, so I tried it with faerie, this is what came back:

carl@DuoboxMint13 ~/Downloads/Desura/desura/common/faerie-solitaire $ ./FaerieSolitaire
Starting up player...
Error loading libfluidsynth.so.1: libfluidsynth.so.1: cannot open shared object file: No such file or directory
Error loading libdumb.so: libdumb.so: cannot open shared object file: No such file or directory
Error loading libmpg123.so.0: libmpg123.so.0: cannot open shared object file: No such file or directory
(mmfparser took 1.90545296669)
(unknown chunk 8775)

My searches and the Synaptic Package Manager confirm that I do not have any one of those 3 libraries. Could my solution be as simple as installing one, or do i need all three? I'm encouraged already...

That's perfect. You should be able to find the packages "mpg123" and "libfluidsynth1" in Synaptic. The only thing I could find on LibDump is a project page on codeguru describing it as "LibDump is a Win32 utility tool similar to Microsoft's DumpBin utility except that it can be used to display the contents of library files instead of portable executables and COFF (Common Object File Format) .OBJ files." Oddly enough, I don't even have it myself and it's nowhere in the faerie-solitaire directories, so I'm guessing it's not absolutely necessary.

Try installing those two packages and giving it a run.

Note to developer: Both of the above libraries (I'm not sure about LibDump) are released under the LGPL, so it's possible to distribute them with your closed source game under provisions.

Thanks for continuing pursuit on this with me! I found and installed libfluidsynth1 and libmpg123, as well as mpg123. I also found and installed one called libdumb1, since it was game/music-related like the other two, and sure enough, in my usr/lib directory I now have libdumb.so.1 (a link) and libdumb.so.1.0.0

This is what I get when I run from the terminal now:

carl@DuoboxMint13 ~/Dow...ura/desura/common/faerie-solitaire $ ./FaerieSolitaire
Starting up player...
Error loading libfluidsynth.so.1: /home/carl/Downloads/Desura /desura/common/faerie-solitaire/FaerieSolitaire data/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/i386-linux-gnu/libjack.so.0)
Error loading libdumb.so: libdumb.so: cannot open shared object file: No such file or directory
(mmfparser took 3.10800504684)
(unknown chunk 8775)

I'm stuck on the libdumb issue, but the libfluidsynth1/libstdc++ issue I dug into some. The file is there, but I don't know about how to check versions like the error mentions, but just for giggles I tried something I saw about checking versions and (from within the "FaerieSolitiare data" folder) I ran this command in the Terminal.

LD_DEBUG=versions libstdc++.so.6

That output many screens worth of information, but one line that caught my eye was this one:

3394: checking for version `GLIBCXX_3.4.15' in file /usr/lib/i386-linux-gnu/libstdc++.so.6 [0] required by file /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12 [0]

I have no idea if this is helpful information, but I noticed the LD-DEBUG checked a libstdc++.so.6 file that was in usr/lib/i386-linux-gnu, even though I ran the command from within the "FaerieSolitaire data" folder. The two files are not the same. The Faerie... one is 930kB dated 26 Dec 2011. The one in the usr/lib/i386-linux-gnu is 905.7kB, dated 15 Apr 2012, and is actually a link to one in the same folder called libstdc++.6.0.16 (continued...)

(...continuation of previous comment) Figuring I couldn't destroy things too badly I decided I would try copying the newer one to the Faerie folder, so (as root) I did, renamed the original one, and then (after changing the permissions to match the original) I renamed it without the last .0.16 and tried to run the game again. Progress!

carl@DuoboxMint13 ~/Downloads/Desura/desura/common/faerie-solitaire $ ./FaerieSolitaireStarting up player...
Error loading libdumb.so: libdumb.so: cannot open shared object file: No such file or directory
(mmfparser took 1.95084404945)
(unknown chunk 8775)

Sorry about the overly long typed-as-I-went post. Any suggestions at this stage? Thanks!

Okay, I just tried it myself from the command line and this was the output:

Starting up player...
Error loading libfluidsynth.so.1: libfluidsynth.so.1: cannot open shared object file: No such file or directory
Error loading libdumb.so: libdumb.so: cannot open shared object file: No such file or directory
(mmfparser took 10.1572680473)
(unknown chunk 8775)
AL lib: pulseaudio.c:485: Context did not connect: Connection refused

It still ran exactly as it should. I should explain that last line: I removed pulseaudio for numerous reasons. Doesn't matter. I still had sound, so it tries it if it's there and then just sends to the audio device otherwise. This is what it should do, so no problem.

Have you tried simply running it from Desura now that you've made those changes? How long do you wait once you see the output you described before giving up?

And I don't mind long posts. People who don't like reading should watch TV. The internet is not good for avoiding reading.

*edit: The mention of pulseaudio was in no way meant to advise removing pulseaudio. I seriously doubt that this is the problem.

Hmmmm, well I guess the good news is I'm getting practice debugging and fixing issues with missing libraries. The not so good news is, they were probably not the problem. Argh.

Using a similar technique I have managed to get rid of the libdumb error also, so now when I run it all I see id the Starting player, and about 5 seconds later, the mmfparser and chunk 8775 lines, and then the command prompt returns. If I have the System Monitor running, I can see it go to 100% CPU usage for about 3 seconds, and also the RAM usage starts to increase, but after the few seconds both drop back to idle state. A process called "runtime" is the only one that shows up on that list, and it disappears after the 3 or 5 seconds too. Symptoms are identical run from the command prompt or from with in Desura.

I am using two monitors, I wonder if that could be the issue. It's way too late for me to try that now, maybe tomorrow... Thanks for your help so far!

I also have dual monitors, using nVidia's TwinView. The only issue with that is that trying to make it fullscreen does funky stuff to it unless I change to a metamode where one monitor is off. So I play in windowed mode. Beyond that, though, no issues. Not saying it's not worth considering, just that in my case it's okay.

There seems to be an error log in the "FaerieSolitaire data" directory called "anaconda.log". Does that suggest anything to you?

This might sound a bit random, but if you know how, look through .settings (the period at the beginning is important) within the main desura directory with `ls -l` and make sure the ownership/permissions look right. Don't do anything else to the files. I've never had this problem with Desura, but if I'm having trouble figuring out why something's not running, it's just habit for me to look at permissions to see if I or some errant program has done something funky to them. I don't think it's likely here, but if you already know what to look for and it wouldn't be a huge pain, it doesn't hurt.

Well, tonight I went 0 for 2. The anaconda.log was just a log of whatever the Terminal generates, so all it had was the same old Starting player...mmfparser...chunk8775.

I checked around in the .settings folders, and every file in there was owned by me, except for one link to a libopenal.so.?(I forget) that was owned by root, but it was in a numbered subfolder that was not the one for FaerieSoli. (I looked into Faerie's desura_launch_Play.sh file and was able to determine which folders it's lib files were expected to be in.) Just for fun, I changed the permissions to own it myself anyway, but to no avail, same exact responses (or lack thereof...) as before.

Grasping at straws, I also tried running it from the Terminal as sudo, but nothing new that way either. Earlier I had used the Desura app to "Verify Files" for the game, and that apparently worked, because it replaced my hacked libstdc++.so.6 with the original one again, leading to the same can't find version error I had prior to the hack.

I'm just about frustrated by now. How about you? As usual, thanks again for your time and assistance, I'm learning all kinds of new things, even if this problem is still unsolved!

I'm a stubborn SOB. Not ready to give up quite yet.

I looked again at what you had written before about libstdc++. At the time, I hadn't yet looked and saw that I get the same output as you but for that and it didn't really hit me. It looks like the game is trying to use JACK audio. So you obviously have JACK installed. I don't know if you have it running or not.

Do you have pulseaudio installed? If so, try running the game with the command:

padsp FaerieSolitaire

If you do not have pulseaudio installed or don't have it running, try:

aoss FaerieSolitaire

That second one emulates the old Open Sound System which has long since been deprecated, but I'm hoping (and this is really just a guess) that it'll force the game to try going straight to ALSA's dsp. Mainly, I'm wondering if the attempt to use JACK is what's messing it up. I do have JACK installed, but I only run it when I'm playing or recording music. Anyway, it's a stab in the dark.

Ladies and Gentlemen, we have a winner! I do have pulse audio, and while padsp FaerieSolitaire gave an error, ( /usr/bin/padsp: 88: exec: FaerieSolitaire: not found ) when I added the full path to Faerie by running:
padsp ~/Downloads/Desura/desura /common/faerie-solitaire/FaerieSolitaire (without the space)
it started up just like it should. Hooray! Success! Your knowledgeable assistance, stubbornness, and patience are greatly appreciated!

Now if I could just ask one more favor... (or favour, as my Minty spell checker suggests) Maybe it's actually two. 1) Why did I not need to put the "./" before padsp ...? and 2) What exactly was I doing with that command, running Faerie from within pulse audio? Or forcing pulse audio to take control of the audio and executing Faerie after that? or...?

Next I guess I just need to mod the little starter file Desura uses and/or make a Launcher and I will be free and easy after that! Thanks very much again for your assistance!

You're very welcome. I'm glad we could get it working.

DSP basically means a sound card or device. Before pulseaudio, Linux software that produced sound would send its sound output to ALSA's dsp. ALSA gives them basic device names like dsp0 for the first sound card/device, dsp1 for the second, etc. Whichever one ALSA is told is default is the one the output gets sent to. But most sound devices don't natively handle multiple sound streams at the same time, so without software mixing only one program could hold the dsp at any one time. ALSA does have a primitive software mixer, but it usually wasn't enabled by default on most distributions for latency reasons and most didn't even know it was there. A few noble, but bad attempts at sound servers (like esd and aRTs) were made until the pulseaudio project began. pulseaudio grabs the sound device then allows programs that use it to pipe everything to pulseaudio, which then mixes the signal and sends it to the dsp.

But software that wasn't written to work with pulseaudio won't find it and won't play sound because pulseaudio is holding the dsp. So pulseaudio gives you the nifty utility padsp that takes another program as an argument, and tries to trick that program into seeing pulseaudio *as* the dsp, so it sends sound to it instead of ALSA.

I guess this is the problem with Faerie Solitaire on Linux and it also explains why I didn't have the problem. To be fair, it's not pulseaudio's fault. I don't like pulseaudio and use an old SoundBlaster with a hardware mixer so I don't need it, but it does exactly what it set out to do and makes Linux audio a heck of a lot easier for most users. In this case, it's really the developer who should make sure their Linux port checks for pulseaudio.

By the way, that's why the Windows version works in Wine when the native version does not: current versions of Wine are made to look for pulseaudio and anything running through Wine will send audio to the right place because of it.