The erase function requires an iterator to tell it which one to erase. In your code:
m_SoundV.erase(m_SoundV[i]);
m_BufferV.erase(m_BufferV[i]);
the value you are passing to erase is the actual sound or soundbuffer object, not an iterator to it.
An iterator is like a pointer, it's an object made to move through containers. STD likes them a lot.
Given an index number i, you can turn it into an iterator by adding it to another iterator, like begin(), which is the iterator of the first thing in the deque:
m_SoundV.erase(m_SoundV.begin()+i);
m_BufferV.erase(m_BufferV.begin()+i);
I find iterators to be annoying, but there are some containers (maps, lists) that can't be used with an index number lookup the iterator has extra logic for them to step 1 at a time.
Something that can go wrong with erasing is values move down to fill the gap. If you erase at position 5, whatever was at position 6 will now be position 5 and so on. Your code is ok, since it returns immediately after the erasing, it doesn't keep stepping through the deque. But it does mean you can only stop one sound each time. If several stopped, it takes one pass for each. The way around that is to make it take a step back if it erases. So if you erase at position 5, you need to check 5 again since a new item is there now. A bit like this:
for(int i=0;i<m_soundV.size();++i)
{
if (m_SoundV[i].getStatus() == sf::Sound::Stopped) {
m_SoundV.erase(m_SoundV.begin()+i);
m_BufferV.erase(m_BufferV.begin()+i);
--i;
}
}
This way the --i takes a step back, to counteract the ++i step forwards in the loop, so if anything is erased, you won't skip the next one, they all get checked.
The parts about templates you've written look like you meant typedefs. There's no need to make any templates for an std::deque, it already is one.
A typedef lets you give an alternative name to a type, usually to make it easier to use.
typedef sf::Sound S;
std::deque<S> m_SoundV;
In that code, S is another name for sf::Sound. Or you could shorten it even further:
typedef std::deque<sf::Sound> S;
S m_soundV;
Now S is the entire deque type.
But none of these are actually needed, they just reduce your typing if you use std::deque<sf::Sound> a lot.
I think that's what you meant there.
Anyway, one little SFML optimisation tip. SoundBuffers are large, they could take megabytes each (they are raw uncompressed audio, like a WAV file). Sounds are tiny. You can have many Sounds all sharing a single SoundBuffer. If 100 gunshots are playing at once, you can have 100 Sounds and 1 SoundBuffer. So usually you don't remove a SoundBuffer, you keep it around, since making a new one uses a lot of memory and slows down to read the file from disk again.
The same with sprites and textures, you can have hundreds of Sprites all using 1 Texture.
Show Posts
