Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Many sounds for a game.  (Read 3507 times)

0 Members and 1 Guest are viewing this topic.

Strikerklm96

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
    • Email
Many sounds for a game.
« on: February 22, 2015, 02:15:24 am »
I see that the max number of sounds is 256, but in the game i'm making, there are more than 256 things that can make noise. So i'm wondering if my solution would be a good approach:

Have a singleton class that holds around 20-30 sound instances, and also holds all sound buffers for the game.
When an object wants to make noise, that object calls a function on this class with the requested sound name, like Singleton.noise("Explosion1", myPosition). Then the singleton selects a sound instance not being used, sets it's buffer to the explosion1 buffer, and plays the sound at that location.

I don't see anything wrong with my approach, but I don't want to write this just to have it fail because I didn't realize something about the way sfml does things. So thank you for your input  :)

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10815
    • View Profile
    • development blog
    • Email
AW: Many sounds for a game.
« Reply #1 on: February 22, 2015, 07:51:13 am »
Should work though I advise against the usage of singletons.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Strikerklm96

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
    • Email
Re: Many sounds for a game.
« Reply #2 on: February 22, 2015, 04:28:09 pm »
Ok, that is a pattern I need to stop using, but how else should I do it?

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Many sounds for a game.
« Reply #3 on: February 22, 2015, 05:21:49 pm »
Passing references or (smart)pointers to constructors so those objects can just store them internally for later use would be one commonly used option instead of the singleton anti-pattern.
« Last Edit: February 22, 2015, 05:25:27 pm by Jesper Juhl »

Strikerklm96

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
    • Email
Re: Many sounds for a game.
« Reply #4 on: February 22, 2015, 05:38:01 pm »
Sorry, but I don't think I fully understand. Put a bunch of sound instances somewhere and sprinkle them around to the objects that need them?

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Many sounds for a game.
« Reply #5 on: February 22, 2015, 05:43:43 pm »
I'm on my phone right now so writing code examples is awkward, but I'll write you a few examples later tonight when I'm back home at my computer.

Strikerklm96

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
    • Email
Re: Many sounds for a game.
« Reply #6 on: February 22, 2015, 05:49:50 pm »
Ok, and to clarify, it may not technically be a singleton, because you can instantiate multiple. It's just that every world that get's created only has 1, and my game would never create more than 1 world, so there will only ever be 1 or 0. This is essentially what i'm doing:
http://gameprogrammingpatterns.com/singleton.html
ctrl-f: Get it from something already global

search that text to see what I have been doing (and was planning on doing)
« Last Edit: February 22, 2015, 05:55:30 pm by Strikerklm96 »

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Many sounds for a game.
« Reply #7 on: February 24, 2015, 09:28:56 pm »
Sorry about the late reply - real life got in the way.

What I meant with my previous reply was this:

Singletons are often used for "manager" classes - like "ResourceManager", "NetworkManager", "DatabaseManager" etc.
The classic singleton pattern goes something like this:
class Singleton {
...
static Singleton *instance() { return /* create instance if needed */ m_instance; }
...
};

class SingletonUser {
...
void doStuff() { Singleton::instance()->getResource("foo").doStuff(); }
...
 

That's nice and convenient for "SingletonUser", but the Singleton class has a number of problems;
 - it is effectively a global variable which means that it has all the issues of regular global variables of coupeling classes too tightly.
 - it get into trouble with destruction since that happens after main() ends and then the world might not be in a state it can cope with (I've see this too often to find it funny).
 - it may itself use other Singleton classes and they may use it and then we have a lot of "fun" centered on who gets instantiated first etc..
 - etc etc - I could write a lot about the problems with global variables (and I have done so; just search the forum) and it all applies to singletons + more. I won't repeat myself here.

What you can do instead is to simply construct your "manager" object (or whatever your singleton is) early in "main()" and then pass references to that object to classes that need to access it.
So you'd do something like this:
class TextureManager { ... };
class TextureManagerUser {
  TextureManagerUser(const TextureManager& tm) : m_tm(tm) {};
  void doStuff() { m_tm.getResource("foo").doStuff(); }
 ...
};
int main() {
  TextureManager tm;
  ...
  TextureManagerUser tmu(tm);
  ...
}
 

The lifetime of the "TextureManager object is nicely controlled by being bounded by "main" and yet, the "TextureManagerUser" can be sure it lives long enough since it has been created before itself. It doesn't need a "global" or "static" function to get hold of it - it got a reference when it was constructed and stored that within itself.
See what I'm getting at?

Strikerklm96

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
    • Email
Re: Many sounds for a game.
« Reply #8 on: February 28, 2015, 06:36:35 pm »
Yes, and that's exactly what I was doing, thanks for clearing that up though! I was using the terms Single-instance and Singleton interchangeably when I shouldn't have.