Closed Fyll closed 9 years ago
Actually, I messed around with my freealut install, and (after breaking everything) somehow got it to compile with the sound functions left in. So I do compile OpenAL now, it just doesn't work. I get a 'shhhhh' noise in my headphones, so audio has been initialized, it just isn't sending any data.
Hmm. I don't really know how OpenAL works, I just nabbed it from an old project of mine, so can't really help you out.
Also, if you had this much difficulty installing it, it won't be very user friendly.
I sort of assumed we would eventually move past the 'handing people source code' stage.
OpenAL was already installed, the problem was Alut. Is there any way you can work round that?
Ok, I've found the problem, though the solution eludes me. OpenAL isn't initializing properly, because it can't find any devices. Which is really strange, I have to say.
alcGetString(NULL, ALC_DEVICE_SPECIFIER)
Is supposed to return a list of all audio output devices. Apparently the Mac implementation is bugged so it only returns the default device, but I'm not even getting that. I couldn't find anyone else mentioning the same error, so it may just be me. I've had problems with my sound card before.
As you may have noticed, I've ifdef'd Sound into what is essentially two separate classes. The linux one (and Windows, presumably) is free to continue as it is. At some point, I'm going to get the Mac one working with Apple's CoreAudio framework.
The idea is to encapsulate sound such that the same function calls can be used, but have them access different frameworks within the class. Hopefully that's possible...
Should be doable. I just don't know anything about Mac architecture (or any other architecture for that matter...), so can't really do much more than point at what I've written and look happy. :)
Coming back to this, we could give this a whirl: http://www.sfml-dev.org/
It's a cross-platform, open source multimedia framework for C++. There's also instructions for integrating with cmake, so building should be straightforward (especially compared to the nightmare that was getting openAL to integrate).
Hmm. I'm not sure how I missed this way back when....
Either way, I downloaded SFML and managed to get it working. It's not as efficient as it could be (I only wrote this quickly, so it streams everything), and I may have sworn at the cmake file a few times, but it's all running fine on this end. If you could try it out on your Mac, David, that'd be nice (you may have to install SFML).
It's also really compact, which is a nice bonus.
Apparently, SFML can also handle windows, so it may be a nice idea at some point to shift everything off of SDL and all onto SFML (which should simplify the dependencies a bit). I'd have to look into SFML's capabilities first, so I'll leave it for now though.
Also, apparently no one had noticed that the background music wasn't set to repeat. None of us played with the audio on for more than 1m 25s....
SFML is pretty cool. I was playing around with it around Easter and came to like it a lot. It's basically a multimedia library. Also, there are views, that do something similar to what our Screen class currently does.
EDIT: And Vector classes that do what our Vector class does. EDIT2: Iain did you use the FindSFML cmake file when you were compiling with SFML? If so I think you forgot to add it to the repo.
It does seem to be able to do quite a lot, but it's just... Bleh. I'm feeling far too lazy at the moment to try to shift everything over to using a new system.
Replacing Vector is something I really can't see the point in doing, not out of lazyness or a stubborn refusal to upgrade to better things, but because the flexibility of being able to add functions and whatnot to Vector is quite nice, and I don't imagine it'd really save anything in terms of efficiency or readability.
Screen's going to be used (probably) to manage the parallaxing on the background. I don't think (from my quick cursory glance) that views have that built in, so would need a wrapper, which is just basically back to Screen.
Sure, we don't have to migrate everything over, but there's always the option.
From what I remember SFML uses it's own Vector type in much of the graphics code. We could get around this fairly easily by just having our Vector inherit from SFML::Vector2
We could make this a long term goal, but I agree there's no pressure and we certainly shouldn't change over SFML just for the sake of it.
"If you could try it out on your Mac, David, that'd be nice (you may have to install SFML)."
I have installed it and compiled with it. No problems with actually getting it to compile. I do get a list of errors though (missing functions and suchlike). Does it run for you currently? If so, it's possible that there's still Mac specific code I need to redo.
The crux of the problem seems to be that you're using functions with capitals, but the library I have uses camel case. (eg. your code has OpenFromFile instead of openFromFile). Is the linux library different?
Oh. Having just checked, the Linux ones also use camel caps. The problem seems to be that I downloaded the 32 bit version, which uses All-First-Caps. Unfortunately, I have a 32 bit computer. I smell preprocessor code approaching...
Huh. The Mac one is a universal binary. Is there not one for Linux?
Nope. Two different ones: http://www.sfml-dev.org/download/sfml/2.3/
You didn't install using the package manager then?
This is all a little odd. The official source code uses camel case: https://github.com/SFML/SFML/blob/master/include/SFML/Audio/Music.hpp#L79, as do the docs: http://www.sfml-dev.org/documentation/2.0/classsf_1_1Music.php#a3edc66e5f5b3f11e84b90eaec9c7d7c0.
Actually... I believe I used the terminal (sudo apt-get install whatever). Looking at the 32 bit distribution on that link, it must have just installed an old version. I appear to only have up to version 1.6 on synaptic (which is apparently the version I have installed). I'll try using the tarball from the link (someone else can change the capitalisation if they want. EDIT: Never mind, I've pushed it now).
I've fixed the capitalisation, and I've added a FindSFML.cmake file to the repo. It now compiles for me without issue. It also runs well, until you quit, at which point I get the following message printed repeatedly to the screen:
An internal OpenAL call failed in SoundStream.cpp (362) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
I've just pulled and I still don't get this. Does it happen every time?
I tried it twice and it happened twice. I've since tried again, and now I get this:
AL lib: (WW) FreeContext: (0x32f5340) Deleting 1 Source(s)
AL lib: (WW) FreeDevice: (0x3338300) Deleting 3 Buffer(s)
An internal OpenAL call failed in SoundStream.cpp (278) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
An internal OpenAL call failed in SoundStream.cpp (357) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
An internal OpenAL call failed in SoundStream.cpp (284) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
An internal OpenAL call failed in SoundStream.cpp (285) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
An internal OpenAL call failed in SoundSource.cpp (64) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
An internal OpenAL call failed in SoundSource.cpp (65) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
Perhaps there's some step required to finalize the sound device before the program quits?
Maybe try putting an iterator through all of the tracks in the vector, telling each to stop and then deleting them, inside Sound::~Sound()?
Well, you're one up on me. I get a compiler error now.
Undefined symbols for architecture x86_64:
"sf::SoundStream::play()", referenced from:
Sound::open(std::1::basic_string<char, std::__1::char_traits
@DivFord: Maybe try adding "-stdlib=libstdc++" in with the CMAKE_CXX_FLAGS in the makefile - http://stackoverflow.com/questions/19637164/c-linking-error-after-upgrading-to-mac-os-x-10-9-xcode-5-0-1.
@Fyll Hmm that made no difference. The tracks should be automatically deleted as they're in a unique_ptr, but stopping them in the destructor didn't help.
@mspraggs: A few ideas:
true
to a false
(whether or not it should loop). Then run the program and wait for the BG music to stop, then quit. Do you still get the error? While this isn't a fix, it might help solve things. EDIT: Actually, you'd get the same effect by just commenting that line out, then firing a gun a few times before quitting (as the BG music is the only sound that loops).@mspraggs: Actually, I've redone the sound a bit (short sound effects now use sf::Sound, so should be more efficient). Maybe try pulling and seeing if this new version has the same error messages?
@DivFord: This'll probably have just added more error messages for you... :(
All good!
Eventually we should sort out sound so it can play on any machine. OpenAL has proven itself to not be up to the task, so, any ideas?
What's nice is that the sound is almost entirely self contained, so if anyone wants to try any alternatives out, they need only change one file (hint hint).