SFML community forums

Help => General => Topic started by: FRex on October 20, 2012, 02:28:32 am

Title: Where to put manager classes
Post by: FRex on October 20, 2012, 02:28:32 am
Hey, for example: textures manager, that holds map of strings to textures. Where to put it? It should be accesible from anywhere sf::Texture is... so.. everywhere, that's the problem. What are the options even? A static pointer of a class that also has static method GetReference()? Externs? Creating in main and passing pointer around anyone who is likely to request duplicates of already loaded texture?
Title: Re: Where to put manager classes
Post by: Nexus on October 21, 2012, 12:06:47 pm
It should be accesible from anywhere sf::Texture is... so.. everywhere, that's the problem.
That's indeed the problem, your assumption is wrong ;)

You don't need it everywhere. You only need it in the part of your game which is responsible for the graphics, and in particular, sf::Texture. You don't need it for physics, audio, AI, or other game logic. So you can put your manager object in a class responsible for the graphics.
Title: Re: Where to put manager classes
Post by: FRex on October 21, 2012, 12:24:37 pm
Quote
You don't need it everywhere. You only need it in the part of your game which is responsible for the graphics, and in particular, sf::Texture. You don't need it for physics, audio, AI, or other game logic. So you can put your manager object in a class responsible for the graphics.
Well yes, it 'should be acessible from few places in which I might need same textures'. So there are few locations one of these should be placed I can think of. I'm really struggling with structuring anything nicely in oop. ;D Apparently global singletons are bad so I'm avoiding them. Should I just let any group of classes that are likely to request same textures keep a pointer to their texture manager? Is that 'dependancy injection'?
Title: Re: Where to put manager classes
Post by: Nexus on October 21, 2012, 02:30:56 pm
Should I just let any group of classes that are likely to request same textures keep a pointer to their texture manager?
Yes, that is a possibility.

You can also add a small abstraction layer in-between: Each texture gets an identifier (e.g. an enum or small description string). The classes that request textures then pass this ID to a higher-level class, which in turn lookups the exact resource path and returns the sf::Texture. This has the advantage that you don't need to refactor every place where textures are processed, in case something with the loading changes.
Title: Re: Where to put manager classes
Post by: mateandmetal on October 22, 2012, 02:07:56 am
You need to share textures between game states?

I think you can have a texture manager instance inside your game state manager class, and a public accesor, so your game states can easily access the textures ( say goodbye to evil singletons  8) )

Pseudo-code:
   texture = gameStateMgr.getTextureManager().getTexture("file.png")
 
Title: Re: Where to put manager classes
Post by: FRex on October 22, 2012, 02:13:01 am
May or may not need to share between several instances of a something(bullet, monster, whatever) so I need a way to request texture - freshly loaded or already existing from previous request and I'm considering the options.
Title: Re: Where to put manager classes
Post by: masskiller on October 22, 2012, 05:00:14 am
In my manager class I use a getTextureref method which receives an unsigned int to get a reference of the texture according to the number given, that way I can use the texture for whatever I want as long as I have filled the object with something. I was even thinking of adding the same functionality to operator[]. In my case I fill the manager with all images(and textures afterwards) I need beforehand and then use it as needed for either sprites or a class that uses them.