SFML community forums
Help => General => Topic started by: pwnstar23 on December 23, 2012, 11:43:13 pm
-
Is it safe to use the classes that you use to instance things like Sound and Sprite? Of course you don't want to with the Texture and SoundBuffer classes.
I am using them in std::vector and I know that from time to time vector will move them around, and when I want to erase one, i swap it with the last one then pop_back() the last one, is this going to cause trouble?
Second issue that maybe related to the first.
I have a std::vector<Sound>, when ever i want to play a new sound like a laser shot, i create a Sound and use the laser sound buffer to construct the sound. Then I call push back it into the vector and then use back().play().
I a loop to check the status and if the status of one of these sounds is stopped then I swap it with the last one then pop_back() to remove it.
However occasionally one of the sounds doesn't play when it should and sometimes one seems to get cut off. Is the use of vector messing them up or something else my problem?
-
I'm not sure reagarding sf::Sound but I know that having a std::vector<sf::Texture> can cause problems, because the address of the texture changes when the vector gets reallocated in memory.
It's probably better for both sf::Texture and sf::Sound to use std::vector<std::unique_ptr<sf::Texture/sf::Sound>> or if it shall be shared, shared_ptr.
-
I did what you said made them unique_ptr's now it seems to work fine, hasn't hiccuped yet. Guess that means I should use pointers for the Sprites to, just to be safe.
-
Guess that means I should use pointers for the Sprites to, just to be safe.
No you don't have to use smart pointers for the sprites. They are a light-weighted class and as long as the address of the referenced texture doesn't change, everything should be fine.
The reason why you should use smart pointers for sf::Texture and sf::Sound, is because they are resources which others depend on, so a simple address change isn't nice, since they get already referenced by other objects. ;)
-
Guess that means I should use pointers for the Sprites to, just to be safe.
No you don't have to use smart pointers for the sprites. They are a light-weighted class and as long as the address of the referenced texture doesn't change, everything should be fine.
The reason why you should use smart pointers for sf::Texture and sf::Sound, is because they are resources which others depend on, so a simple address change isn't nice, since they get already referenced by other objects. ;)
Are you confusing sf::Sound with sf::SoundBuffer ? I replaced sf::Sound using a smart pointer and it did fix my issue even though it isn't the buffer like sf::SoundBuffer and sf::Texture are. Unless I am mistaken?
-
Are you confusing sf::Sound with sf::SoundBuffer ?
Yes I was confusing them, but it makes also sense for sf::Sound to use a std::unique_ptr, because sf::Sound needs to be kept alive as long as the sound is playing. You then can't directly compare it to sf::Sprite, since sf::Sprite is only needed for drawing things and for instance can be used temporarily: window.draw(sf::Sprite(texture));.
Which IIRC doesn't work with sf::Sound. ;)
-
For sound effects, a queue is a nice data structure. You push new sounds to the back, and pop stopped ones from the front. Since std::queue bases on std::deque, which guarantees that insertions and removals of single elements at either end keep references valid (ยง23.3.3.4/4), the sf::Sound objects won't be relocated while playing.