The biggest error was to be mistakenly convinced that due to the presence of the 'if (!buffer.loadFromFile("..."))' the buffer of the sound wouldn't be not only damaged but also repeated or born from zero.
That is precisely the reason
"if (sound.getStatus() != sf::Sound::Playing)
sound.play();
"
that brillantly was suggested gets its purpose defeated
Not really.
Your biggest error (to use your own words) here is to not realize a very basic C++ fact; that objects created in a scope, on the stack, get destroyed when that scope (in this case, the game loop) ends. This is very fundamental C++ knowledge and, had you had that knowledge, it would/should have made it obvious that the "sound" object would not live for more than a single frame. The
if statement testing whether or not the sound is currently playing is completely irrelevant in that context.
Having read the system module, etc. I tend to think that the position of the main loop is for facilitate, among other things, space for events (through the event loop itself) and that's the reason you must not integrate the bulk of the code into the main loop.
But then it arises the question of what about the supervisor ( ...is that the name for the loop in wich the course of the game takes place? ).
The main "game" loop is what (in most games) drives everything. It is responsible for processing events, updating game state and rendering the current state of the world. It's what makes the game "
tick".
The main game loop repeats over and over - every frame - and it's where you do all your processing. But, that doesn't mean that you need to create all objects
within the loop. Long lived objects usually get created before the loop and persist for the entire lifetime of the application. Objects that need to be dynamically created (but need to live more than a single frame) are usually created on the heap and stored as std::unique_ptr or std::shared_ptr objects - commonly in STL containers like std::vector or similar.
Anyways, I want to think that if the buffers are not destroyed, the sound variables are available, and not only that, if there is playing any music, it arrives to the end if no method interrupts it.
You may think what you want. But that's just not good enough. You need to
know how the lifetime rules for objects in C++ work.
As long as your sound object is alive and there's something to play in its buffer and play() has been called on it, it will play. But if you destroy the object (for example; by letting it go out of scope) or destroy the buffer it's playing from, then - surprise, surprise - it will stop playing.
Another question is if you include all this in a thread and that thread is affected by something.
Music already plays in its own thread. You don't need to worry about that... Please, please don't even
consider threads until you have a
much firmer grasp of C++ (I'd say at least 5 more years of experience or so).
Am I in the right track?.
Personally, I'd say no.
You seem to be guessing randomly and making assumptions that you have no basis for.
You should attempt to get a firmer grasp of the C++ language before proceeding or you'll only get yourself into trouble that you'll have no idea how to dig yourself out of.
